On Fri, Aug 24, 2012 at 7:12 PM, Bert Huijben <b...@qqmail.nl> wrote: > > >> -----Original Message----- >> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] >> Sent: vrijdag 24 augustus 2012 18:32 >> To: Simon Heffer >> Cc: users@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
