Missing pristine files in SVN working copyPosted on June 20,201 2
In SVN 1.7 working copy format all SVN-specific information is kept in. Svn/wc. dbDatabase and pristine files in. Svn/pristineDirectory.
$ 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-1Of contents of any pristine file corresponds to its name.Da39a3ee5e6b4b0d3255bfef95601890afd80709Corresponds to empty contents.
. Svn/wc. dbIs an SQLite database that contains all SVN-specific metadata (path, URLs, properties and so on). The most interesting table isNODES. 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.dbSQLite version 3.7.112012-03-2011:35:50Enter".help"for instructionsEnter SQL statements terminated with a ";"sqlite>.tablesACTUAL_NODE NODES PRISTINE WC_LOCKEXTERNALS NODES_BASE REPOSITORY WORK_QUEUELOCK NODES_CURRENT WCROOTsqlite>select local_relpath, revision, checksum from NODES;|0|file|1|$sha1$da39a3ee5e6b4b0d3255bfef95601890afd80709anotherFile|2|$sha1$da39a3ee5e6b4b0d3255bfef95601890afd80709
As one can see there're 3 entries: for working copy root ("") and 2 for files in it. And contents is referencedSHA-1Hash.
For some reasons SVN keeps references count for everySHA-1Checksum 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. WhenRefcountInPRISTINETable becomes 0, corresponding pristine files are not deleted automatically, but only after"Svn cleanup"Command.
Every software contains a bug. SometimeRefcountBecomes 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.RefcountValue may reach zero but some entries can still reference to a pristine fileSHA-1Checksum. 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 cleanupsvn: E155010:Pristine text 'da39a3ee5e6b4b0d3255bfef95601890afd80709'not present$ find .svn/pristine/.svn/pristine/.svn/pristine/da
Now our working copy is already upted. It is locked (because"Svn cleanup"Failed) and consequent cleanups do not help.
$ echo text > file$ svn diffsvn: E155010:Pristine text 'da39a3ee5e6b4b0d3255bfef95601890afd80709'not present$ svn cleanupsvn: 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 selectModify | 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.dbSQLite version 3.7.112012-03-2011:35:50Enter".help"for instructionsEnter SQL statements terminated with a ";"sqlite>select*from PRISTINE;$sha1$da39a3ee5e6b4b0d3255bfef95601890afd80709||0|2|$md5 $d41d8cd98f00b204e9800998ecf8427e$ svn diffIndex: file===================================================================--- file (revision 1)+++ file (working copy)@@-0,0+1@@+text
Our working copy is retried red and unlocked, local changes are untouched.
Refer to: http://vcs.atspace.co.uk/2012/06/20/missing-pristines-in-svn-working-copy/