Folks,
we recently encountered a server crash and needed to restore the state
of one of our repositories using our backups. Here is what we did:
- For weekly backup purposes, we use svnadmin hotcopy to create a copy
of the repo on the most recent revision. We remember the revision
number.
- We run svnadmin dump --incremental --revision from:to for the daily
backups.
Now, restoring the repo should be as simply as copying the copy
generated by hotcopy back to the desired location, then do a svnadmin
load from the most recent daily backup.
While this worked fine during out tests, we have now observed something
that we think is wrong:
svnadmin load imported several transactions fine, then stopped with
"Cannot verify lock on path '%s'; no username available"
We identified that svnadmin load was trying to commit a file in a
transaction associated with user B, while the repository was still
assuming that the file was locked by user A. We were able to recover
from this problem by running svnadmin rmlocks prior to svnadmin load.
We tracked this down to the following sequence of events:
- User A had locked the file
- svnadmin hotcopy was run
- User A had unlocked the file (*), and didn't commit any changes
- User B has locked the file (*)
- User B has committed changes to the file
- svnadmin dump was run
In my eyes, there are two issues here:
- The error message is misleading. Shouldn't it be "Cannot verify lock
on path '%s'; no matching lock-token available"? One cannot specify a
username for svnadmin load.
- Shouldn't the actions marked (*) be part of the information that is
contained in the dump file?
Comments welcome,
Marcus
Dionex Softron GmbH
Rechtsform: Gesellschaft mit beschrankter Haftung
Sitz der Gesellschaft: Germering
Geschaftsfuhrer: Dr. Peter Jochum
Zustandiges Registergericht: Amtsgericht Munchen, HRB 717 65
Received on 2008-03-03 17:52:58 CET