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

Re: deleted-with-history [sic] after merge

From: David Glasser <glasser_at_davidglasser.net>
Date: Fri, 29 Feb 2008 09:06:03 -0800

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,

> In theory, if the two commits made absolutely identical textual
> changes to the same file, that would also be an example of a 'safe'
> auto-mergeable thing; we just never made the commit-finalization loop
> sophisticated enough to notice that case.

Not really. The typical example is something like a file containing
the number of modules in a system. The system has 10 modules and the
file contains "10". Two changes are applied at the same time: both of
them adds a module and changes the "10" to "11". This should
conflict, since the file needs to end up saying "12".


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:06:37 CET

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

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