wiki
Wiki: Subversion Server FAQ

Edit this page | Links to this page | Page information | Attachments | Refresh page

 


CollabNet Subversion Client FAQ

Subversion Client FAQ -- FAQ Index -- Find Page -- Community Home

This FAQ was created by the Subversion open source community and CollabNet.


Contents

  1. General questions
    1. What is Subversion's client/server interoperability policy?
    2. What operating systems does Subversion run on?
    3. What kind of hardware do I need to run a Subversion server?
    4. I heard that Subversion is an Apache extension? What does it use for servers?
    5. Does this mean I have to set up Apache to use Subversion?
    6. I run Apache 1.x right now, and can't switch to Apache 2.0 just to serve Subversion repositories. Does that mean I can't run a Subversion server?
    7. Why does the entire repository share the same revision number? I want each of my projects to have their own revision numbers.
  2. How-to
    1. Should I store my repository on a NFS server?
    2. Why is my repository taking up so much disk space?
    3. How do I set repository permissions correctly?
    4. Why do read-only operations still need repository write access?
    5. How do I completely remove a file from the repository's history?
    6. How do I change the log message for a revision after it's been committed?
    7. What is this "dump/load cycle" people sometimes talk about when upgrading a Subversion server?
    8. How do I allow clients to authenticate against a Windows domain controller using SSPI authentication?
    9. I have a file in my project that every developer must change, but I don't want those local mods to ever be committed. How can I make 'svn commit' ignore the file?
    10. How can I set certain properties on everything in the repository? Also, how can I make sure that every new file coming into the repository has these properties?
    11. I'm managing a website in my repository. How can I make the live site automatically update after every commit?
    12. How do I run svnserve as a service on Windows?
    13. How do I convert my repository from using BDB to FSFS or from FSFS to BDB?
    14. How does Subversion handle binary files?
  3. Troubleshooting
    1. My repository seems to get stuck all the time, giving me errors about needing recovery (DB_RUNRECOVERY). What could be the cause?
    2. Every time users try to access my repository, the process just hangs. Is my repository corrupt?
    3. My repository keeps giving errors saying "Cannot allocate memory". What should I do?
    4. When I run `configure', I get errors about subs-1.sed line 38: Unterminated `s' command. What's wrong?
    5. How can I specify a Windows drive letter in a file: URL?
    6. I'm having trouble doing write operations to a Subversion repository over a network.
    7. Under Windows XP, the Subversion server sometimes seems to send out corrupted data. Can this really be happening?
    8. What is the best method of doing a network trace of the conversation between a Subversion client and server?
    9. Why does the svn revert require an explicit target? Why is it not recursive by default? These behaviors differ from almost all the other subcommands.
    10. Why doesn't HTTP Digest auth work?
    11. I am trying to use mod_dav_svn with Apache on Win32 and I'm getting an error saying that the module cannot be found, yet the mod_dav_svn.so file is right there in \Apache\modules.
    12. Why aren't my repository hooks working?
    13. Why does my --diff-cmd complain about '-u'? I tried to override it with --extensions, but it's not working.
    14. I'm getting the error "svn: bdb: call implies an access method which is inconsistent with previous calls". How do I fix this?
    15. My users get occasional, seemingly inconsistent errors when checking out over http:// from a repository running on MacOS X 10.4
    16. When performing Subversion operations involving a lot of data over SSL, I get the error SSL negotiation failed: SSL error: decryption failed or bad record mac.


General questions

What is Subversion's client/server interoperability policy?

The client and server are designed to work as long as they aren't more than one major release version apart. For example, any 1.X client will work with a 1.Y server. However, if the client and server versions don't match, certain features may not be available.

See the client/server interoperability policy is documented in the "Compatibility" section of the Hacker's Guide to Subversion.


What operating systems does Subversion run on?

All modern flavors of Unix, Win32, BeOS, OS/2, MacOS X.

Subversion is written in ANSI C and uses APR, the Apache Portable Runtime library, as a portability layer. The Subversion client will run anywhere APR runs, which is most places. The Subversion server (i.e., the repository side) is the same, except that it will not host a Berkeley DB repository on Win9x platforms (Win95/Win98/WinME), because Berkeley DB has shared-memory segment problems on Win9x. FSFS repositories (introduced in version 1.1) do not have this restriction; however, due to a limitation in Win9x's file-locking support, they also don't work in Win9x.

To reiterate, the Subversion client can be run on any platform where APR runs. The Subversion server can also be run on any platform where APR runs, but cannot host a repository on Win95/Win98/?WinMe.


What kind of hardware do I need to run a Subversion server?

