Alan,
Thank you for the critique! I hope that aside from the above gripes, you found the package useful otherwise.
Regarding the issues you've raised ...
<ul>
<li><b>Use of PEAR_ErrorStack</b></b>
While I was writing VC_SVN, the following post about PEAR_ErrorStack popped up on the PEAR-DEV list.
http://marc.theaimsgroup.com/?l=pear-dev&m=108200419215900&w=2
Not wanting to waste time using PEAR_Error if the new standard is PEAR_ErrorStack, I just used PEAR_ErrorStack.
The raging debate on PEAR-DEV regaring error handling, exceptions, etc. has far exceeded the amount of time I have to spend reading list posts ... so until something formal is posted on pear.php.net about a final decision on error handling in PEAR packages, I still believe that the choice of PEAR_ErrorStack was the best choice for VersionControl_SVN, and will most likely be my choice for future packages.</li>
<li><b>Making things easy vs. Messy API</b>
The snippet in your example ...
$x = VersionControl_SVN::factory(array('list','cat'), $options);
$x->list->run()....
... is an optional way to do things. This would work just as well:
$svnlist = VersionControl_SVN::factory('list', $options);
$svnlist->run()....
$svncat = VersionControl_SVN::factory('cat', $options);
$svncat->run()....
The option of a multi-command factory is to save some keystrokes for those instances when you need to use a number of svn subcommands. But, it <b>is</b> an option, not a requirement ... as stated pretty clearly (I think, anyway) in the documentation.</li>
<li><b>Counterintuitive Program Flow</b>
The run() method doesn't change between subcommands, but the prepare() and parseOutput() methods do. In trying to keep the package small and maintainable, it made sense to me to keep the code that's the same through out the package in the base class.
I'm open to suggestions on how to approach this differently ... but naturally I'm looking for ways to keep the package as light as possible.</li>
Alan, I definitely do value your comments -- if you recall, I made numerous tweaks to the package based on your initial review when VC_SVN was in the propsal phase. I guess I don't agree with the issues you've raised here, but your previous comments definitely made VC_SVN a much better package than it was originally.
