The bug tracker for setuptools 0.7 or higher is on BitBucket



Title SVN Entries parsing should use local svn command for implementation
Priority feature Status chatting
Superseder Nosy List cboos, dw, grant, jaraco, mjpieters, pje, rjollos, srid
Assigned To Keywords

Created on 2009-07-05.23:43:27 by jaraco, last changed 2013-01-09.20:46:11 by rjollos.

File name Uploaded Type Edit Remove
unnamed pje, 2011-11-09.17:26:35 text/plain
msg647 (view) Author: pje Date: 2011-11-09.17:26:35
FYI, the setuptools_subversion package can be used until such time as I
backport its functionality:

Unfortunately the above code requires 2.4 as a minimum, and setuptools
still supports 2.3+
msg646 (view) Author: cboos Date: 2011-11-09.07:13:01
Re msg645: please no, this ticket is about using the *svn command line* in order to be robust against implementation changes...

Your "select local_relpath from nodes" follows the same logic as "it's easy, just get the version from that .svn/entries file" and will likely break in svn 1.8 again, etc. (oh well, I already said that in msg320 it seems).

Anyway, I don't think that anything will happen on this front here (for the "historical" setuptools). The similar issue for Distribute is:
msg645 (view) Author: mjpieters Date: 2011-10-17.12:47:55
Now that Subversion 1.7 has been released, we are once again in the same bind. There is only one root .svn directory now, which contains a sqlite file named `wc.db`. This should make it a lot easier to get the information, a simple "select local_relpath from nodes;" gives you all the files in the repository.
msg437 (view) Author: pje Date: 2009-10-21.05:22:47
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.)
msg340 (view) Author: jaraco Date: 2009-07-31.12:00:08
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

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?
msg339 (view) Author: cboos Date: 2009-07-31.09:59:21
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.
msg323 (view) Author: grant Date: 2009-07-07.15:38:45
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).
msg322 (view) Author: dw Date: 2009-07-06.00:17:22

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,

msg320 (view) Author: jaraco Date: 2009-07-05.23:43:27
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
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.
Date User Action Args
2013-01-09 20:46:11rjollossetnosy: + rjollos
2011-11-09 17:26:36pjesetfiles: + unnamed
messages: + msg647
2011-11-09 07:13:02cboossetmessages: + msg646
2011-10-17 12:47:55mjpieterssetnosy: + mjpieters
messages: + msg645
2009-10-21 05:22:48pjesetnosy: + pje
messages: + msg437
2009-08-31 22:19:06sridsetnosy: + srid
2009-07-31 12:00:08jaracosetmessages: + msg340
2009-07-31 09:59:22cboossetnosy: + cboos
messages: + msg339
2009-07-07 15:38:46grantsetnosy: + grant
messages: + msg323
2009-07-06 00:17:22dwsetstatus: unread -> chatting
messages: + msg322
2009-07-05 23:43:27jaracocreate