Server requirements depend on many factors, such as number of users, frequency of commits and other server related operations, repository size, and the load generated by custom repository hooks. When using Apache, it is likely that Apache itself will be the biggest factor in memory usage. See this discussion on the mailing list for some concrete answers.

Remember to take in account other applications running on the same server; for example, repository browsers use resources too, independently of Subversion itself.

In general, you can expect to need much less server memory than you would for comparable CVS repositories.


I heard that Subversion is an Apache extension? What does it use for servers?

No. Subversion is a set of libraries. It comes with a command-line client that uses them. There are two different Subversion server processes: either svnserve, which is small standalone program similar to cvs pserver, or Apache httpd-2.0 using a special mod_dav_svn module. svnserve speaks a custom protocol, while mod_dav_svn uses WebDAV as its network protocol. See chapter 6 in the Subversion book to learn more.


Does this mean I have to set up Apache to use Subversion?

The short answer: no.

The long answer: if you just want to access a repository, then you only need to build a Subversion client. If you want to host a networked repository, then you need to set up either Apache2 or an "svnserve" server.

For more details about setting up a network accessible Subversion server, see chapter 6 in the Subversion book.


I run Apache 1.x right now, and can't switch to Apache 2.0 just to serve Subversion repositories. Does that mean I can't run a Subversion server?

No, you can run svnserve as a Subversion server. It works extremely well.

