On Fri, Jul 1, 2011 at 11:32 AM, Noorul Islam K M <noorul_at_collab.net> wrote:
> Johan Corveleyn <jcorvel_at_gmail.com> writes:
>> 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_at_noorul:/tmp/wc/repo$ tree
> `-- A
> `-- B
> `-- C
> `-- D
> `-- file.txt
> 4 directories, 1 file
> noorul_at_noorul:/tmp/wc/repo$ rm -r -f A/B/C/D
> noorul_at_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.
Received on 2011-07-01 15:44:45 CEST