Your repository is not corrupt, nor is your data lost. If your process accesses the repository directly (mod_dav_svn, svnlook, svnadmin, or if you access a file:// URL), then it's using Berkeley DB to access your data. Berkeley DB is a journaling system, meaning that it logs everything it is about to do before it does so. If your process is interrupted (e.g. by a kill signal or segfault), then a lockfile is left behind, along with a logfile describing unfinished business. Any other process that attempts to access the database will just hang, waiting for the lockfile to disappear. To awaken your repository, you need to ask Berkeley DB to either finish the work, or rewind the database to a previous state that is known to be consistent.

Make sure you run this command as the user that owns and manages the database, not as root, or else it will leave root-owned files in the db directory. These files cannot be opened by the non-root user that manages the database, which is typically either you or your Apache process. Also be sure to have the correct umask set when you run recover, since failing to do so will lock out users that are in the group allowed to access the repository.

Simply run:

$ svnadmin recover /path/to/repos

Once the command has completed, check the permissions in the db/ directory of the repository.

Subversion's working copy, just like Berkeley DB, uses a journaling mechanism to perform all actions. That is, it logs everything it is about to do before it does so. If svn is interrupted while performing an action, then one or more lockfiles are left behind, along with log files describing the unfinished actions. (svn status will show an L next to locked directories.)

Any other process that attempts to access the working copy will fail when it sees the locks. To awaken your working copy, you need to tell the client to finish the work. To fix this, run this command from the top of your working copy:

$ svn cleanup

See the section called “Every time I try to access my repository, my Subversion client just hangs.”.

You might also have a permissions problem opening the repository. See the section called “Supporting Multiple Repository Access Methods”.

See Repository URLs.

If import works fine over local access:

$ mkdir test
$ touch test/testfile
$ svn import test file:///var/svn/test -m "Initial import"
Adding         test/testfile
Transmitting file data .
Committed revision 1.

But not from a remote host:

$ svn import test http://svn.red-bean.com/test -m "Initial import"
harry's password: xxxxxxx

svn_error: … The specified activity does not exist.

We've seen this when the REPOS/dav/ directory is not writable by the httpd process. Check the permissions to ensure that Apache httpd can write to the dav/ directory (and to the corresponding db/ directory, of course).

You need to install Windows XP Service Pack 1 to fix a TCP/IP stack bug in the operating system. You can get all sorts of information about that Service Pack at http://support.microsoft.com/default.aspx?scid=kb;EN-US;q317949.

Use Ethereal to eavesdrop on the conversation:

Alternatively, you may set a parameter in your client's servers run-time configuration file to cause neon's debugging output to appear. The numeric value of neon-debug is a combination of the NE_DBG_* values in the header file ne_utils.h. Setting the neon-debug-mask variable to 130 (i.e. NE_DBG_HTTP + NE_DBG_HTTPBODY) will cause the HTTP data to be shown.

You may well want to disable compression when doing a network trace by tweaking the http-compression parameter in the same file.

Subversion uses a plugin system to allow access to repositories. Currently there are three of these plugins: ra_local allows access to a local repository, ra_dav allows access to a repository via WebDAV, and ra_svn allows local or remote access via the svnserve server. When you attempt to perform an operation in subversion, the program tries to dynamically load a plugin based on the URL scheme. A file:// URL will try to load ra_local, and an http:// URL will try to load ra_dav.

The error you are seeing means that the dynamic linker/loader can't find the plugins to load. This normally happens when you build subversion with shared libraries, then attempt to run it without first running 'make install'. Another possible cause is that you ran make install, but the libraries were installed in a location that the dynamic linker/loader doesn't recognize. Under Linux, you can allow the linker/loader to find the libraries by adding the library directory to /etc/ld.so.conf and running ldconfig. If you don't wish to do this, or you don't have root access, you can also specify the library directory in the LD_LIBRARY_PATH environment variable.

The short answer: it's for your own good.

Subversion places a very high priority on protecting your data, and not just your versioned data. Modifications that you make to already-versioned files, and new files scheduled for addition to the version control system, must be treated with care.

Making the svn revert command require an explicit target—even if that target is just '.'—is one way of accomplishing that. This requirement (as well as requiring you to supply the --recursive flag if you want that behavior) is intended to make you really think about what you're doing, because once your files are reverted, your local modifications are gone forever.

Your apr-util linked against DB-3, and svn linked against DB-4. Unfortunately, the DB symbols aren't different. When mod_dav_svn is loaded into Apache's process-space, it ends up resolving the symbol names against apr-util's DB-3 library.

The solution is to make sure apr-util compiles against DB-4. You can do this by passing specific switches to either apr-util's or apache's configure: "--with-dbm=db4 --with-berkeley-db=/the/db/prefix".

This is not really a problem with Subversion, but it often affects Subversion users.

RedHat 9 and Fedora ship with a Berkeley DB library that relies on the kernel support for NPTL (the Native Posix Threads Library). The kernels that RedHat provides have this support built in, but if you compile your own kernel, then you may well not have the NPTL support. If that is the case, then you will see errors like this:

svn: Berkeley DB error
svn: Berkeley DB error while creating environment for filesystem tester/db:
Function not implemented

This can be fixed in one of several ways:

If you allow anonymous write access to the repository via Apache, the Apache server never challenges the client for a username, and instead permits the write operation without authentication. Since Subversion has no idea who did the operation, this results in a log like this:

$ svn log
------------------------------------------------------------------------
rev 24:  (no author) | 2003-07-29 19:28:35 +0200 (Tue, 29 Jul 2003)
…

Read about adding authentication in Chapter 6, Server Configuration.

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.

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.

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.

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

$ 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
...