On Fri, Feb 29, 2008 at 9:06 AM, David Glasser <glasser_at_davidglasser.net> wrote:
>
> On Fri, Feb 29, 2008 at 6:50 AM, Ben Collins-Sussman
> <sussman_at_red-bean.com> wrote:
> > 2008/2/29 Stephen Butler <sbutler_at_elego.de>:
> >
> > > Hi folks,
> > >
> > > If an item has been modified or deleted in the repository since
> > > the item was last updated in the working copy, Subversion should
> > > disallow committing that item. This is a prerequisite for tree
> > > conflict detection. The user should have to update in order to
> > > integrate the repo changes, possibly revealing tree conflicts.
> > >
> > > I had assumed that Subversion would block a commit that includes an
> > > item that has been modified or deleted on the repo. But that's not
> > > true in all cases:
> > >
> > > WC State Repo State Blocked?
> > > ======== ========== ========
> > > Modified Modified Yes
> > > Modified Deleted Yes
> > > Deleted Modified Yes
> > > Deleted Deleted No
> > >
> > > We'd like to plug that gap.
> >
> > Let's back up a moment. Why is that a 'gap'? That's a very
> > deliberate design decision, IIRC. The 'auto merging' loop that's part
> > of commit finalization considers some changes to be mergeable, and
> > some not. If two people are in a commit race and change the same
> > file, that's not auto-mergeable: somebody wins the race, the other
> > person's commit outright fails. But if the only 'conflict' is that
> > they both happened to delete the same file, that's a perfectly safe
> > auto-mergeable change: the overlapping changes are in agreement.
> > Nobody will be destroying or overwriting somebody else's change by
> > allowing the changes to be merged.
>
> You sure? From libsvn_fs_fs/tree.c(merge):
>
> /* If SOURCE-ENTRY and TARGET-ENTRY are both null, that's a
> double delete; flag a conflict. */
> if (s_entry == NULL || t_entry == NULL)
> return conflict_err(conflict_p,
> svn_path_join(target_path,
> a_entry->name,
> iterpool));
Though to be clear, the repos commit editor takes the opposite
approach: it ignores delete_entry calls made on nonexistent paths.
Perhaps this inconsistency is a bug.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-29 18:09:12 CET