Monday, August 17, 2009

Interesting svn "gotcha"...

I just learned that you have to be careful about which version of subversion you are using if you have an IDE and also want to use the command-line client.

Starting about V1.4, there were changes in the internal structure of the subversion directory hierarchy (i.e., the .svn files that it creates to track things) which means that you have to make sure that your versions are in synch.

For example, I'm using Aptana Studio, which is eclipse-based, and which uses the latest subclipse client (subversion for Eclipse). That latest version is V1.6. However, on my Kubuntu development box (V8.04/Hardy Heron), the latest subversion package right now is V1.4. If I try to run a subversion command from the shell, I get this error message:
jseidel@EDP15:~/AptanaStudio/4MyPasswords$ svn status
svn: This client is too old to work with working copy '.'. You need
to get a newer Subversion client, or to downgrade this working copy.
See http://subversion.tigris.org/faq.html#working-copy-format-change
for details.

The help link above will explain that -- due to new features in the later versions -- they had to introduce new structure which is incompatible with the older clients.

Since I don't want to downgrade my working copy, I went looking for V1.6 command-line clients. Sad to say, they aren't packaged (yet) for Kubuntu/Hardy --so far I only found it for the Karmic version of Ubuntu.

There are other svn clients out there, either as wrappers around the command line client, or full-on clients. One that I looked at was kdesvn. This looked to be a nice client and was at V1.6. Unfortunately, the developer only provides a Fedora package, so I would have to build my own from source.

I went to the subversion site, but the referenced Ubuntu binaries only pointed back to the Ubuntu site and the older version, so I tried building it from source. Bad move! As stated on their site, there are a number of dependencies which I started to work through one at a time. When I reached a point of having to figure this out:
jseidel@EDP15:~/downloads/subversion-1.6.4/subversion-1.6.4$ apr/buildconf
buildcheck: checking installation...

buildcheck: autoconf version 2.61 (ok)

buildcheck: autoheader version 2.61 (ok)

buildcheck: libtool version 1.5.26 (ok)

buildcheck: local copy of find_apr.m4 does not match APR's copy.

An updated copy of find_apr.m4 may need to be checked in.
buildcheck: local copy of PrintPath does not match APR's copy.

An updated copy of PrintPath may need to be checked in.
Copying libtool helper files ...

buildconf: Using libtool.m4 at /usr/share/aclocal/libtool.m4.

Creating include/arch/unix/apr_private.h.in ...

Creating configure ...

configure.ac:185: error: possibly undefined macro: AC_PROG_LIBTOOL

If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
Generating 'make' outputs ...

apr/buildconf: 91: build/gen-build.py: not found rebuilding rpm spec file

apr/buildconf: 107: build/get-version.sh: not found

cat: ./build/rpm/apr.spec.in: No such file or directory


I quit trying: I want to work on my application, not have to learn THIS much about the internals of the tool I want to use... Argh! For now, I'm sticking with the Aptana support which is working (with some help from the Aptana support folks), although I do miss the ability to do quick svn commands from the shell.

I think Linux needs to come up with a better installation mechanism...

3 comments:

  1. I ran into that too. Tried googling for an answer but came up with nothing. Then I read the error properly and realized it was a simple path error. i.e. it can't find "build/gen-build.py" because it's not in your svn source directory, it's in "apr/build/gen-build.py" instead.

    The simple solution is to move to the apr directory first and then run the command:
    cd apr
    ./buildconf

    Don't know if you're interested in giving it another try, but I thought I'd pass this on anyway. I totally agree that building subversion is far more trouble than it needs to be.

    ReplyDelete
  2. @matt:
    Thanks for the feedback; hopefully it will help someone else with the problem. As for me, I've moved on. I'm now using git and Heroku. Great combination with drop-dead easy deployment. And I've moved from Aptana to RubyMine: much better, IMO.

    ReplyDelete
  3. It did, in fact, help someone else out. Thank you _so much_ for posting the solution.

    ReplyDelete