mbp at sourcefrog.net
Thu Apr 13 03:29:28 BST 2006
On 12/04/2006, at 10:55 PM, Aaron Bentley wrote:
> Martin Pool wrote:
>> Just to expand on what I said before - the problem with walk() is
>> it returns all lines in the history of the file, even those which
>> irrelevant to the two versions we're trying to merge. Touching
>> them is
>> not just specific to weave storage, but an undesirable consequence,
>> since we spend time walking lines we can't possibly use.
> Okay, but with weaves, we always have to read the weave from
> top-to-bottom anyhow, I think.
Right - what I meant was that there's no sense paying this cost on
>> We can make a plan_merge for knits which does something similar, but
>> only deals with lines which can possibly be in the output. It
>> annotated knits. It should work like this:
>> Do a two-way diff between the two versions to be merged.
>> Within the
>> difference regions, we need to determine whether each line is
>> live, or killed in the other side. Taking the lines from the
>> left-hand-side conflict region first, get the line origins.
> Depending on the costs involved, it might be worthwile to diff the
> annotated version, to reduce false matches.
Doing that would give you a result that's more similar to that of
weave merge. Whether those results are subjectively better or not
may vary from case to case.
Possibly a good tradeoff would be to use a strict Patience diff,
without falling back to difflib diff; then we'll align only on lines
that are unique in each file, even if their apparent origin is
> An interesting thought. Are you thinking of
> http://revctrl.org/MarkMerge and the way it distinguishes between
Yes, that sort of thing. If the user gets a conflict and resolves
it, then they have made a new decision in that area, even if they
didn't introduce any new lines. It's a bit more like the case
described as a motivation here
More information about the bazaar