Subversion

Updated September 28, 2004 | March 2004 | Fredrik Lundh

A pretty good version control system, by Greg Stein and others. See subversion.tigris.org.

Observations

Subversion rules!

However…

Migration Issues

The p42svn tool sometimes destroys binary files. This is either a bug in the tool, or a bug in svnadmin load (probably the tool; it looks as if it either fails to set the mime-type based on the perforce types, or doesn’t try at all).

Remember that svnadmin may create files in the repository which are owned by the user running svnadmin. If you’re not careful, you can end up with a repository that cannot be accessed by the Subversion server. If you’re unlucky, a user can crash the repository simply by browsing the repository, if you’re running svnadmin at the same time (but svnadmin recover and chmod can help you). If you’re really unlucky, the poor user browsing the repository can cause a svnadmin load to crash. And when you’ve repaired the repository, you’ll find that you cannot finish the load, since the first N revisions has already been checked in, which means that old versions of most of the files already exist in the repository.

Usage Issues

Properties are nice, but having to use three different commands to check in a text file from Windows is pretty annoying. Perforce’s “p4 add -t text+k” is a lot easier to get right than “svn add” followed by “svn propset svn:eol-style native” followed by “svn propset svn:keywords Id”.

(Suggestion: add a “-t type” option where “type” is mapped to a set of properties, according to some configuration file somewhere (like auto-props, but less auto).

(Suggestion: add a “-b” option to “force binary mode” (implies a propset svn:mime-type application/octet-stream). this would save me lots of time and trouble).

Make sure your hook scripts are executable, and that they’re designed to run from any directory. If you put helper tools in the hook directory itself, make sure the hook changes to the right directory before it calls the helper tool.

The error messages could need some work. When Subversion refuses to do something, telling the user that something’s “locked”, something’s “not locked”, something’s “not part of the workspace”, or something’s “not up to date” isn’t very helpful, when it’s obvious that nobody’s ever touched that something since the last checkout. And when Subversion refuses to proceed because it needs to copy a file that was deleted from the repository several days earlier, it would be nice if it could, sort of, motivate its decision.

And yes, the Subversion server shouldn’t generate invalid XML. Or if it has to, the Subversion client should be equipped with a tolerant parser.

(Suggestion: Change the —xml option so it simply displays whatever XML it gets from the server, rather than trying to parse it before printing it out.)

A recursive svn update may hang if the repository contains files that map to the same filename on a case-insensitive file system (e.g. Area.py and area.py). If you run the same command in the directory where the files are, you get an error message. If you delete one of the files from the repository (using svn delete), the command ignores the case you specify, and picks on the files by chance (i.e. svn delete Area.py deletes either area.py or Area.py).

(Suggestion: Trust the user. Don’t mangle the filename before you’ve looked in the repository.)

(to be continued)

Build Issues

Building ViewCVS is painful. Actually, finding ViewCVS is painful. The Subversion documentation links to the ViewCVS homepage, which contains pointers to ViewCVS 0.9.2. Which, of course, doesn’t support Subversion at all. To get Subversion support, you need to get the latest code from CVS. CVS, not Subversion. And when you’ve done that, you have to make sure that you have the right version of SWIG (old ones thinks Subversion is written in C++), the right version of libtool (old ones gets confused by certains options), and probably a few other right versions (since the build process cannot find Python.h anywhere). Nearly two hours later, I gave up.

RPM is a bad joke. We installed Subversion on a Windows XP box and had a server running in a couple of minutes (without ever having installed Subversion before). We built Subversion from source on an old RedHat server in less than 30 minutes (20 of which was spent on figuring out how to get Subversion to understand that we really had the right version of Berkeley DB in /usr/local/lib). We spent nearly four hours to make Subversion run on Fedora Core, using prebuilt RPM packages for that very platform.

What exactly is it that causes the APR configure script to need several hours to finish on a Tru64 4.0 machine? And the resulting build files don’t work, either. Portable, my ass.

Works better on Tru64 5.X. Better, but not good enough: I get a svn command, but as soon as you try to do something with it, it crashes, with a runtime linking error. Fixes:

1. Add -lpthreads to LIBS. This made the help crash go away, but now all invocations crash with “symbol iconv_open unresolved”
2. Add -liconv to LIBS: didn’t help. (Bloody APR crap. what’s wrong with plain ANSI C and POSIX?)
3. Fix the include paths. Turned out that the build used tru64’s own iconv.h, but -liconv picked up the GNU version installed under /usr/local/lib. I simply hacked apr-util/xlate/xlate.c to include /usr/local/include/iconv.h instead of plain iconv.h. Other solutions can be found here.

Silly Subversion Error Messages

From time to time, subversion surprises me with yet another incomprehensible error message. If you know what they mean, and know how to avoid them, let me know (dead link).

$ svn up
Invalid editor anchoring; at least one of the input paths is not a directory and there was no source entry.

(Solution: unknown)

$ svn co http://…/foo
svn: Working copy ‘foo’ not locked
$ cd foo
$ ls
$ svn up
A fie
A fum
…

(Solution: unknown)

$ ls font
ls: font: No such file or directory
$ svn up font
svn: ‘font’ is not under version control
$ cp -R ~/somewhere/font .
$ svn add font
svn: warning: ‘font’ is already under version control

(Solution: somewhere/font was also under version control. To check in the copy, remove the extra .svn subdirectory: “rm -rf font/.svn”)

$ svn cleanup
svn: In directory ‘tcl8.0.5/doc’
svn: Can’t copy ‘tcl8.0.5/doc/.svn/tmp/text-base/LinkVar.3.svn-base’ to ‘tcl8.0.5/doc/LinkVar.3.2.tmp’: No such file or directory

(Solution: unknown. well, removing the directory and doing another “svn cleanup” followed by “svn up” helps, of course.)

A reader writes:

A possible cause can be an svn client running on a case insensitive system (for example Mac OS X, which is only case preserving). If the .svn/entries contains at the same time lowercase and uppercase versions of the same file name, only one of them will be honored by the system, hence the Missing File Warning. A solution is to svn remove the file present on the system (properly spelled with respect to the case) then svn commit the directory to validate the change.)

(to be continued)