On Tue, Jun 12, 2012 at 8:22 AM, Justin Erenkrantz
<justin_at_erenkrantz.com> wrote:
> On Tuesday, June 12, 2012, C. Michael Pilato wrote:
>> On 06/10/2012 09:13 AM, Justin Erenkrantz wrote:
>> > How does the user recover? Less of an issue when we have WC-specific
>> > pristines, but itis more of an issue as we move towards global
>> > pristines.
>>
>> Recovery is a whole 'nuther topic. In the past, some recovery has been
>> possible with 'svn update -r0 /path/to/messedup/file && svn cleanup && svn
>> up'. Not sure that that is a guaranteed recovery recipe, though, and
>> certainly not one that either the binary itself or any official
>> user-facing
>> documentation prescribes.
>
>
> There were a few conversations last night that we should probably consider
> creating a UI/command to do something about fixing up local corruption.
> There are definite real-world reports of local WC corruption and folks
> having such large WCs that a clean checkout would be quite painful. Perhaps
> we should have a breakout session during the Hackathon this week to
> brainstorm some ideas? -- justin
Yeah, I've had to help out colleagues with wc corruptions of varying
degrees. It can be pretty hard. But most of the time, the problem
wasn't the prisine itself being corrupt (i.e. its contents being
inconsistent with its filename), but rather the wc.db records (I
think).
There's missing pristines (see [1]):
svn: E720002: Can't open file
'C:\Work\WC-root\.svn\pristine\6d\6d6e0892990e945b03a15b8e518dbef26848dc75.svn-base':
The system cannot find the file specified.
This was annoying, because it broke 'cleanup' itself. I ended up doing
the following to fix it:
$ sqlite3 .svn/wc.db "delete from work_queue"
$ svn cleanup
$ svn up --set-depth exclude X
$ svn up X
And the there's a checksum mismatch, which I encountered with IntelliJ
IDEA which has its svn4idea plugin using svnkit (the issue of how the
checksum mismatch occurs is still unresolved -- it's hard to figure
out if it's svn's fault, or svnkit's, or some unsafe use of API calls
by the svn plugin in IntelliJ). See [2].
This is the error we end up with:
Checksum mismatch for 'C:\some\dir\with\some\JavaFile.java'; expected:
'$md5 $f73711098f4c6baec568f4f0f1f37b7e', actual:
'cd3889e8a6692b29f828ea7b0665ad30'
And after that, the wc is pretty corrupt at that node (its "Revision"
has been bumped, but in reality it hasn't been updated (its "Last
Changed Rev" is not correct wrt the Revision)). 'svn update' then
fails with:
svn: E200003: Delta source ended unexpectedly
So far, apart from the above recipe, I've also used the following ways
to repair working copies:
1) clear work_queue and/or clear wc_lock table manually (because
cleanup wouldn't run anymore)
2a) either fix it with 'svn update -r0' or 'svn update --set-depth=exclude'
2b) or if that doesn't work: set the presence to "not-present" in
nodes, and run 'svn update'.
That last one is pretty drastic, but it seemed to be the only way I
found to recover some corrupt working copies.
[1] http://svn.haxx.se/users/archive-2012-03/0458.shtml
[2] http://youtrack.jetbrains.com/issue/IDEA-83673
--
Johan
Received on 2012-06-12 10:16:23 CEST