On Thu, Feb 23, 2012 at 03:05:41PM +0000, Philip Martin wrote: > Stefan Sperling <s...@elego.de> writes: > > > > Recall that any commit to a node creates a new revision of the node's > > parents in the repository. If a commit changes, for instance, /trunk/foo, > > the following nodes will get a new revision in the repository: > > > > / > > /trunk > > /trunk/foo > > > > This is called "bubble-up process" and is described here in detail: > > http://www.red-bean.com/kfogel/beautiful-code/bc-chapter-02.html > > > > A concurrent commit racing the copy operation can cause a new revision of > > the destination 'tags/build', of '/tags', and of the root. > > This can cause an out-of-date error because the copy operation is now > > trying to modify out-of-date directories. > > That's not correct, a commit does involve bubble-up changes but that > doesn't stop concurrent commits. Look at the '1729' loop in > svn_fs_fs__commit_txn, that will detect the race and retry the commit > based on the new revision. > > You can get a conflict on URL-URL copies if two concurrent commits > attempt to create the same destination URL, but that leads to a > "Conflict at" error, not "out of date".
I made a generalised statement because it wasn't clear what the other commit is doing. In the general case, it won't always work. For example, if a commit deletes tags/build, that should prevent a competing transaction from copying into tags/build. I don't know off-hand what kind of error is returned in this situation however. > I'm not sure how an URL-URL copy can trigger the original error. Is > there any clue in the apache error log? Which version of Subversion on > the client and server? Are you using serf or neon? Is there a > master-slave write-through proxy involved? I am not entirely convinced yet that the situation involves only copies. That is what we're apparently being told, but we don't know what these build scripts are really doing. So, yes, more information is needed to figure out what's happening.
