@dw You make some good points, and I don't disagree that shelling out to an SVN
client would be a valuable approach, and probably even the preferred approach.

Nevertheless, the existing implementation, while having dependency on a specific
file format, does not have any dependency on a subversion client.  I'll describe
some scenarios that come to my mind in which a person may have a subversion
checkout of a project without having the defacto subversion client available.

1) Using Subclipse under Eclipse.  Subclipse may be using JavaHL or SVNKit as
the underlying library for working with the SVN checkout.  JavaHL links to the
reference implementation whereas SVNKit re-implements the same code in Java.  In
either case, there is no svn command that can be run (although it may be
possible to initiate a JavaVM with the proper java class to parse out the SVN
entries info).
2) Windows users typically use TortoiseSVN.  On 64-bit Windows, the reference
implementation of SVN isn't even available, although there is SlikSVN which
makes available a 64-bit command-line client for Windows.  Nevertheless, Windows
users prefer TortoiseSVN, which like JavaHL SVN links to the reference
implementation, but does not provide an svn command.  As far as I can tell,
TortoiseProc.exe doesn't expose any command to retrieve the info for a checkout.
3) In some deployment scenarios, deployment may be performed on a different
machine than that on which development is performed.  For example, I have a
Windows XP box that mounts a share on my development machine for the purpose of
deploying binaries for older versions of Python.  This deployment machine has
Python and setuptools, but has no need for subversion, as no subversion
operations are ever done on that machine.

I point out these scenarios to illustrate only some of the cases that affect my
use of setuptools.  I'm all but certain there are other scenarios where having a
subversion client is not a defacto assumption.

durin42 points out that we might be able to use bindings, but I would argue that
adding compile-time dependencies on setuptools is also a barrier for some
platforms.  Because setuptools is such a pervasive dependency, it would be
unwise to add a compile-time requirement that delays or prohibits the deployment
to the various platforms.  For example, pysvn for Windows 64-bit is not readily
available.  I would hate for setuptools to find itself in the same boat because
of the challenges with compiling it.  If Tigris.org were to release pure-python
bindings that could be borrowed wholesale by setuptools, that would great.

You mention that this approach cost you an hour of your billable time last week,
but you would not have had to spend this time if the patch had been applied and
released sooner.  The patch takes an incremental step toward improving the
approach and providing a more generalizable architecture for determining
entries, including possibly using a shell out to an existing SVN client.  A lot
more than an hour of non-billable work has gone into making setuptools more
compatible while maintaining backward-compatibility and portability.  I think
it's unfair to dismiss this effort simply because it isn't the implementation
that works best for your particular configuration.

That said, your suggestions are very good.  This effort is one of my few
contributions to setuptools.  I have very little visibility into the effort and
am only trying to contribute where I can without making too many waves.

I still contend that to the extent possible, setuptools must support native,
pure-python access to svn info to support the nature of its broad deployment.

If someone would commit the patch as we have it, I'd be happy to move forward
with an additional effort to implement a command-based version... and to query
the community on whether this should be the preferred or fallback approach.