What is a wedged repository and why does it happen?

A Subversion repository consists of two different internal parts, a working compartment and a storage compartment. A wedged repository is a repository where the working compartment is inaccessible for some reason, but the storage compartment is intact. Therefore, a wedged repository has not suffered any loss of data, but the working compartment has to be corrected before you can access the repository.

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 exits when it hits a permission problem
• The process crashes/segfaults
• The process is forcibly killed
• Running out of disk space

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 (apache or svnserve), and running out of disk space are pretty rare but do happen.

The Berkeley database (as of 4.4.x - see links below for more information) has a mechanism called DB_REGISTER, which helps the database to auto-recover when it encounters these benign crashes. However, sometimes that mechanism does not solve the problem. For most of these cases, manually running svnadmin recover rewinds the repository back to a consistent state. See the link below for details.

For onsite installations, permission problems are far more common. For instance, 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.

For hosted installations, application crashes are the most common reason for the subversion service process to crash, and repository checking must be completed before the application is completely restarted. This is a rare occurrence.

Some links that support this solution and provide more information appear below.