You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Johan Corveleyn <jc...@gmail.com> on 2011/07/01 11:03:21 UTC
wc-ng and recoverability of corrupt wc's
Hi,
Sometimes, a (part of a) working copy gets corrupted (errors like
'checksum mismatch ...' while running 'update'). Maybe it happened
because a third-party tool has messed with the base files, or with the
entries file, or ... or maybe it happened because of a bug in svn.
This was/is deemed non-disastrous, because it's only a working copy,
one can always checkout a new one (after backing up local changes).
Of course, it can be painful if a working copy is (very) large, and
the corruption is in a small directory somewhere deep down, ... In
wc-1, there was the cheap solution that you could just blast away the
"corrupt directory" (including the .svn metadata), and let "svn
update" restore it (after which you would copy over your modified
files). Just this week I helped out two of my colleagues who ran into
such wc corruptions, by following exactly this procedure.
AFAICS, this will no longer be possible with wc-ng. Has anyone thought
about this problem? Any ideas on how one could recover "cheaply" from
a small (local to a single directory or file) corruption in the wc
(either incorrect meta-data, or corrupt pristine, or ...)?
Maybe the "increased recovery cost" will be partly offset by wc-ng
having less chance of becoming corrupt? Because of more robustness,
and because of decreased likelyhood of corrupting pristine files
because they are only in the wc-root, and things like that? I don't
know ...
In any case, I expect questions about "how to recover from wc
corruption" to appear on the users list pretty quickly, so it would be
useful if some strategies could already be devised ...
Cheers,
--
Johan
Re: wc-ng and recoverability of corrupt wc's
Posted by Philip Martin <ph...@wandisco.com>.
Daniel Shahaf <d....@daniel.shahaf.name> writes:
> Philip Martin wrote on Fri, Jul 01, 2011 at 10:26:34 +0100:
>> Corrupt pristine can be recovered by doing:
>>
>> $ svn up -r0 wc/some/path
>> $ svn up wc
>>
>> That will also work for some, but by no means all, instances of corrupt
>> metadata.
>>
>
> And 'svn up --set-depth exclude'? Would that also work?
I think so, however exclude is sticky so needs the subsequent update
needs '--set-depth infinity'.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: wc-ng and recoverability of corrupt wc's
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Philip Martin wrote on Fri, Jul 01, 2011 at 10:26:34 +0100:
> Johan Corveleyn <jc...@gmail.com> writes:
>
> > AFAICS, this will no longer be possible with wc-ng. Has anyone thought
> > about this problem? Any ideas on how one could recover "cheaply" from
> > a small (local to a single directory or file) corruption in the wc
> > (either incorrect meta-data, or corrupt pristine, or ...)?
>
> Corrupt pristine can be recovered by doing:
>
> $ svn up -r0 wc/some/path
> $ svn up wc
>
> That will also work for some, but by no means all, instances of corrupt
> metadata.
>
And 'svn up --set-depth exclude'? Would that also work?
> --
> Philip
Re: wc-ng and recoverability of corrupt wc's
Posted by Philip Martin <ph...@wandisco.com>.
Johan Corveleyn <jc...@gmail.com> writes:
> AFAICS, this will no longer be possible with wc-ng. Has anyone thought
> about this problem? Any ideas on how one could recover "cheaply" from
> a small (local to a single directory or file) corruption in the wc
> (either incorrect meta-data, or corrupt pristine, or ...)?
Corrupt pristine can be recovered by doing:
$ svn up -r0 wc/some/path
$ svn up wc
That will also work for some, but by no means all, instances of corrupt
metadata.
--
Philip
Re: wc-ng and recoverability of corrupt wc's
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Jul 1, 2011 at 11:32 AM, Noorul Islam K M <no...@collab.net> wrote:
> Johan Corveleyn <jc...@gmail.com> writes:
>
>> Hi,
>>
>> Sometimes, a (part of a) working copy gets corrupted (errors like
>> 'checksum mismatch ...' while running 'update'). Maybe it happened
>> because a third-party tool has messed with the base files, or with the
>> entries file, or ... or maybe it happened because of a bug in svn.
>> This was/is deemed non-disastrous, because it's only a working copy,
>> one can always checkout a new one (after backing up local changes).
>>
>> Of course, it can be painful if a working copy is (very) large, and
>> the corruption is in a small directory somewhere deep down, ... In
>> wc-1, there was the cheap solution that you could just blast away the
>> "corrupt directory" (including the .svn metadata), and let "svn
>> update" restore it (after which you would copy over your modified
>> files). Just this week I helped out two of my colleagues who ran into
>> such wc corruptions, by following exactly this procedure.
>>
>
> noorul@noorul:/tmp/wc/repo$ tree
> .
> `-- A
> `-- B
> `-- C
> `-- D
> `-- file.txt
>
> 4 directories, 1 file
> noorul@noorul:/tmp/wc/repo$ rm -r -f A/B/C/D
> noorul@noorul:/tmp/wc/repo$ ~/projects/subversion/builds/trunk/bin/svn up A/B/C/D
> Updating 'A/B/C/D':
> Restored 'A/B/C/D'
> Restored 'A/B/C/D/file.txt'
> At revision 1.
>
> It is working for me. I might be overlooking.
Yes, this works, but this is not solving the problem I'm talking
about. If you do this with wcng, you only delete the working file, and
let it be restored. What I'm talking about here is the case where a
pristine file is corrupt (no longer located in D/.svn, but in
/tmp/wc/repo/.svn), or the rows in the wc.db database which are
related to that working file.
Especially with wc.db, you can't easily blast away the corrupt rows or
something like that.
--
Johan
Re: wc-ng and recoverability of corrupt wc's
Posted by Noorul Islam K M <no...@collab.net>.
Johan Corveleyn <jc...@gmail.com> writes:
> Hi,
>
> Sometimes, a (part of a) working copy gets corrupted (errors like
> 'checksum mismatch ...' while running 'update'). Maybe it happened
> because a third-party tool has messed with the base files, or with the
> entries file, or ... or maybe it happened because of a bug in svn.
> This was/is deemed non-disastrous, because it's only a working copy,
> one can always checkout a new one (after backing up local changes).
>
> Of course, it can be painful if a working copy is (very) large, and
> the corruption is in a small directory somewhere deep down, ... In
> wc-1, there was the cheap solution that you could just blast away the
> "corrupt directory" (including the .svn metadata), and let "svn
> update" restore it (after which you would copy over your modified
> files). Just this week I helped out two of my colleagues who ran into
> such wc corruptions, by following exactly this procedure.
>
noorul@noorul:/tmp/wc/repo$ tree
.
`-- A
`-- B
`-- C
`-- D
`-- file.txt
4 directories, 1 file
noorul@noorul:/tmp/wc/repo$ rm -r -f A/B/C/D
noorul@noorul:/tmp/wc/repo$ ~/projects/subversion/builds/trunk/bin/svn up A/B/C/D
Updating 'A/B/C/D':
Restored 'A/B/C/D'
Restored 'A/B/C/D/file.txt'
At revision 1.
It is working for me. I might be overlooking.
Thanks and Regards
Noorul