Pristine text missing - cleanup doesn't work

I have just been fixing one of my WCs, in which a number of pristine texts had gone missing from the pristine store.  Some of the pristine texts referenced by the wc.db 'nodes.checksum' column were missing from the wc.db 'pristine' table and from the '.svn/pristine/' directory.

I don't know how or when this happened.  My best guess is it was caused by a bug in a (development) version of Subversion that I was using on this working copy at some point in the past, that set the ref-count column to 0 erroneously, and then a subsequent 'svn cleanup' removed the pristine.  The bug may have been triggered by some exceptional condition such as network failure during 'svn update'.  The bug may or may not still exist in 1.8.x stabilization, but as far as I know, no such bug has been identified and fixed, so I would assume the bug probably still does exist.

Other people have run into the same situation.  For example, here are three reports that also include useful information and suggestions for fixing the WC:
<http://disinformationtech.blogspot.ca/2012/09/svn-error-pristine-text-not-found.html>
<http://vcs.atspace.co.uk/2012/06/20/missing-pristines-in-svn-working-copy/>
<http://mail-archives.apache.org/mod_mbox/subversion-users/201203.mbox/%3CCAB84uBUv7dV9wY25W-oMYUvZvh5vXVm2RhuZpjRt8VjpeJm6GA@mail.gmail.com%3E>

Running "svn cleanup" after discovering a lost pristine does not help, and in fact makes things *worse* because it locks the WC which previously was not locked.

[[[
$ svn st
svn: warning: W155010: Pristine text '00bc6534fb7cec87cf9cb17332679ba304d98b09' not present

$ svn up
Updating '.':
svn: E155010: Pristine text '00bc6534fb7cec87cf9cb17332679ba304d98b09' not present

$ svn cleanup
svn: E155010: Pristine text '00bc6534fb7cec87cf9cb17332679ba304d98b09' not present

$ svn st
  L     .
svn: warning: W155010: Pristine text '00bc6534fb7cec87cf9cb17332679ba304d98b09' not present

$ svn up
svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
svn: E155004: Working copy '/.../svn-site' locked.
svn: E155004: '/.../svn-site' is already locked.
]]]

==DIAGNOSIS==

1) Bug: Subversion sometimes erroneously sets a ref-count to 0.

2) Bug: 'cleanup' deletes pristines that have a ref-count of 0 without first checking that the ref-count is correct.

3) Bug: 'cleanup' errors out, leaving the WC locked, on finding a missing pristine.

Further observations on (1).  Setting the re-count wrongly has no immediate effect, as only 'svn cleanup' checks the ref-count, AFAIK.  Having set a ref-count to 0 when it should be 1, Subversion will ignorantly decrement the erroneous 0 to -1 upon "svn update -r0 foo", and increment the erroneous -1 to 0 upon "svn up -r$EXISTS foo", without reporting any problem.

==WORK-AROUNDS==

It is interesting to note that the three web pages I linked above all recommend using SmartSVN's "Validate admin area" command; that diagnoses and fixes the problem, downloading the necessary text from the repository and inserting the row into the 'pristine' table.

I wrote the attached script "svn-fetch-pristine-by-sha1.sh" today, which, given a SHA-1, finds the reference in the 'nodes' table, downloads the file from the reepository, and fixes the 'pristine' table.  (It presently assumes that the correct ref-count is 1.)

I think we should do something to improve the situation.  Fortunately it seems to be relatively rare, as not many people have complained about it, but there are over 5000 pages listed by Google with that error message.

- Julian

--
Join WANdisco's free daily demo sessions on Scaling Subversion for the Enterprise
<http://www.wandisco.com/training/webinars>