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...
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/