If you want WebDAV and all the other "goodies" that come with the Apache server, then yes, you'll need Apache 2.0. It's always an option to run Apache 2.0 on a different port while continuing to run Apache 1.x on port 80. Different versions of Apache can happily coexist on the same machine. Just change the Listen directive in httpd.conf from "Listen 80" to "Listen 8080" or whatever port number you want, and make sure to specify that port when you publish your repository URL (e.g., http://svn.mydomain.com:8080/repos/blah/trunk/).

Why does the entire repository share the same revision number? I want each of my projects to have their own revision numbers.

The global revision number attached to the repository as a whole is meaningless from a user's perspective. It's an internal mechanism that accomplishes the goal of the underlying schema design. It just so happens to be exposed so that the user's interface can sometimes be a little more convenient than always having to type obnoxiously long date/time strings.

The revision number is only relevant to the repository, and user convenience. It has no impact on any other factor of what you store in the repository. Repository revision number bumps aren't nearly useful enough to be an accurate indication of the real rate of change of a given code base. There are other more complicated ways to get a much better picture of a code-base's rate of change.


How-to

Should I store my repository on a NFS server?

If you are using a repository with the Berkeley DB back end (default for repositories created with Subversion 1.0 and 1.1, not the default thereafter), we recommend not storing the repository on a remote filesystem (for example, NFS). While Berkeley DB databases and log files can be stored on remote filesystems, the Berkeley DB shared region files cannot be stored on a remote filesystem, so the repository may be safely accessed by only a single filesystem client, and not all Subversion functionality will be available to even that one client.

If you are using the FSFS repository back end, then storing the repository on a modern NFS server (i.e., one that supports locking) should be fine.

Working copies can be stored on NFS (one common scenario is when your home directory is on a NFS server). On Linux NFS servers, due to the volume of renames used internally in Subversion when checking out files, some users have reported that 'subtree checking' should be disabled (it's enabled by default). Please see NFS Howto Server Guide and exports(5) for more information on how to disable subtree checking.

We've had at least one report of working copies getting wedged after being accessed via SMB. The server in question was running a rather old version of Samba (2.2.7a). The problem didn't recur with a newer Samba (3.0.6).


Why is my repository taking up so much disk space?

The repository stores all your data in a Berkeley DB "environment" in the repos/db/ subdirectory. The environment contains a collection of tables and bunch of logfiles (log.*). Berkeley DB journals all changes made to the tables, so that the tables can be recovered to a consistent state in case of interruptions (more info).

The logfiles will grow forever, eating up disk space, unless you, (as the repository administrator) do something about it. At any given moment, Berkeley DB is only using a few logfiles actively (see this post and its associated thread); the rest can be safely deleted. If you keep all the logfiles around forever, then in theory Berkeley DB can replay every change to your repository from the day it was born. But in practice, if you're making backups, it's probably not worth the cost in disk space.

Use svnadmin to see which log files can be deleted. You may want a cron job to do this.

$ svnadmin list-unused-dblogs /repos /repos/db/log.000003 /repos/db/log.000004 [...]

$ svnadmin list-unused-dblogs /repos | xargs rm # disk space reclaimed!

You could instead use Berkeley DB's db_archive command:

$ db_archive -a -h /repos/db | xargs rm # disk space reclaimed!

See also svnadmin hotcopy or hotbackup.py.

Note: If you use Berkeley DB 4.2, Subversion will create new repositories with automatic log file removal enabled. You can change this by passing the --bdb-log-keep option to svnadmin create. Refer to the section about the DB_LOG_AUTOREMOVE flag in the Berkeley DB manual.


How do I set repository permissions correctly?

Try to have as few users access the repository as possible. For example, run apache or 'svnserve -d' as a specific user, and make the repository wholly owned by that user. Don't allow any other users to access the repository via file:/// urls, and be sure to run 'svnlook' and 'svnadmin' only as the user which owns the repository.

If your clients are accessing via file:/// or svn+ssh://, then there's no way to avoid access by multiple users. In that case, read the last section in chapter 6, and pay particular attention to the "checklist" sidebar at the bottom. It outlines a number of steps to make this scenario safer. Note for SELinux / Fedora Core 3+ / Red Hat Enterprise users:

In addition to regular Unix permissions, under SELinux every file, directory, process, etc. has a 'security context'. When a process attempts to access a file, besides checking the Unix permissions the system also checks to see if the security context of the process is compatible with the security context of the file.

Fedora Core 3, among other systems, comes with SELinux installed by default, configured so that Apache runs in a fairly restricted security context. To run Subversion under Apache, you have to set the security context of the repository to allow Apache access (or turn off the restrictions on Apache, if you think all this is overkill). The chcon command is used to set the security context of files (similarly to how the chmod sets the traditional Unix permissions). For example, one user had to issue this command

  • $ chcon -R -h -t httpd_sys_content_t PATH_TO_REPOSITORY

to set the security context to be able to successfully access the repository.


Why do read-only operations still need repository write access?

Certain client operations are "read-only", like checkouts and updates. From an access-control standpoint, Apache treats them as such. But libsvn_fs (the repository filesystem API) still has to write temporary data in order to produce tree-deltas. So the process accessing the repository always requires both read and write access to the Berkeley DB files in order to function.

In particular, the repository responds to many "read-only" operations by comparing two trees. One tree is the usually the HEAD revision, and the other is often a temporary transaction-tree -- thus the need for write access.

This limitation only applies to the Berkeley DB backend; the FSFS backend does not exhibit this behavior.


How do I completely remove a file from the repository's history?

There are special cases where you might want to destroy all evidence of a file or commit. (Perhaps somebody accidentally committed a confidential document.) This isn't so easy, because Subversion is deliberately designed to never lose information. Revisions are immutable trees which build upon one another. Removing a revision from history would cause a domino effect, creating chaos in all subsequent revisions and possibly invalidating all working copies.

The project has plans, however, to someday implement an svnadmin obliterate command which would accomplish the task of permanently deleting information. (See issue 516.)

In the meantime, your only recourse is to svnadmin dump your repository, then pipe the dumpfile through svndumpfilter (excluding the bad path) into an svnadmin load command. See chapter 5 of the Subversion book for details about this.


How do I change the log message for a revision after it's been committed?

Log messages are kept in the repository as properties attached to each revision. By default, the log message property (svn:log) cannot be edited once it is committed. That is because changes to revision properties (of which svn:log is one) cause the property's previous value to be permanently discarded, and Subversion tries to prevent you from doing this accidentally. However, there are a couple of ways to get Subversion to change a revision property.

The first way is for the repository administrator to enable revision property modifications. This is done by creating a hook called "pre-revprop-change" (see this section in the Subversion book for more details about how to do this). The "pre-revprop-change" hook has access to the old log message before it is changed, so it can preserve it in some way (for example, by sending an email). Once revision property modifications are enabled, you can change a revision's log message by passing the --revprop switch to svn propedit or svn propset, like either one of these:

$ svn propedit -r N --revprop svn:log URL $ svn propset -r N --revprop svn:log "new log message" URL

where N is the revision number whose log message you wish to change, and URL is the location of the repository. If you run this command from within a working copy, you can leave off the URL.

The second way of changing a log message is to use svnadmin setlog. This must be done by referring to the repository's location on the filesystem. You cannot modify a remote repository using this command.

$ svnadmin setlog REPOS_PATH -r N FILE

where REPOS_PATH is the repository location, N is the revision number whose log message you wish to change, and FILE is a file containing the new log message. If the "pre-revprop-change" hook is not in place (or you want to bypass the hook script for some reason), you can also use the --bypass-hooks option. However, if you decide to use this option, be very careful. You may be bypassing such things as email notifications of the change, or backup systems that keep track of revision properties.


What is this "dump/load cycle" people sometimes talk about when upgrading a Subversion server?

Subversion's repository database schema has changed occasionally during development. Old repositories, created with a pre-1.0 development version of Subversion, may require the following operation when upgrading. If a schema change happens between Subversion releases X and Y, then repository administrators upgrading to Y must do the following:

  1. Shut down svnserve, Apache, and anything else that might be accessing the repository.
  2. svnadmin dump /path/to/repository > dumpfile.txt , using version X of svnadmin.

  3. mv /path/to/repository /path/to/saved-old-repository
  4. Now upgrade to Subversion Y (i.e., build and install Y, replacing X).
  5. svnadmin create /path/to/repository, using version Y of svnadmin.
  6. svnadmin load /path/to/repository < dumpfile.txt , again using version Y of svnadmin.

  7. Copy over hook scripts, etc, from the old repository to the new one.
  8. Restart svnserve, Apache, etc.

See http://svnbook.red-bean.com/html-chunk/ch05s03.html#svn-ch-5-sect-3.4 for more details on dumping and loading.

Note: Most upgrades of Subversion do not involve a dump and load. When one is required, the release announcement and the CHANGES file for the new version will carry prominent notices about it. If you don't see such a notice, then there has been no schema change, and no dump/load is necessary.


How do I allow clients to authenticate against a Windows domain controller using SSPI authentication?

TortoiseSVN has an excellent document that describes setting up a Subversion server on Windows. Go to http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-serversetup.html#tsvn-serversetup-apache-5, to see the section on SSPI authentication.

An important part of the configuration is the line:

  • SSPIOfferBasic On

Without this line, browsers that support SSPI will prompt for the user's credentials, but clients that do not suppport SSPI such as Subversion will not prompt. (The current release of Neon - Subversion's HTTP library - handles only basic authentication.) Because the client never asks for credentials, any action that requires authentication will fail. Adding this line tells mod_auth_sspi to use basic authentication with the client, but to use the Windows domain controller to authenticate the credentials.


I have a file in my project that every developer must change, but I don't want those local mods to ever be committed. How can I make 'svn commit' ignore the file?

The answer is: don't put that file under version control. Instead, put a template of the file under version control, something like "file.tmpl".

Then, after the initial 'svn checkout', have your users (or your build system) do a normal OS copy of the template to the proper filename, and have users customize the copy. The file is unversioned, so it will never be committed. And if you wish, you can add the file to its parent directory's svn:ignore property, so it doesn't show up as '?' in the 'svn status' command.


How can I set certain properties on everything in the repository? Also, how can I make sure that every new file coming into the repository has these properties?

Subversion will not change a file's contents by default; you have to deliberately set the svn:eol-style or svn:keywords property on a file for that to happen. That makes Subversion a lot safer than CVS's default behavior, but with that safety comes some inconvenience.

Answering the first question: to set properties on all files already in the repository, you'll need to do it the hard way. All you can do is run svn propset on every file (in a working copy), and then svn commit. Scripting can probably help you with this.

But what about future files? Unfortunately, there's no server mechanism to automatically set properties on files being committed. This means that all of your users need to remember to set certain properties whenever they svn add a file. Fortunately, there's a client-side tool to help with this. Read about the auto-props feature in the book. You need to make sure all your users configure their clients' auto-props settings appropriately.

You could write a pre-commit hook script to reject any commit which forgets to add properties to new files (see http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/check-mime-type.pl for example). However, this approach may be overkill. If somebody forgets to set svn:eol-style, for example, it will be noticed the minute somebody else opens the file on a different OS. Once noticed, it's easy to fix: just set the property and commit.

Note: many users have asked for a feature whereby the server automatically "broadcasts" run-time settings to clients, such as auto-props settings. There's already a feature request filed for this (issue 1974), though this feature is still being debated by developers, and isn't being worked on yet.


I'm managing a website in my repository. How can I make the live site automatically update after every commit?

This is done all the time, and is easily accomplished by adding a post-commit hook script to your repository. Read about hook scripts in Chapter 5 of the book. The basic idea is to make the "live site" just an ordinary working copy, and then have your post-commit hook script run 'svn update' on it.

In practice, there are a couple of things to watch out for. The server program performing the commit (svnserve or apache) is the same program that will be running the post-commit hook script. That means that this program must have proper permissions to update the working copy. In other words, the working copy must be owned by the same user that svnserve or apache runs as -- or at least the working copy must have appropriate permissions set.

If the server needs to update a working copy that it doesn't own (for example, user joe's ~/public_html/ area), one technique is create a +s binary program to run the update, since Unix won't allow scripts to run +s. Compile a tiny C program:

