I bounced this around quiet a bit. I'm sure there will be some comments, I'm not married to anything.
I cleaned out sdist.py. The CVS is consolidated into an object; after working out the SVN all remainder of the repository code left was CVS specific, the interface for the cvs_svn hook shouldn't be any different. If you want, I can try to throw together some CSV tests if you think it needs more.
I added a bunch of SVN tests. The parsing of XML and output has been saved so I test for 1.3-1.8. However, only the version on the path gets tested for the command interface. Due to obvious issues.
Not sure we really needed to worry about pre svn-1.3 in which case, the command line interface will cover everything.. So I cleaned this up. The downside being that you have to have a SVN client, but that would be the case for 1.7+ anyway.
this would probably play weird with any third party svn plugins.
all the SVN stuff is in a separate svn_util.py file
I'm not sure about Mac's as they do has odd encoding stuff, but I have tested this fairly thoroughly otherwise
Thanks for this! Especially all the work on the tests.
I guess it's possible to drop support for parsing the files directly (and require a specific client). While this does have some substantial advantages, it does fail to support some environments. At one time, I used to develop using Eclipse and its SVN plugin. I didn't have a command-line client installed. In this type of environment, this patched version of setuptools would no longer work properly. Perhaps that's an acceptable backward-incompatibility, but I'm reluctant to impose that on others. At the very least, we should have an interim release that (a) supports both interfaces and (b) raises a deprecation warning when only the native parser is viable (i.e. there's no command-line interface). This will signal to users that the support will be going away and draw their attention to this issue before the support is dropped in a subsequent release.