Re: disallowing commit of a deletion of a deleted file

[Karl Fogel <kf...@red-bean.com>]

"David Glasser" <gl...@davidglasser.net> writes:
> Just for extra super duper fun, Subversion today isn't actually
> consistent about whether or not a double-delete should be a conflict
> or OK.
>
> Specifically, in the libsvn_repos commit editor, if a delete_entry is
> sent from the client on an entry that doesn't exist in the
> transactions' root (and note that the transaction root is always based
> off of the youngest rev when the commit is started, not anything found
> in the WC or otherwise client-specified), then it'll just ignore that
> call and not pass anything to the FS layer: the concurrent deletion is
> ignored.  This is the usual case, where we commit deletions not
> simultaneously, but without an update in between.
>
> However!  *If* two people are actually trying to delete the entry
> nearly simultaneously (specifically, if both transactions are created
> before either is committed), then the merge() code in
> libsvn_fs_{base,fs}/tree.c will actually notice the double-delete and
> throw a conflict error.  (I managed to reproduce this a few months ago
> with careful placement of breakpoints on the server.)

How odd.  That means that simply re-attempting the failed commit would
succeed, even though no update had happened in between, right?

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

Re: disallowing commit of a deletion of a deleted file

[David Glasser <gl...@davidglasser.net>]

On Wed, Apr 2, 2008 at 4:02 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "David Glasser" <gl...@davidglasser.net> writes:
>  > Just for extra super duper fun, Subversion today isn't actually
>  > consistent about whether or not a double-delete should be a conflict
>  > or OK.
>  >
>  > Specifically, in the libsvn_repos commit editor, if a delete_entry is
>  > sent from the client on an entry that doesn't exist in the
>  > transactions' root (and note that the transaction root is always based
>  > off of the youngest rev when the commit is started, not anything found
>  > in the WC or otherwise client-specified), then it'll just ignore that
>  > call and not pass anything to the FS layer: the concurrent deletion is
>  > ignored.  This is the usual case, where we commit deletions not
>  > simultaneously, but without an update in between.
>  >
>  > However!  *If* two people are actually trying to delete the entry
>  > nearly simultaneously (specifically, if both transactions are created
>  > before either is committed), then the merge() code in
>  > libsvn_fs_{base,fs}/tree.c will actually notice the double-delete and
>  > throw a conflict error.  (I managed to reproduce this a few months ago
>  > with careful placement of breakpoints on the server.)
>
>  How odd.  That means that simply re-attempting the failed commit would
>  succeed, even though no update had happened in between, right?

I believe so, yes.

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/

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