#include <stddef.h> #include <stdlib.h> #include <unistd.h> int main(void) {

  • execl("/usr/local/bin/svn", "svn", "update", "/home/joe/public_html/",
    • (const char *) NULL);
    return(EXIT_FAILURE);

}

... and then chmod +s the binary, and make sure it's owned by user 'joe'. Then in the post-commit hook, add a line to run the binary.

If you have problems getting the hook to work, see "Why aren't my repository hooks working?".

Also, you'll probably want to prevent apache from exporting the .svn/ directories in the live working copy. Add this to your httpd.conf:

# Disallow browsing of Subversion working copy administrative dirs. <?DirectoryMatch "^/.*/\.svn/">

  • Order deny,allow Deny from all

<?/DirectoryMatch>


How do I run svnserve as a service on Windows?

For versions 1.4.0 and later, you can find instructions here.

CollabNet Subversion and click the svnserve checkbox when installing.


How do I convert my repository from using BDB to FSFS or from FSFS to BDB?

There are three steps:

  1. A dump/load from the old format to the new one.
  2. Copy the hook scripts.
  3. Copy the configuration files.

Say you have a repository /svn/myrepos which is using the BDB backend and you would like to switch to using the FSFS backend:

  1. Close down your server so that the data cannot change during this procedure.
  2. Make a new repository specifying the fsfs backend (it is the default from 1.2 onwards), e.g., svnadmin create /svn/myreposfsfs --fs-type fsfs.
  3. Pipe the output of a dump from /svn/myrepos to the input of a load into /svn/myreposfsfs, e.g., svnadmin dump /svn/myrepos -q | svnadmin load /svn/myreposfsfs. Windows users should dump to a file and load from that file in two separate steps.
  4. Copy any hook scripts which are active in /svn/myrepos/hooks into /svn/myreposfsfs/hooks. Don't mindlessly copy everything, the templates generated by Subversion may have changed.
  5. Compare the template scripts which the svnadmin create command put in /svn/myreposfsfs/hooks with those in /svn/myrepos/hooks and incorporate any changes which you would like into your active hook scripts.
  6. Copy configuration files from /svn/myrepos/conf into /svn/myreposfsfs/conf (and don't forget a password file, if you use one). Or you might instead want to merge the changes that you made to your configuration files into the new default ones.
  7. Rename /svn/myrepos to /svn/myreposbdb and then /svn/myreposfsfs to /svn/myrepos ensuring that the file permissions are the same as those that the BDB version had.
  8. Restart the server.

Once you are happy that all is well with your new repository delete the old one.

To do the reverse and migrate from FSFS to BDB change the svnadmin create command to specify BDB.


How does Subversion handle binary files?

When you first add or import a file into Subversion, the file is examined to determine if it is a binary file. Currently, Subversion just looks at the first 1024 bytes of the file; if any of the bytes are zero, or if more than 15% are not ASCII printing characters, then Subversion calls the file binary. This heuristic might be improved in the future, however.

If Subversion determines that the file is binary, the file receives an svn:mime-type property set to "application/octet-stream". (You can always override this by using the auto-props feature or by setting the property manually with svn propset.)

Subversion treats the following files as text:

  • Files with no svn:mime-type
  • Files with a svn:mime-type starting "text/"
  • Files with a svn:mime-type equal to "image/x-xbitmap"
  • Files with a svn:mime-type equal to "image/x-xpixmap"

All other files are treated as binary, meaning that Subversion will:

  • Not attempt to automatically merge received changes with local changes during svn update or svn merge
  • Not show the differences as part of svn diff
  • Not show line-by-line attribution for svn blame

In all other respects, Subversion treats binary files the same as text files, e.g. if you set the svn:keywords or svn:eol-style properties, Subversion will perform keyword substitution or newline conversion on binary files.

Note that whether or not a file is binary does not affect the amount of repository space used to store changes to that file, nor does it affect the amount of traffic between client and server. For storage and transmission purposes, Subversion uses a diffing method that works equally well on binary and text files; this is completely unrelated to the diffing method used by the 'svn diff' command.


Troubleshooting

My repository seems to get stuck all the time, giving me errors about needing recovery (DB_RUNRECOVERY). What could be the cause?

The Berkeley DB database in your repository is sensitive to interruptions. If a process accessing the database exits without "cleanly" closing the environment, then the database is left in an inconsistent state. Common causes of this include:

  • the process exiting when it hits a permission problem
  • the process crashing/segfaulting
  • the process being forcibly killed
  • running out of disk space

For most of these cases, you should run "svnadmin recover", which rewinds the repository back to a consistent state; see this question for details. Note that running out of disk space, combined with frequent checkouts or updates, can cause the repository to crash in a way where recovery is not possible (so keep backups).

Segfaults, forced killings, and running out of disk space are pretty rare. Permission problems are far more common: one process accesses the repository and accidentally changes ownership or permissions, then another process tries to access and chokes on the permissions.

The best way to prevent this is to get your repository permissions and ownership set up correctly. See here for our recommendations.


Every time users try to access my repository, the process just hangs. Is my repository corrupt?

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 (Control-C, 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.

WARNING: you can seriously corrupt your repository if you run recover and another process accesses the repository.

Make absolutely sure you disable all access to the repository before doing this (by shutting down Apache, removing executable permissions from 'svn'). Make sure you run this command as the user that owns and manages the database, and not as root, else it will leave root-owned files in the db directory which 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.

Sometimes "svnadmin recover" doesn't work. You may see it give errors like this:

  • Repository lock acquired. Please wait; recovering the repository may take some time... svnadmin: DB_RUNRECOVERY: Fatal error, run database recovery svnadmin: bdb: Recovery function for LSN 175 7066018 failed on backward pass svnadmin: bdb: PANIC: No such file or directory svnadmin: bdb: PANIC: fatal region error detected; run recovery

or like this:

  • Repository lock acquired. Please wait; recovering the repository may take some time... svn: DB_RUNRECOVERY: Fatal error, run database recovery

    svn: bdb: DB_ENV->log_flush: LSN of 115/802071 past current end-of-log of 115/731460 svn: bdb: Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment [...] svn: bdb: changes: unable to flush page: 0 svn: bdb: txn_checkpoint: failed to flush the buffer cache Invalid argument svn: bdb: PANIC: Invalid argument svn: bdb: PANIC: fatal region error detected; run recovery svn: bdb: PANIC: fatal region error detected; run recovery [...]

In that case, try Berkeley DB's native db_recover utility (see db_recover documentation). It usually lives in a "bin/" subdirectory of the Berkeley DB installation, for example if you installed Berkeley DB from source, it might be /usr/local/BerkeleyDB.4.2/bin/db_recover; or on systems where Berkeley DB comes prepackaged it might just be /usr/bin/db_recover. If you have multiple versions of Berkeley DB installed, make sure that the version of db_recover you use matches the version of Berkeley DB with which your repository was created.

Run db_recover with the "-c" ("catastrophic recovery") flag. You can also add "-v" for verbosity, and "-h" with an argument telling it what db environment to recover (so you don't have to cd into that directory). Thus:

  • db_recover -c -v -h /path/to/repos/db

Run this command as the same user that owns the repository, and again, make absolutely sure that no other processes are accessing the repository while you do this (e.g., shut down svnserve or Apache).


My repository keeps giving errors saying "Cannot allocate memory". What should I do?

If you're using http:// access, "Cannot allocate memory" errors show up in the httpd error log and look something like this:

  • [Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227] (20014) Error string not specified yet: Berkeley DB error while opening 'strings' table for filesystem /usr/local/svn/repositories/svn/db: Cannot allocate memory [Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227] Could not fetch resource information. [500, #0] [Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227] Could not open the requested SVN filesystem [500, #160029] [Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227] (17) File exists: Could not open the requested SVN filesystem [500, #160029]

It usually means that a Berkeley DB repository has run out of database locks (this does not happen with FSFS repositories). It shouldn't happen in the course of normal operations, but if it does, the solution is to run database recovery as described here. If it happens often, you probably need to raise the default lock parameters (set_lk_max_locks, set_lk_max_lockers, and set_lk_max_objects) in the db/DB_CONFIG file. When changing DB_CONFIG in an existing repository, remember to run recovery afterwards.


When I run `configure', I get errors about subs-1.sed line 38: Unterminated `s' command. What's wrong?

You probably have old copies of /usr/local/bin/apr-config and /usr/local/bin/apu-config on your system. Remove them, make sure the apr/ and apr-util/ that you're building with are completely up-to-date, and try again.


How can I specify a Windows drive letter in a file: URL?

Like this:

svn import file:///d:/some/path/to/repos/on/d/drive

See Repository URLs in the Subversion Book for more details. VS.NET/ASP.NET seems to have a problem with the ".svn" directory name. What should I do?

VS.Net has a subsystem called ASP.Net, which uses WebDAV to do remote publishing through IIS. This subsystem rejects any pathname that starts with ".". This causes a problem when you try to remotely publish a Subversion working copy, because of the ".svn" subdirectories. The error message says something like "unable to read project information".

To work around this, set the environment variable SVN_ASP_DOT_NET_HACK to any value — this will tell Windows clients to use "_svn" as a directory name in your working copy. See the relevant section of the Subversion 1.3 release notes for more details, and see this question for other ways to customize the administrative directory name.


I'm having trouble doing write operations to a Subversion repository over a network.

For example, one user reported that imports worked 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 http://svn.sabi.net/test testfile -m "import" nicholas's password: xxxxxxx

    svn_error: #21110 : <Activity not found> 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 Apache can write to the dav/ directory (and to db/, of course).


Under Windows XP, the Subversion server sometimes seems to send out corrupted data. Can this really be happening?

You need to install Window XP Service Pack 1. You can get all sorts of information about that Service Pack here:


What is the best method of doing a network trace of the conversation between a Subversion client and server?

Use Wireshark (formerly known as "Ethereal") to eavesdrop on the conversation.

First, make sure that between captures within the same wireshark session, you hit Clear, otherwise filters from one capture (say, an HTTP capture) might interfere with others (say, an ra_svn capture).

Assuming you're cleared, then:

1. Pull down the Capture menu, and choose Capture Filters. 2. If debugging the http:// (WebDAV) protocol, then in the window that pops up, choose "HTTP TCP port (80)" (which should result in the filter string "tcp port http").

If debugging the svn:// (ra_svn) protocol, then choose New, give the new filter a name (say, "ra_svn"), and type "tcp port 3690" into the filter string box.

When done, click OK.

3. Again go to the Capture menu, this time choose Interfaces, and click Options next to the appropriate interface (probably you want interface "lo", for "loopback", assuming the server will run on the same machine as the client).

4. Turn off promiscuous mode by unchecking the appropriate checkbox.

5. Click the Start button in the lower right to start the capture.

6. Run your Subversion client.

7. Click the Stop icon (a red X over an ethernet interface card) when the operation is finished (or Capture->Stop should work). Now you have a capture. It looks like a huge list of lines.

8. Click on the Protocol column to sort.

9. Then, click on the first relevant line to select it; usually this is just the first line.

10. Right click, and choose Follow TCP Stream. You'll be presented with the request/response pairs of the Subversion client's HTTP conversion.

The above instructions are specific to the graphical version of Wireshark (version 0.99.6), and don't apply to the command-line version known as "tshark" (which corresponds to "tethereal", from back when Wireshark was called Ethereal).

Alternatively, you may set the neon-debug-mask parameter in your servers configuration file to cause neon's debugging output to appear when you run the svn client. The numeric value of neon-debug-mask is a combination of the NE_DBG_... values in the header file ne_utils.h. For current versions of neon, setting neon-debug-mask 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—see the http-compression parameter in the servers configuration file.

Another alternative is to set up a logging proxy between the Subversion client and server. A simple way to do this is to use the socat program. For example, to log communication with an svnserve instance, run the following command:

socat -v TCP4-LISTEN:9630,reuseaddr,fork TCP4:localhost:svn

Then run your svn commands using an URL base of svn://127.0.0.1:9630/; socat will forward the traffic from port 9630 to the normal svnserve port (3690), and will print all traffic in both directions to standard error, prefixing it with < and > signs to show the direction of the traffic.


Why does the svn revert require an explicit target? Why is it not recursive by default? These behaviors differ from almost all the other subcommands.

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 (-R) 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. When I start Apache, mod_dav_svn complains about a "bad database version", that it found db-3.X, rather than db-4.X.

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


Why doesn't HTTP Digest auth work?

This is probably due to a known bug in Apache HTTP Server (versions 2.0.48 and earlier), for which a patch is available, see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25040. You may also want to read over http://subversion.tigris.org/issues/show_bug.cgi?id=1608 to see if the description there matches your symptoms.


I am trying to use mod_dav_svn with Apache on Win32 and I'm getting an error saying that the module cannot be found, yet the mod_dav_svn.so file is right there in \Apache\modules.

The error message in this case is a little misleading. Most likely Apache is unable to load one or more DLLs that mod_dav_svn.so relies on. If Apache is running as a service it will not have the same PATH as a regular user. Make sure that libdb4*.dll, intl3_svn.dll, libeay32.dll and ssleay32.dll are present in either \Apache\bin or \Apache\modules. You can copy them from your Subversion installation directory if they are not there.

If this still does not resolve the problem, you should use a tool like Dependency Walker on mod_dav_svn.so to see if there are any other unresolved dependencies.


Why aren't my repository hooks working?

They're supposed to invoke external programs, but the invocations never seem to happen.

Before Subversion calls a hook script, it removes all variables -- including $PATH on Unix, and %PATH% on Windows -- from the environment. Therefore, your script can only run another program if you spell out that program's absolute name.

Debugging tips:

If you're using Linux or Unix, try running the script "by hand", by following these steps:

1. Use "su", "sudo", or something similar, to become the user who normally would run the script. This might be httpd or www-data, for example, if you're using Apache; it might be a user like svn if you're running svnserve and a special Subversion user exists. This will make clear any permissions problems that the script might have.

2. Invoke the script with an empty environment by using the "env" program. Here's an example for the post-commit hook:

$ env - ./post-commit /var/lib/svn-repos 1234

Note the first argument to "env" is a dash; that's what ensures the environment is empty.

3. Check your console for errors.


Why does my --diff-cmd complain about '-u'? I tried to override it with --extensions, but it's not working.

When using an external diff command, Subversion builds a fairly complicated command line. First is the specified --diff-cmd. Next comes the specified --extensions (although empty --extensions are ignored), or '-u' if --extensions is unspecified (or specified as ). Third and fourth, Subversion passes a '-L' and the first file's label (e.g. "project_issues.html (revision 11209)"). Fifth and sixth are another '-L' and the second label. Seventh and eighth are the first and second file names (e.g. ".svn/text-base/project_issues.html.svn-base" and ".svn/tmp/project_issues.html.tmp").

If your preferred diff command does not support these arguments, you may need to create a small wrapper script to discard arguments and just use the last couple file paths.

Warning: Beware that Subversion does not expect the external diff program to change the files it receives, and doing so may scramble the working copy.

For further information, see issue #2044.


I'm getting the error "svn: bdb: call implies an access method which is inconsistent with previous calls". How do I fix this?

Berkeley DB 4.1 has shown itself to be rather unstable - both 4.0 and 4.2 are better. This error message is a symptom of one unique way in which 4.1 will sometimes break.

The problem is that the database format field for one of the tables that make up a Subversion repository using the Berkeley DB backend has become corrupted. For unknown reasons, this is almost always the 'copies' table, which switches from the 'btree' type to the 'recno' type. Simple recovery procedures are outlined below - if they do not succeed, you should contact the Subversion Users mailing list.

  • Ensure that no other processes will attempt to access your repository.
  • Now, back up your repository to a tar or zip file or similar.
  • Change to the db subdirectory of your repository.
  • rm db.* log.*

  • db_dump -p -r copies > copies.dump

  • Now edit copies.dump. In the section near the top, change "type=recno" to "type=btree", and delete the line beginning "re_len=".
  • rm copies
  • db_load copies < copies.dump

  • svnadmin dump .. > ../../my-recovered.svndump

  • Now create a new repository, reload the dump file just produced, and copy across any custom hooks or configuration. Verify that the highest revision number in the new repository is what you think it should be.

I can't hotbackup my repository, svnadmin fails on files larger than 2Gb!

Early versions of APR on its 0.9 branch, which Apache 2.0.x and Subversion 1.x use, have no support for copying large files (2Gb+). A fix which solves the 'svnadmin hotcopy' problem has been applied and is included in APR 0.9.5+ and Apache 2.0.50+. The fix doesn't work on all platforms, but works on Linux.


My users get occasional, seemingly inconsistent errors when checking out over http:// from a repository running on MacOS X 10.4

Note: this assumes the repository is being served by Apache 2.0.x.

There is a bug in APR 0.9.6 that is present when it is running on Tiger, and shows up when you attempt to check out a file larger than 64Kb. The resulting checkout fails, often with unpredictable error messages. Here are some examples of what you might see on the client side, the specific errors may differ for you:

  • svn: Invalid diff stream: [tgt] insn 1 starts beyond the target view position svn: Unexpected end of svndiff input svn: REPORT request failed on '/path/to/repository' svn: REPORT of '/path/to/repository/!svn/vcc/default': Chunk delimiter was invalid

There may also be errors in the Apache error_log, such as:

  • [error] Provider encountered an error while streaming a REPORT response. [500, #0] [error] A failure occurred while driving the update report editor [500, #190004]

To confirm the presence of this bug — assuming you have access to the machine that the repository is being served from — try checking out using a file:// URL, which will access the filesystem directly instead of going through Apache. If the resulting checkout completes successfully, then it is almost certain that this is the problem.

Currently, the best solution is to upgrade to APR 1.2.0+.

Alternately, you can rebuild Apache and Subversion from their respective sources, setting the following environment variable before running configure for Apache:

  • setenv ac_cv_func_poll no

or in Bourne shell syntax, like this:

  • ac_cv_func_poll=no; export ac_cv_func_poll

If you built APR / APRUTIL separately (i.e., you did not use the ones that come as part of the Apache tarball), you must set that environment variable before running configure for APR, as this is where the problem lies.


When performing Subversion operations involving a lot of data over SSL, I get the error SSL negotiation failed: SSL error: decryption failed or bad record mac.

This can occur due to a problem with OpenSSL 0.9.8. Downgrading to an older version (or possibly upgrading to a newer version) is known to fix this issue.

>> Subversion Client FAQ.

Subversion Server FAQ (last edited 2008-04-29 18:56:42 -0800 by ?ghaarmans)