Re: subversion on NFS

[Murli Varadachari <mv...@facebook.com>]

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" <sv...@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

Re: subversion on NFS

[Lieven Govaerts <sv...@mobsol.be>]

Murli Varadachari wrote:
> 
> 
> 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
> 

This patch is the latest version. It has been committed to a branch in
r30438 and merged to trunk later.

The regression test part of patch does not apply cleanly to 1.5, but the
rest does and it works as intended. This won't break merge, just handles
this one case differently.

Lieven

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org