Nico Schellingerhout wrote:
> Stefan Sperling <stsp_at_elego.de> wrote on 04/20/2008 09:56:56 AM:
> > On Sun, Apr 20, 2008 at 01:32:17AM +0200, Nico Schellingerhout wrote:
> > > Tree conflict case analysis:
> > > ============================
> > >
> > > Let's start by enumerating all the cases:
> > >
> > > target \ source | mod add del rep
> > > ----------------+-----------------
> > > mod | M X C C
> > > add | X C X X
> > > del | C X C C
> > > rep | C X C C
> > >
> > > Legend:
> > > M = merge (=text merge for files, dir merge for dirs)
> > > X = can't happen
That works for update/switch.
I suggested we need a different table for merges, because the concept or
philosophy of merging in Subversion considers only how the target looks
relative to the source, and not how it got into that state. Thus:
target \ source | mod del rep
----------------+-------------
identical | mod del rep
different | M C C
different-kind | C C C
not-there | C C C
target \ source | add
----------------+-----
not-there | add
anything-there | C
> * This table holds for both files and directories.
Yes.
[...]
> * The changes on the source listed in the table are the full set of changes
> to be merged (these changes are by design unique to the source branch,
> thanks to merge tracking).
It's quite common to cherry-pick an individual change from the source branch
without having previously merged all the previous changes. I think it's better
if we don't assume that merge tracking is being used and that all available
changes are being merged sequentially. Instead, we can define how to merge any
(cherry-picked) change into any target, and then both the complex
(cherry-picked) case and the simple (always merge everything) cases will work.
[...]
>>> Desired behaviour (apart from raising the conflict):
[...]
> Come to think of it, wouldn't it be more consistent to load the WC
> with the usual helper files, and extend that to tree conflicts and
> dirs?
> From the Subversion book:
> > sandwich.txt
> > sandwich.txt.mine
> > sandwich.txt.r1
> > sandwich.txt.r2
> for update/switch and
> > filename.working
> > filename.left
> > filename.right
> for merge.
Yes, that's much better than just trying to use the plain file name.
> That would lead to the following behavior table:
>
> target \ source | mod add del rep
> ----------------+-----------------
> mod | M X Ca Cb
> add | X Cc X X
> del | Cd X Ce Cd
> rep | Cb X Ca Cb
>
> Legend:
> Ca: filename.working + filename.left
> Cb: filename.working + filename.left + filename.right
> Cc: filename.working + filename.right
> Cd: filename.left + filename.right
> Ce: filename.left
That looks fine for update/switch. (We might want to use the "sandwich.txt.r1"
naming style for consistency.)
And similarly, for merges:
target \ source | mod del rep
----------------+-------------
identical | mod del rep
different | M Ca Cb
different-kind | Cb Ca Cb
not-there | Cd Ce Cd
target \ source | add
----------------+-----
not-there | add
anything-there | Cc
> Note that the only differences between the Ca-Ce behaviors is what
> files are dropped in the WC. The decision on what files to drop is
> based purely on the absence/presence of the path in the left, right,
> and working version of the tree. This should make the implementation
> easier I guess.
>
> The advantage of that approach is also that it should be pretty clear to
> the user, because IMHO it would be a consistent re-use of a known concept.
In all of these cases, the rule is that we will create
a .working if a target item existed, and
a .left if a source-left item existed, and
a .right if a source-right item existed.
That's simple and consistent. +1.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-22 08:47:38 CEST