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.
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.
In any case, I certainly don't consider this a loophole or oversight;
it's a deliberate feature. Is this behavior presenting a real problem
for your model of tree-conflict resolution?
---------------------------------------------------------------------
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 16:11:59 CET