Issue #26 resolved

SVN 1.7

created an issue

It is really interesting how far I've gotten sidetracked, but scratching the itch I suppose.

I was running the tests for pip on win32 and the SVN tests were failing, took a looked like there is an issue with metadata support for SVN 1.7.

I had tossed together a revision to get_svn_revision to get the pip's test suite to complete with 0.7.3dev and svn1.7. This revision is a bit different than my original patch but should get the idea across. I was surprised that the suite only choked on getting the revision. So, I have doubts about the completeness of the this fix.

Also I used the subprocess module (in a Python2.4+ compatible manner). However, I noticed a comment in the module saying that needed to be Python 2.3 compatible. Is this still true?

Looks like the change is pretty significant: Switching to a central sqllite database located in the root .svn directory. Some of the documentation would seem to indicate that they want people to use the command line tools to access this information and not the try to use it directly.

I had some concerns about testing. I have a which uses the command line to build the working directories for testing get_svn_revision(), but would seem wiser to just provide static copies of a checked out directory. SVN tests looks like they need to be expanded.

Here are some previous tickets on the issues as the issue tracker has migrated around:

subversion 1.5 working copy causes problem in entries_finder: NameError: global name 'log' is not defined

This contains several patches for converting the current setup to a separate SVN class. This looks like a good idea (would probably be saner for testing) Subversion 1.6 entries format 'unrecognized'

SVN Entries parsing should use local svn command for implementation

Subversion 1.7 introduces new storage format - breaks distribute svn support

Later i will grep the code for svn related routines and see if I missed anything.

Comments (15)

  1. philip_thiem reporter

    Relevant files appear to be:

    • setuptools/command/
      • externals_finders - look like read/parse iterator looking for svn:externals from a properties file
        • referenced by a global variable to look in .svn/dir-props, .svn/dir-prop-base
      • enteries_finder - lists directory enteries.
        • referenced by a global variable to look in .svn/enteries,
      • these are referenced with iter_entry_points : setuptools.file_finders
        • used only (as much as I can see) by walk_revctl
          • which is only used in
            • rcfiles = list(walk_revctrl())
    • setuptools/command/
      • get_svn_revision

    The following uses SVN from command-line

    • setuptools/
      • _download_svn

    So will probably need to add a test for the walk_revctrl() function or at least the iter_entery_point.

  2. philip_thiem reporter

    Looks like both over look externals (1.7 doesn't have .svn/dir-prop-[base]) and the fact that there seems to be 2-3 different field orderings supported

  3. philip_thiem reporter

    cleaned up things don't need all the file parsing if we just rely on the commandline tools. Everything can be done from the command line from 1.3.x onward without localization issues. My branch has a working implementation. Just need some finishing touches with encodings and a 1.6 repository test case since I broke one of Jason's

  4. philip_thiem reporter

    Ran into a bit of snag with what some of the newer version will accept for svn:externals, and finally finished expanding out the unit tests (not pushed to my repo yet). Will probably merge the latest develop this weekend and if all goes well test will pass on win32 X (py 2.4-2.7 and 3.1-3.3) x (svn1.3-1.8) and linux x (py 2.5-2.7 and 3.1 and 3.3) x svn1.6 before I send the pull request. If someone on darwin wants to try it out or knows of a travis-ci on mac service, I can pushing things a bit sooner. :)

  5. Log in to comment