[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: subversion on NFS

From: Murli Varadachari <mvaradachari_at_facebook.com>
Date: Thu, 9 Oct 2008 19:46:07 -0700

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.