Version Control with Subversion - Login

Repository AdministrationTo protect the data in your repository, Berkeley DB uses a locking mechanism. This mechanismensures that portions of the database are not simultaneously modified by multipledatabase accessors, and that each process sees the data in the correct state when thatdata is being read from the database. When a process needs to change something in thedatabase, it first checks for the existence of a lock on the target data. If the data is notlocked, the process locks the data, makes the change it wants to make, and then unlocksthe data. Other processes are forced to wait until that lock is removed before they are permittedto continue accessing that section of the database. (This has nothing to do with thelocks that you, as a user, can apply to versioned files within the repository; we try to clearup the confusion caused by this terminology collision in the sidebar The Three Meanings of“Lock”.)In the course of using your Subversion repository, fatal errors or interruptions can preventa process from having the chance to remove the locks it has placed in the database. Theresult is that the backend database system gets “wedged.” When this happens, any attemptsto access the repository hang indefinitely (since each new accessor is waiting for alock to go away—which isn't going to happen).If this happens to your repository, don't panic. The Berkeley DB filesystem takes advantageof database transactions, checkpoints, and prewrite journaling to ensure that only the mostcatastrophic of events 8 can permanently destroy a database environment. A sufficientlyparanoid repository administrator will have made off-site backups of the repository data insome fashion, but don't head off to the tape backup storage closet just yet.Instead, use the following recipe to attempt to “unwedge” your repository:1. Make sure no processes are accessing (or attempting to access) the repository. For networkedrepositories, this also means shutting down the Apache HTTP Server or svnservedaemon.2. Become the user who owns and manages the repository. This is important, as recoveringa repository while running as the wrong user can tweak the permissions of the repository'sfiles in such a way that your repository will still be inaccessible even after it is“unwedged.”3. Run the command svnadmin recover /var/svn/repos. You should see outputsuch as this:Repository lock acquired.Please wait; recovering the repository may take some time...Recovery completed.The latest repos revision is 19.This command may take many minutes to complete.4. Restart the server process.This procedure fixes almost every case of repository wedging. Make sure that you run thiscommand as the user that owns and manages the database, not just as root. Part of therecovery process might involve re-creating from scratch various database files (sharedmemory regions, e.g.). Recovering as root will create those files such that they are ownedby root, which means that even after you restore connectivity to your repository, regularusers 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 directory aside (perhaps8 For example, hard drive + huge electromagnet = disaster.139