Note up front: Please don't top-post, it makes it difficult to
understand what exactly you are referring to.
Am 28.08.2012 10:14, schrieb Simon Heffer:
> svn --version gives:
> svn, version 1.7.2 (r1207936) compiled Nov 29 2011, 22:11:27
>
> There's no build system issue here.
So you don't use svnkit, neither directly nor indirectly via the build
system?
> 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.
There is the danger of mismatches between SVN versions, in particular
since there are different machines involved. Do you copy working copies
around or just files?
> This system has been in place for over three years.
That's unlikely, since SVN 1.7 was not around at that time and that
version drastically changed the WC format. At least it was modified
since the initial installation.
> 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.
You are able to reproduce this from a clean checkout? That's good,
because it makes the issue actually diagnosable.
> 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?
For what? As backing storage for SVN repositories? No way. You don't
seem to have any issue with the backing storage anyway, but rather a
corruption in your working copies, probably caused by the build system.
In any case, there is one thing that looks suspicious:
> 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)
The first error E155010 could actually be caused by a bug in SVN, since
it tries to access the pristine copy before getting a lock on the WC,
which would be a classic race condition. It could also be an
opportunistic read-only locking schema, I'm not sure.
The second error E155004 is that it stumbles over the fact that the
working copy is already locked. This smells of concurrent accesses, like
if you run two svn operations simultaneously on one WC. For example, it
could be one that performs some "svn add" operations and the other an
"svn commit" operation. If your build system starts the first and then
the second without waiting for the first to fisish, that's exactly what
you get. Actually, the advise at the end is misleading in that case. You
don't need a cleanup but only have to wait until a previous operation
has finished, which will remove the lock.
Good luck!
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
Received on 2012-08-28 10:40:15 CEST