SVN locked & Missing pristine files in SVN working copy

Missing pristine files in SVN working copy

Posted on June 20, 2012

In SVN 1.7 working copy format all SVN-specific information is kept in .svn/wc.db database and pristine files in .svn/pristine directory.

$ ls -a
...  anotherFile  file  .svn

$ find .svn
.svn
.svn/format
.svn/entries
.svn/wc.db
.svn/tmp
.svn/pristine
.svn/pristine/da
.svn/pristine/da/da39a3ee5e6b4b0d3255bfef95601890afd80709.svn-base

Pristine file is an analog of Git blob. SHA-1 of contents of any pristine file corresponds to its name. da39a3ee5e6b4b0d3255bfef95601890afd80709 corresponds to empty contents.

.svn/wc.db is an SQLite database that contains all SVN-specific metadata (path, URLs, properties and so on). The most interesting table is NODES. It contains entries for every path in the working copy (1 entry if the path is not changed, more than 1 otherwise).

$ sqlite3 .svn/wc.db
SQLite version 3.7.112012-03-2011:35:50Enter".help"for instructions
Enter SQL statements terminated with a ";"

sqlite>.tables
ACTUAL_NODE    NODES          PRISTINE       WC_LOCK
EXTERNALS      NODES_BASE     REPOSITORY     WORK_QUEUE
LOCK           NODES_CURRENT  WCROOT

sqlite>select local_relpath, revision, checksum from NODES;|0|
file|1|$sha1$da39a3ee5e6b4b0d3255bfef95601890afd80709
anotherFile|2|$sha1$da39a3ee5e6b4b0d3255bfef95601890afd80709

As one can see there’re 3 entries: for working copy root (“”) and 2 for files in it. And contents is referenced by SHA-1 hash.

For some reasons SVN keeps references count for every SHA-1 checksum instead of calculation on-the-fly.

sqlite>select checksum, size, refcount, md5_checksum from PRISTINE;
$sha1$da39a3ee5e6b4b0d3255bfef95601890afd80709|0|2|$md5 $d41d8cd98f00b204e9800998ecf8427e

Here in the example one checksum is referenced twice. When the refcount in PRISTINEtable becomes 0, corresponding pristine files are not deleted automatically, but only after"svn cleanup" command.

Every software contains a bug. Sometime refcount becomes wrong. If it is greater than actual value, it is not a problem. But if less, it can lead to a problem.

One won’t notice the problem immediately, but the working copy becomes a time bomb.refcount value may reach zero but some entries can still reference to a pristine file bySHA-1 checksum. If one runs "svn cleanup" and the pristine file is deleted, there’re problems: one can’t commit the file referencing to missing pristine, one can’t revert it, one can’t get working copy diff and so on.

Let’s emulate the problem:

sqlite> update PRISTINE set refcount=0;

$ svn cleanup
svn: E155010:Pristine text 'da39a3ee5e6b4b0d3255bfef95601890afd80709'not present

$ find .svn/pristine/.svn/pristine/.svn/pristine/da

Now our working copy is corrupted. It is locked (because "svn cleanup" failed) and consequent cleanups do not help.

$ echo text > file

$ svn diff
svn: E155010:Pristine text 'da39a3ee5e6b4b0d3255bfef95601890afd80709'not present

$ svn cleanup
svn: E155010:Pristine text 'da39a3ee5e6b4b0d3255bfef95601890afd80709'not present

$ svn status
  L     .
svn: E155010:Pristine text 'da39a3ee5e6b4b0d3255bfef95601890afd80709'not present

Despite the fact that the problem is not so hard to resolve (and I hope SVN will be able to repair this some day), currently I know only one tool that allows to restore missing pristine files — SmartSVN. Unfortunately it is not free. Fortunately it has 30 days free period, that’s enough to repair the working copy.

To repair our working copy select Modify | Validate Admin Area...

Repair pristine files with SmartSVN

Lets check the result.

$ find .svn/pristine/.svn/pristine/.svn/pristine/da
.svn/pristine/da/da39a3ee5e6b4b0d3255bfef95601890afd80709.svn-base

$ sqlite3 .svn/wc.db
SQLite version 3.7.112012-03-2011:35:50Enter".help"for instructions
Enter SQL statements terminated with a ";"

sqlite>select*from PRISTINE;
$sha1$da39a3ee5e6b4b0d3255bfef95601890afd80709||0|2|$md5 $d41d8cd98f00b204e9800998ecf8427e

$ svn diff
Index: file
===================================================================--- file        (revision 1)+++ file        (working copy)@@-0,0+1@@+text

Our working copy is repaired and unlocked, local changes are untouched.

refer to :http://vcs.atspace.co.uk/2012/06/20/missing-pristines-in-svn-working-copy/