Version Control with Subversion - Repository Maintenance - Repository Recovery
As mentioned in
the section called “Berkeley DB”, a
Berkeley DB repository can sometimes be left in frozen state
if not closed properly. When this happens, an administrator
needs to rewind the database back into a consistent
In order to protect the data in your repository, Berkeley
DB uses a locking mechanism. This mechanism ensures that
portions of the database are not simultaneously modified by
multiple database accessors, and that each process sees the
data in the correct state when that data is being read from
the database. When a process needs to change something in the
database, it first checks for the existence of a lock on the
target data. If the data is not locked, the process locks the
data, makes the change it wants to make, and then unlocks the
data. Other processes are forced to wait until that lock is
removed before they are permitted to continue accessing that
section of the database.
In the course of using your Subversion repository, fatal
errors (such as running out of disk space or available memory)
or interruptions can prevent a process from having the chance to
remove the locks it has placed in the database. The result is
that the back-end database system gets “wedged”.
When this happens, any attempts to access the repository hang
indefinitely (since each new accessor is waiting for a lock to
go away—which isn't going to happen).
First, if this happens to your repository, don't panic.
The Berkeley DB filesystem takes advantage of database
transactions and checkpoints and pre-write journaling to
ensure that only the most catastrophic of events
can permanently destroy a database environment. A
sufficiently paranoid repository administrator will be making
off-site backups of the repository data in some fashion, but
don't call your system administrator to restore a backup tape
Secondly, use the following recipe to attempt to
“unwedge” your repository:
Make sure that there are no processes accessing (or
attempting to access) the repository. For networked
repositories, this means shutting down the Apache HTTP
Become the user who owns and manages the repository.
This is important, as recovering a repository while
running as the wrong user can tweak the permissions of the
repository's files in such a way that your repository will
still be inaccessible even after it is
Run the command
. You should see output like
Repository lock acquired.
Please wait; recovering the repository may take some time...
The latest repos revision is 19.
This command may take many minutes to complete.
Restart the Subversion server.
This procedure fixes almost every case of repository
lock-up. Make sure that you run this command as the user that
owns and manages the database, not just as
root. Part of the recovery process might
involve recreating from scratch various database files (shared
memory regions, for example). Recovering as
root will create those files such that they
are owned by
root, which means that even
after you restore connectivity to your repository, regular
users will be unable to access it.
If the previous procedure, for some reason, does not
successfully unwedge your repository, you should do two
things. First, move your broken repository out of the way and
restore your latest backup of it. Then, send an email to the
Subversion user list (at
[email protected]>) describing your
problem in detail. Data integrity is an extremely high
priority to the Subversion developers.
[an error occurred while processing this directive]