Re: Pristiine copy not present

On Fri, Aug 24, 2012 at 7:12 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
>> Sent: vrijdag 24 augustus 2012 18:32
>> To: Simon Heffer
>> Cc: users_at_subversion.apache.org
>> Subject: Re: Pristiine copy not present
>>
>> Simon Heffer wrote on Fri, Aug 24, 2012 at 15:55:29 +0000:
>> >
>> > We seem to have a deadlock of some kind...
>> > At the end of a system build we commit our built components to a binary
>> repository...
>> >
>> > svn cleanup --username xxxxx --password xxxxx
>> >
>>
>> Last I checked, 'cleanup' does not access the repository (well, maybe
>> except for upgraded 1.0 working copies or something like that, Bert
>> would know :)), so it doesn't need these arguments.
>
> svn upgrade needs access to the repository for 1.0 working copies, but svn
> cleanup never.
> (Very early in 1.7 development we used svn cleanup for the upgrade, but we
> never released that code)
>
>> > svn commit -m "build msg" --username xxxxx --password xxxx
>> > svn: E155010: Pristine text 'd9b41b57756396b9cb236801fc02e0da0a83dffe'
>> not present
>> > svn: E155004: Commit failed (details follow):
>> > svn: E155004: Working copy 'D:\xxxxxx\Base' locked.
>> > svn: E155004: 'D:\xxxxx\Base' is already locked.
>> > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>> >
>> > If I run svn cleanup again I get:
>> > svn: E155010: Pristine text 'd9b41b57756396b9cb236801fc02e0da0a83dffe'
>> not present
>> >
>> > or update:
>> > svn update
>> > svn: E155004: Working copy 'D:\xxxxxx\Base' locked.
>> > svn: E155004: 'D:\xxxxx\Base' is already locked.
>> > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>> >
>> > The working copy is quite new i.e. not much opportunity to screw it up
> :(
>
> Which build system do you use?
>
> Some very popular java based buildsystems automatically use svnkit, and in
> that case we might have to call in others to help in diagnosing the problem.

Indeed, I've seen similar issues after svnkit usage (though I believe
they fixed some subtle corruption bugs in their most recent release
(1.7.5-v1)). It would be nice if you could confirm if svnkit is
involved (has ever been used on this working copy), and if so, which
version. I've never seen 'pristine-text-not-present' problems with
only native svn usage.

Now, if you want to repair this working copy, and you're feeling
adventurous, here is something you can try (I've had some success with
this, but YMMV -- WARNING: this involves direct manipulation of the
working copy metadata. If something goes wrong you might destroy your
working copy):

1) Get an sqlite executable (for Windows: download a pre-compiled
binary from http://www.sqlite.com/download.html). Put it somewhere in
your PATH.

2) Open a command prompt and go to the root of your working copy. Execute:

sqlite3 .svn\wc.db "select * from nodes where checksum like
'%d9b41b57756396b9cb236801fc02e0da0a83dffe'"

This should return exactly 1 row from the svn working copy database.
You can see in that row the local path that's related to that pristine
file.

3) Now execute:

sqlite3 .svn\wc.db "update nodes set presence='not-present' where
checksum like '%d9b41b57756396b9cb236801fc02e0da0a83dffe'"

Now you've changed the presence value of that particular row to
"not-present", giving svn a chance to recover from the actually
missing pristine file.

4) "svn cleanup" again. There might be more missing pristines. Repeat
steps 2 and 3 for them.

5) Finally:

svn update --force

This makes svn actually restore the pristines. The --force is there
because svn will also try to install the working versions of the
"not-present" files. But those files are still there. Without --force
you'll get tree conflicts on those files because of the "unversioned
obstructions" that svn thinks they are (because of "not-present" svn
thinks they shouldn't be there).

HTH

-- 
Johan