Julian Foad <julianfoad_at_btopenworld.com> wrote on 04/21/2008 02:51:57 PM:
> [...]
> > * 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 tomerge
any
> (cherry-picked) change into any target, and then both the complex
> (cherry-picked) case and the simple (always merge everything) cases will
work.
>
Good point.
I had been thinking about cherry picking, and sort of assumed that
would work as well (conveniently ignoring the faint warning signs
in the back of my head :(
So much for trying to take a shortcut.
Everytime we dig into this it comes down to tracking the moves of
the file (by pairing up deletes and replaces/adds-with-history)
from the revision to be merged in the source branch back to some
common point in history (branch point), and then forward into the
target branch to find the equivalent file. After that (assuming
the search uniquely connects a file in source to a file in target,
which is not guaranteed), the change can be merged as usual (if
the change is a modification) or using some yet to be defined
merge heuristics (for delete, replace, add-with-history, and
possible pairs of these).
Ah well ...
As you suggested in your earlier post, looking at the current
state of the WC is good enough for now.
- Nico
Received on 2008-04-22 08:22:17 CEST