RE: Pristiine copy not present

Thanks all,

svn --version gives:
svn, version 1.7.2 (r1207936)
   compiled Nov 29 2011, 22:11:27

There's no build system issue here. We build a number of different machines (windows and UNIXs) and copy the results onto the final machine (Windows Server 2003 SP2). A script is then run to copy the files into the working copy and another to commit to the repository. This system has been in place for over three years.

I have checked out a clean copy already to try and fix this but still get the same problem. Those messages are what we get.

Unlikely I'll be able to poke around too much on this system as it's used to control all our production builds but I'll see what's possible. We do have SQL server 2005 installed - is there a way to use that?

Simon

-----Original Message-----
From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
Sent: 24 August 2012 20:59
To: Simon Heffer
Cc: Daniel Shahaf; Bert Huijben; users_at_subversion.apache.org
Subject: 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 diagnosinroblem.

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
This message has been scanned by MailController - portal1.mailcontroller.co.uk
This message has been scanned by MailController - portal1.mailcontroller.co.uk