On Fri, Feb 29, 2008 at 6:50 AM, Ben Collins-Sussman
> 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)
> 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 | firstname.lastname@example.org | 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