Revision number lost 0.12dev-r0

[anonymous]

Installing on Windows from trunk not shows the correct Revision number:

...
Installed d:\python25\lib\site-packages\trac-0.12dev_r0-py2.5.egg
Processing dependencies for Trac==0.12dev-r0
Searching for Genshi==0.6dev-r1019
Best match: Genshi 0.6dev-r1019
Processing genshi-0.6dev_r1019-py2.5-win32.egg
genshi 0.6dev-r1019 is already the active version in easy-install.pth

Using d:\python25\lib\site-packages\genshi-0.6dev_r1019-py2.5-win32.egg
Searching for setuptools==0.6c9
Best match: setuptools 0.6c9
Adding setuptools 0.6c9 to easy-install.pth file
Installing easy_install-script.py script to D:\Python25\Scripts
Installing easy_install.exe script to D:\Python25\Scripts
Installing easy_install-2.5-script.py script to D:\Python25\Scripts
Installing easy_install-2.5.exe script to D:\Python25\Scripts

Using d:\python25\lib\site-packages
Finished processing dependencies for Trac==0.12dev-r0

I'am running trac on Windows Server 2003, Apache 2.2.11, Python 2.5, SVN 1.6.0

[anonymous]

Additional version infos: Trac: 0.12dev-r0 Python: 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] setuptools: 0.6c9 SQLite: 3.3.4 pysqlite: 2.3.2 Genshi: 0.6dev-r1019 Babel: 0.9.4 mod_python: 3.3.1 Subversion: 1.6.0 (r36650) jQuery: 1.3.2

[ebray]

Works fine for me with Trac from trunk with Python 2.5.2 and SVN 1.5.1. I wonder if it's some incompatibility between SVN 1.6dev and setuptools—that seems the most likely culprit.

What command are you using to build/install Trac?

[DS77 <marcel@…>]

The command is: setup.py install I'm not using svn 1.6dev. I use 1.6 final (​http://subversion.tigris.org/svn_1.6_releasenotes.html) trac 0.12dev runs since a few month without any problem on my system. The broken revision number semms to be a compatibility issue after updating svn to 1.6.0 final.

[DS77 <marcel@…>]

Is there nobody with same problem?

[Remy Blank]

I know setuptools does some voodoo to get the revision number from the .svn folder directly, instead of using SVN bindings. It's possible that this doesn't work anymore with SVN 1.6, as IIRC the working copy format has changed.

This is most likely related to:

​http://bugs.python.org/setuptools/issue64

Anyway, this is not an issue with Trac.

[DS77 <marcel@…>]

Here you can find a patch ​http://bugs.python.org/setuptools/file49/svn_1.6_format.patch which solves this issue.

[Christian Boos]

… which will work until the next version of Subversion. How hard is it for them to use the svn command-line for such things?

[Emmanuel Blot]

Replying to cboos:

… which will work until the next version of Subversion. How hard is it for them to use the svn command-line for such things?

I think they've already considered this option: they may not want to rely on external dependencies. It's a trade-off.
Knowing how Trac has been boring on this subject, I'm not sure they're wrong ;-)

[Christian Boos]

Of course, having a dependency on the svn bindings, like Trac has, would be even worse.

But the external dependency on the command line is not a hard requirement, given that the task in question is about getting the version information out of a svn workspace. The only situation that I can think of where you would have a Subversion checkout without having the command-line available is when you're only using TortoiseSvn - in which case, there's still the SubWCRev command.

If the only Subversion tool you have is some other high-level tool, then yes, you'd be out of luck, but not more than every time there's been a wc format change, which happens pretty consistently for every new major release - and the error message and solution would be more understandable than a backtrace (something like "No svn or SubWCRev executable available. Be sure to have either Subversion or TortoiseSvn tools in the PATH.").

[Emmanuel Blot]

Replying to cboos:

and solution would be more understandable than a backtrace (something like "No svn or SubWCRev executable available. Be sure to have either Subversion or TortoiseSvn tools in the PATH.").

I agree on the latter point: the error message is all but easy to understand.
On the other points, there are several high-level tools out there: hardcoding various way to find the proper tool, depending on the platform etc. may not be very handy. What about Java-based SVN client, Mac OS X Cocoa clients, etc? They cannot support the dozens of available clients out there.

The main issue for me is that setuptools should be updated as soon as a new SVN release is out: it takes far too long for setuptools to get updated to a new, official SVN release: they choose to implement their own parser, whatever the actual reasons, so they should support new WC format every time it is created.

Just another reason not to rush to the latest SVN version as soon as it gets released. I used to run after the very latest version of every tool, but the truth is that it is just time consuming, and usually properly bugged ;-). In other word, Never rush when a new SVN major version is released. It is usually bugged, and poorly supported.