Troubleshooting

happen at random.

These appear to be due to the various Windows services that monitor the filesystem for changes (anti-virus software, indexing services, the COM+ Event Notification Service). This is not really a bug in Subversion, which makes it difficult for to fix. A summary of the current state of the investigation is available at http://www.contactor.se/~dast/svn/archive-2003-10/0136.shtml. A workaround that should reduce the incidence rate for most people was implemented in revision 7598.

On FreeBSD, certain operations (especially svnadmin create) sometimes hang.

This is usually due to a lack of available entropy on the system. Subversion asks APR to generate random numbers to create UUIDs from time to time, and certain operating systems will block for high-quality randomness. You probably need to configure the system to gather entropy from sources such as hard-disk and network interrupts. Consult your system manpages, specifically random(4) and rndcontrol(8) on how to effect this change. Another workaround is to compile APR against /dev/urandom instead of /dev/random.

I can see my repository in a web browser, but svn checkout gives me an error about 301 Moved Permanently.

It means your httpd.conf is misconfigured. Usually this error happens when you've defined the Subversion virtual “location” to exist within two different scopes at the same time.

For example, if you've exported a repository as <Location /www/foo>, but you've also set your DocumentRoot to be /www, then you're in trouble. When the request comes in for /www/foo/bar, Apache doesn't know whether to find a real file named /foo/bar within your DocumentRoot, or whether to ask mod_dav_svn to fetch a file /bar from the /www/foo repository. Usually the former case wins, and hence the "Moved Permanently" error.

The solution is to make sure your repository <Location> does not overlap or live within any areas already exported as normal web shares.

I'm trying to look at an old version of my file, but svn says something about “path not found”.

A nice feature of Subversion is that the repository understands copies and renames, and preserves the historical connections. For example, if you copy /trunk to /branches/mybranch, then the repository understands that every file in the branch has a “predecessor” in the trunk. Running svn log --verbose will show you the historical copy, so you can see the rename:

r7932 | joe | 2003-12-03 17:54:02 -0600 (Wed, 03 Dec 2003) | 1 line Changed paths:

A /branches/mybranch (from /trunk:7931)

Unfortunately, while the repository is aware of copies and renames, almost all the svn client subcommands in version 1.0 are not aware. Commands like svn diff, svn merge, and svn cat ought to understand and follow renames, but don't yet do this. It's scheduled as a post-1.0 feature. For example, if you ask svn diff to compare two earlier versions of /branches/mybranch/foo.c, the command will not automatically understand that the task actually requires comparing two versions of /trunk/foo.c, due to the rename. Instead, you'll see an error about how the branch-path doesn't exist in the earlier revisions.

The workaround for all problems of this sort is to do the legwork yourself. That is: you need to be aware of any renamed paths, discover them yourself using svn log -v, and then provide them explicitly to the svn client. For example, instead of running

266

Troubleshooting

$ svn diff -r 1000:2000 http://host/repos/branches/mybranch/foo.c svn: Filesystem has no item

svn: '/branches/mybranch/foo.c' not found in the repository at revision 1000

...you would instead run

$ svn diff -r1000:2000 http://host/repos/trunk/foo.c

...

267