Sorry for the delay in getting back to this subject
My question ==>
If I apply the patch provided to eliminate the "double" delete problem [ I am currently on 1.5.2 ] --- would that break merge. Is that just a corner case [ the merge issue !] . Is there a newer patch available.
http://subversion.tigris.org/issues/show_bug.cgi?id=3156
murli
On 9/29/08 9:25 AM, "Lieven Govaerts" <svnlgo_at_mobsol.be> wrote:
Murli Varadachari wrote:
>
> RE: Testing a shared subversion repository [ netapps partition - NFS
> mounted ] with multiple access points [ HOST1, HOST2]. Test consisted of
> large parallel commits of the same set of changes .
>
> Results: WEIRD --- a "dummy" commit with no changes whatsoever [ in
> one instance ]
..
> 1: I made a number of commits [ both small and big] using svn+ssh and
> http protocols from both HOST1 and HOST2 . Results were OK
>
> 2: Then I made two large simultaneous commits after deleting a very
> large directory. Please note that I was deleting the same set of files
> -- one based off HOST1 and the other one based off HOST2 [ http and
> svn+ssh protocols ]
>
> Example:
>
> svn delete my-WC-HOST1/html/intern
>
> svn delete my-WC-HOST2/html/intern
>
> svn commit -m "Delete html/intern" my-WC-HOST1 [ uses http://URL ]
>
> svn commit -m "Delete html/intern" my-WC-HOST2 [ uses svn+ssh://URL ]
>
>
> RESULTS
> ++++++++
>
> What I would have expected to see is the commit going through from one
> HOST and a error / failure / conflict from the 2nd HOST since the same
> set of files have already been deleted.
>
> However the results were unexpected --- the commit from HOST1 went
> through OK - strangely the commit from HOST2 also went thorough. However
> the second commit log indicated *NO* changes -- a completely "dummy"
> commit generated via HOST2.
..
>
> Q: Has anyone seen this type of behaviour before ?? The log of 123386
> indicates *no* change.
>
This is known and intended behavior. On the second delete the svn repos
layer notices that this file was already deleted, presumably in a
transaction that finished right before this one, decides that's ok and
just ignores that delete.
If there are no other changes in the transaction than that results in an
empty revision file. So perfectly normal, for svn 1.5.
Now this has changed in svn trunk as part of the tree-conflicts work,
sin with svn 1.6 you'll get a out-of-date conflict in this situation.
See also: http://subversion.tigris.org/issues/show_bug.cgi?id=3156.
hth,
Lieven
Received on 2008-10-10 04:47:28 CEST