Two quick updates: first, setuptools 0.6c10 and 0.6c11 now support subversion
1.6.  Second, in 0.7a1 the plan is to phase out setuptools' native SVN support
in favor of a separate plugin that can be updated independently of setuptools. 
This would allow a plugin that uses the SVN API, or the svn command line tool,
or really whatever you like.

I'm leaving this issue open for now, but I'd suggest taking a look at issue 42,
which is tracking the revision-identifying part of this.  (The file-finding part
of course can be implemented as a standard file finder plugin.)

Subversion 1.6 has been out for about 5 months.  Seems like forever, I know.

I absolutely agree that this is a good idea and we should move forward with an
implementation.

I don't want to spend time on an implementation that will just linger here in
patches.  What needs to be done to get buy-in from a maintainer with commit access?

I'm also glad to see some progress on this topic. If I may add my 2 cents though, doing it 
the simple way first, by using svn if available in the path, would already cover 90% of the 
situations and bring the most value at the lowest implementation effort.

The point 4) from msg320 and the extra features 1) & 2) could always come later.

The fact is that Subversion 1.6.x is out since ... a year or so? and issue64 is still 
opened, which is a situation that could have been avoided if the simple approach suggested 
here would have been taken earlier.

Let's also have in mind that Subversion 1.7 will have wc-ng and therefore ''no'' private 
files to mess with, making point 1) from msg320 moot. Unless of course you want to look into 
their sqlite database file with the Pysqlite2 bindings... which would be another bad idea.

I'm all for this (and willing to help). A couple of comments/questions:

1. The command should run even if there's no .svn directory present (I think
that's implied, but probably worth stating explicitly).

2. For your #4), can the existing setuptools hooks be considered enough of an
"alternative means"?

3. For your #3), I believe "svn list --xml" (or "svn list --xml --recursive")
will cover the details you need (e.g. when extracting lists of files).

@jaraco

Thanks for your well formed reply to my (apparently incoherent, upon rereading)
comment. I must remember not to update bugs without coffee in the morning. :)

I better understand the constraints that you are operating under and very much
appreciate the fact you are working on this voluntary. An iterative improvement
is indeed better than none.

Thanks again,


David

Per issue #64, there is a need for a more future-resistant SVN entries parsing
mechanism for setuptools.  The existing implementation is brittle and depends on
file formats which are internal to the SVN implementation.  @dw has proposed
setuptools use 'svn info --xml' to retrieve entry information.

I propose a patch must support the following:
1) Support fallback to native pure-python parsing if command is not found or
cannot be executed.
2) Use subprocess (requires Python 2.4) for broad platform support (including
Jython).
3) The current implementation appears to gather more detail from the entries
file than is exposed by 'svn info --xml'.  Ensure that the command-based
implementation provides the same logical result.
4) The implementation should have a well-defined and configurable means to
locate the SVN client. If there is no 'svn' command in the search path, there
should be an alternative means for setuptools to locate the command (such as one
or more of: a registry entry, environment variable, package manager callback, etc.).

Some features that may also be considered.
1) Support linking to the TortoiseSVN DLL for Windows users (use ctypes to avoid
compile-time dependencies).
2) Support shelling to a Java VM to support users of Subclipse.

Comments and suggestions are appreciated.  After there is a consensus, I'm
willing to draft an implementation.