Julian Foad <julianfoad_at_btopenworld.com> wrote on 04/21/2008 01:55:47 PM:
>
> Here are the big differences between update/switch and merge:
>
> 1. For update/switch, the source was identical to the target before the
two
> operations mentioned in the table; for "merge", a source item can bethe
same
> as or similar to or completely different from the item at the same
> path in the
> target. Differences can be due to changes in the target branch (or
> WC) and/or a
> change in the source branch that occurred before the merge, if this is a
> cherry-picked merge.
>
> 2. update/switch can tell whether the target item has the same
> object identity
> as the source item, regardless whether its content is identical; merge
can't.
>
> Therefore we have to define the "merge" semantics differently: rather
than
> considering an "operation" that happened, we look at the "state" of
> the target
> (relative to the source-left):
>
> - an item is there and identical
> - an item is there and differs (in content or properties)
> - an item of a different kind is there (file vs. directory)
> - an item is not there
>
> So, for merge, the table should be:
>
> target \ source | mod del rep
> ----------------+-------------
> identical | mod del rep
> different | M C C
> diff-kind | C C C
> not-there | C C C
>
> target \ source | add
> ----------------+-----
> not-there | add
> anything-there | C
Agreed. This should be almost completely safe, in that missing
conflicts due coincedental equality is highly, eh, coincedental.
As such, this has to suffice for a first implementation.
>
> (For "add" and "replace", a more sophisticated conflict resolver could
take
> into account what the target looks like compared with the source-right,
i.e.
> the to-be-added item, but just looking at source-left is enough for us at
the
> moment.)
I'm not sure I would trust that heuristic. Add onto "something-there"
spells trouble and should lead to a conflict.
[...]
> >
> > In my table I tried to indicate "the full set of changes
> > unique to the source/target branch", which includes possibly
> > local modifications on a working copy. In other words, I
> > considered the full history of the two branches, in which
> > case I don't see how this can happen.
> >
> > > Same goes for replace/delete and the other way
> > > around, where the merge wants to add a file to a path
> > > which is scheduled for deletion in the working copy.
> >
> > Ok. If I understand you correctly, a use case could be:
> >
> > source:
> > r1001 A foo.txt
> >
> > target:
> > r1002 A foo.txt
> > r1003 D foo.txt (or, perhaps just a local mod, not yet committed)
> >
> > after which the user tries to merge r1001 from source to target.
> > Now the question is: is this a valid merge or is this a tree
> > conflict? Naively, the fact that foo.txt has been deleted makes
> > the path available for the add from the source again, so the merge
> > is safe. However, If the merge had taken place after r1002, there
> > would have been a tree conflict.
> >
> > Looking at the complete history on target, this would trigger a
> > tree conflict because of the add in r1002, according to the table,
> > and that would probably also be the safest approach.
> [...]
>
> I don't know about "safest". Anyway, this (looking through the
> history at what
> changes have been made) isn't how the concept of "merge" behaves in
> Subversion,
> and I don't know if it would ever make sense or be possible to
> behave like this.
Well, I certainly hope Subversion does develop the notion of at
least tracking where files move to during their lifetime (using
whatever means). Users tend to expect a version control system
that manages versioned trees including moves to be able to do
this. (Without this, mind-numbing and avoidable work is loaded
onto users, who get frustrated, make mistakes, and lose valuable
time.)
>
> As long as the above makes sense to you, I think we've now defined the
> combinations that we need to detect.
Agreed.
- Nico
Received on 2008-04-22 07:09:42 CEST