create .BASE files for --weave (and --lca) merge

Bug #40412 reported by David Allouche
4
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
High
John A Meinel

Bug Description

i t is possible to sythesize a BASE for --weave merge, lets do so, so that the output can be used with 3-way tools without having to have users run 'remerge --merge3' after doing a 'merge --weave'.

Tags: mysql

Related branches

David Allouche (ddaa)
Changed in bzr:
assignee: nobody → aaron-bentley
status: Unconfirmed → Confirmed
Revision history for this message
Aaron Bentley (abentley) wrote :

Weave merge is in maintenance-only mode, in favour of LCA merge.

Changed in bzr:
status: Confirmed → Won't Fix
Revision history for this message
GuilhemBichot (guilhem-bichot) wrote :

Now weave merge is in hot mode again, Canonical improved it largely mid-2008 and this is what MySQL is using for all their difficult criss-cross merges. It would be really great to have a base (and properly annotated); currently I have to navigate in gannotate on the local, remote and merged files to find out what each conflicting change was about.

Revision history for this message
Martin Pool (mbp) wrote :

So let's look into this again for Guilhem.

Changed in bzr:
assignee: abentley → nobody
importance: Wishlist → High
status: Won't Fix → Confirmed
Revision history for this message
John A Meinel (jameinel) wrote :

There generally isn't a clean base for weave merge, because it is a conglomerate of the whole ancestry. So I'm not 100% sure what we would put in the file.

That said, we have some options for his use case

1) bzr merge --weave -Dmerge

Will drop a file named
FILENAME.plan

Into the working tree. This has a detailed accounting of all the lines that we evaluated as part of doing the merge. I don't think it has the actual revision id annotations, though that could probably be added. Instead it tells you what lines existed on what side, what has been superseded, etc. I mention it mostly because it exists now, and gives a more detailed account. Then again, I thought it had the revision ids, which it doesn't seem to have after all. (I know it has to compute them, so I thought it would have listed them)

2) bzr merge --merge3
If we change this to do per-file graph merging, I think it will handle more cases where Guilhem uses --weave now, and still gives him a .BASE that he can use.

3) Output the conglomerated weave as .BASE. We could build the Weave in memory, and then use the same "activate lines in THIS + OTHER" and write out what that generates, possibly with the weave's revision id annotation. We don't really want the revision ids for someone trying to use a 3-way merge tool. But honestly using a 3-way merge tool on the results of Weave isn't particularly relevant either.

Revision history for this message
Robert Collins (lifeless) wrote :

This bug seems stalled; Guilhem, is John's option 1 suitable for you - have you looked at it?

Revision history for this message
GuilhemBichot (guilhem-bichot) wrote :

Sorry for late reply, I had forgotten to subscribe to this bug.
When using --weave, we usually look at the conflict in an editor, look at TREE and MERGE-SOURCE blocks, and resolve. So it would be best if the BASE block was visible in that place, written close to those blocks. Rather than having to open the ".plan" file and parse it. So I would go for (3) if not too hard.

Revision history for this message
John A Meinel (jameinel) wrote :

So there are some small issues still to be resolved.

I think we can create a 'conglomerate' base without too much difficulty. The internal structures should already have it. Do we want it annotated, though? If you are trying to use it with a 3-way tool, then the annotation lines are probably going to confuse the tool.

foo-id this is my text\n

isn't going to match
this is my text\n

Revision history for this message
GuilhemBichot (guilhem-bichot) wrote :

Hello John. Regarding whether it should be annotated or not, it depends.
If the base is put in a .BASE file, people are going to run extmerge (3-way tool), in that case it mustn't be annotated, to not confuse the tool as you say.
If the base is put directly in the file (like --show-base currently puts a BASE region in the file, between <<<TREE and >>>MERGE-SOURCE), then people are going to edit the file with their editor, then the annotation doesn't hurt (they'll delete those BASE lines anyway), I don't know if it would help.
By the way, thank you very much for looking into this!

John A Meinel (jameinel)
Changed in bzr:
assignee: nobody → John A Meinel (jameinel)
Revision history for this message
John A Meinel (jameinel) wrote :

So I've been trying to sort out what would be a reasonable BASE for weave merge. This is not so much --weave --show-base as much as it is dumping a .BASE file that can be used. I think I have a decent idea for one method that could be used for this.

I tried it on a trivial ancestry, and it seemed to do quite well (it picked the lines for BASE that I thought it should based on how I did the merges.)

The basic work is to reprocess the "merge plan" and note which lines should be considered part of "BASE", and output those into the .BASE file.

As such, it turns out I can do this as a post-processing step on a .plan file, so I've implemented it as such. I'd like to get some feedback as to whether the result seems reasonable before I go ahead and change the bzr internals to write out one of these files.

So the basic process is to do:

bzr merge --weave -Dmerge

and then for any '.plan' file, you can run the attached plan_to_base.py script.

  plan_to_base.py *.plan

That should output a bunch of .BASE files which you can try to use.

I'll go ahead and look into what it would take to always do this processing, so as to dump a .BASE file as a standard result of "bzr merge --weave".

However, this gives you something that you can run today with an unmodified bzr, and I can get some feedback as to whether this works well enough to proceed.

Revision history for this message
GuilhemBichot (guilhem-bichot) wrote :

Thanks John!! This is great progress.
So I took an old big criss-cross merge case, followed your instructions, used plan_to_base.py to create .BASE files.
Before checking the BASE files (a significant job :-), I wonder - there are two ways to go for this bug. Create BASE files for usage with 3-way merge tools like kdiff3, as you have done for now. Or insert a BASE text section into the merged file, near the <<<<TREE and >>>>MERGE-SOURCE blocks (like --show-base --merge3 does).
From experience, I was under the impression that, with --merge3, the conflicts showed as TREE/MERGE-SOURCE blocks were sometimes smarter than those showed by a 3-way merge tool (kdiff3 in my case). Like if bzr was doing a better job at finding conflicts, or doing a better job at not autosolving conflicts in a bad way. Like if the patiencediff algorithm of bzr was doing a better job than the normal diff of 3-way merge tools.
This vague impression makes me wonder if the first way is the way to go, but I'm likely confused.
What do you think? Thanks.

Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 40412] Re: show-base for weave merge

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GuilhemBichot wrote:
> Thanks John!! This is great progress.
> So I took an old big criss-cross merge case, followed your instructions, used plan_to_base.py to create .BASE files.
> Before checking the BASE files (a significant job :-), I wonder - there are two ways to go for this bug. Create BASE files for usage with 3-way merge tools like kdiff3, as you have done for now. Or insert a BASE text section into the merged file, near the <<<<TREE and >>>>MERGE-SOURCE blocks (like --show-base --merge3 does).
>>From experience, I was under the impression that, with --merge3, the conflicts showed as TREE/MERGE-SOURCE blocks were sometimes smarter than those showed by a 3-way merge tool (kdiff3 in my case). Like if bzr was doing a better job at finding conflicts, or doing a better job at not autosolving conflicts in a bad way. Like if the patiencediff algorithm of bzr was doing a better job than the normal diff of 3-way merge tools.
> This vague impression makes me wonder if the first way is the way to go, but I'm likely confused.
> What do you think? Thanks.
>

For starters:
lp:~jameinel/bzr/2.0-40412-show-base-weave

Does have the "drop a .BASE" file done. I just couldn't push it up last
night because lp was in readonly mode.

Regardless of whether we want to support --show-base to put the content
inline, I think this is a useful improvement, as it at least allows the
user to use a GUI 3-way tool if they so desire.

As for including --show-base to insert the content inline, I still have
to think about that. I think it is possible, but I think it will require
changing a bunch of code to now include BASE lines along with the
content lines. (I think the information is available at one layer, just
not very close to the point where we output lines to the final content.)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksZLAgACgkQJdeBCYSNAAPFfgCeKnVQi+pw8LxvM9+PWAhomp+V
BE0AnR2pK0mZ7Y7rEo67+qefi2KJx+Na
=yY33
-----END PGP SIGNATURE-----

Revision history for this message
GuilhemBichot (guilhem-bichot) wrote : Re: show-base for weave merge

Hello John. I looked at your branch, but couldn't make it generate the .BASE file (I tried "--weave" and "--weave -Dmerge"; "--weave --show-base" was rejected with error). What command line should I use, please?
Regarding putting the base inline or as a BASE file to be used with a GUI 3-way file merge tool, my point was that the inline blocks put by bzr seemed superior to what 3-way file merge tools do (ldue to a difference between traditional diff and patiencediff??). Which is why I wondered if the inline base wouldn't give better conflict solving.
But if the 3-way file merge tools do a good enough job... fine with me!

Revision history for this message
GuilhemBichot (guilhem-bichot) wrote :

Sorry, it was wrong usage from my part, I tried a wrong branch!
Now I got your branch, and I see .BASE files with --weave.
However, I have 33 files with text conflicts (according to "bzr conflicts --text"), but for two of them there is no BASE file.
Here is the single conflict region of one such file without a BASE file:
<<<<<<< TREE
--echo 'Bug: value in information schema does not match'
=======
>>>>>>> MERGE-SOURCE
and for the other file:
<<<<<<< TREE
'Bug: value in information schema does not match'
=======
>>>>>>> MERGE-SOURCE
Let me know if you'd like instructions to download those branches.

Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 40412] Re: show-base for weave merge

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GuilhemBichot wrote:
> Hello John. I looked at your branch, but couldn't make it generate the .BASE file (I tried "--weave" and "--weave -Dmerge"; "--weave --show-base" was rejected with error). What command line should I use, please?
> Regarding putting the base inline or as a BASE file to be used with a GUI 3-way file merge tool, my point was that the inline blocks put by bzr seemed superior to what 3-way file merge tools do (ldue to a difference between traditional diff and patiencediff??). Which is why I wondered if the inline base wouldn't give better conflict solving.
> But if the 3-way file merge tools do a good enough job... fine with me!
>

Well, "bzr merge --weave" should drop a .BASE file if there is a
conflict. Make sure you are running the right code base. I just tested
it again, though I made a mistake the first few times through and was
running the wrong 'bzr' :).

As for inline versus external... "it depends" is probably the best I can
say. Weave works fairly different to a 3-way tool, so the types of
conflicts it generates could be different for all sorts of reasons.

This was mostly the easiest first step towards getting a .BASE that you
could try out. (well, step 2, since the script was the 'easiest' :)

I would guess that the pseudo base that weave is generating isn't going
to be as good for a 3-way tool. I would expect it to be better than
using an empty file as the .BASE though :).

Part of the issue is that with '--weave' or '--lca' there are arguably
many bases that could be relevant for the given line. I'll certainly
continue to think about how we could put base lines in the text.

John
=:-
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksdYNYACgkQJdeBCYSNAAOJiACfWn/Pvcq0/D9bYZ7j/gaX6BNv
7PMAni4mSC5lfcT6IxQxHtcAepOpjOFa
=nNDP
-----END PGP SIGNATURE-----

Revision history for this message
John A Meinel (jameinel) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GuilhemBichot wrote:
> Sorry, it was wrong usage from my part, I tried a wrong branch!
> Now I got your branch, and I see .BASE files with --weave.
> However, I have 33 files with text conflicts (according to "bzr conflicts --text"), but for two of them there is no BASE file.
> Here is the single conflict region of one such file without a BASE file:
> <<<<<<< TREE
> --echo 'Bug: value in information schema does not match'
> =======
>>>>>>>> MERGE-SOURCE
> and for the other file:
> <<<<<<< TREE
> 'Bug: value in information schema does not match'
> =======
>>>>>>>> MERGE-SOURCE
> Let me know if you'd like instructions to download those branches.
>

I'd be willing to take a look at them at least. It *looks* like this
would be a content conflict, where one side had deleted a file and the
other had introduced content.

But maybe not.

There is code in place that if one text 'dominates', then we don't build
the weave, but if one dominates, I don't think you can get conflicts.

The new code is doing:
        if base_lines is not None:
            # Conflict
            self._raw_conflicts.append(('text conflict', trans_id))
            name = self.tt.final_name(trans_id)
            parent_id = self.tt.final_parent(trans_id)
            file_group = self._dump_conflicts(name, parent_id, file_id,
                                              no_base=False,
                                              base_lines=base_lines)
            file_group.append(trans_id)

So *it* cannot generate a 'text conflict' and not generate a .BASE, but
it is possible that there is a different code path generating the text
conflict that I didn't see.

(And the case where you have a deleted file seemed likely to trigger that.)

Probably it would be easiest to try to debug this with whatever branches
you are using.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksdYjoACgkQJdeBCYSNAAPEhwCfYKYD9/EVATXXUVf6ZA+hE+jo
XRUAoMDydPxusUW+ZbHBeDFlZiMysHZ7
=dibv
-----END PGP SIGNATURE-----

Revision history for this message
GuilhemBichot (guilhem-bichot) wrote : Re: show-base for weave merge

Get https://code.launchpad.net/~mysql/mysql-server/mysql-6.0-codebase-bugfixing, make two branches of it:
A at revid:<email address hidden>
B at revid:<email address hidden>
then do
cd B
yourbzr merge --weave ../A
Then notice that mysql-test/r/slave_allow_batching_basic.result and mysql-test/t/slave_allow_batching_basic.test are in "bzr conflicts --text" but have no BASE file.
I checked that I used your branch.

Martin Pool (mbp)
Changed in bzr:
status: Confirmed → In Progress
Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 40412] Re: show-base for weave merge

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GuilhemBichot wrote:
> Get https://code.launchpad.net/~mysql/mysql-server/mysql-6.0-codebase-bugfixing, make two branches of it:
> A at revid:<email address hidden>
> B at revid:<email address hidden>
> then do
> cd B
> yourbzr merge --weave ../A
> Then notice that mysql-test/r/slave_allow_batching_basic.result and mysql-test/t/slave_allow_batching_basic.test are in "bzr conflicts --text" but have no BASE file.
> I checked that I used your branch.
>

Thanks. Something weird is definitely happening here.

Specifically, if I do "bzr remerge --weave
mysql-test/t/slave_allow_batching_basic.test" and trap based on that
file-id, I can see that the contents is being marked as conflicted, but
it is failing to dump the contents.

Stepping through line-by-line, it seems that this line is at fault:

        for suffix, tree, lines in data:
            if file_id in tree:
                trans_id = self._conflict_file(name, parent_id, tree,
file_id,
                                               suffix, lines,
filter_tree_path)

Basically, for each of OTHER, THIS, and BASE, it checks to see if the
file is present in that revision, and if not it doesn't dump the text.

However base_tree in this case is the one before all of the criss-cross
merges, so it is probably quite old. And we have base-lines even though
the file didn't exist in that base_tree.

I'll try something, but I'm not as sure about what it would do. Namely,
change the 'if' line to:

if file_id in tree or lines is not None:

It turns out that this fails. I'm not positive, but I think it tries to
do something like get the 'executable' bit from the given tree. And
since the content doesn't exist in that tree, it fails...

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksdxgEACgkQJdeBCYSNAANhcACgl6OC/edbVHoPw99taAi1YOZJ
eQ0AoMEG7+u0McJ4gv7D+XRpniTDUDo0
=KCvl
-----END PGP SIGNATURE-----

Revision history for this message
John A Meinel (jameinel) wrote :

I'm happy enough with the current code that I submitted it for review:
  https://code.edge.launchpad.net/~jameinel/bzr/2.0-40412-show-base-weave/+merge/15835

We still don't support --show-base, though we could. This has been split off into bug #494204

Also, there is still a bug that files not present in the global BASE revision do not get .BASE files. This can be tracked in bug #494197.

summary: - show-base for weave merge
+ create .BASE files for --weave (and --lca) merge
Changed in bzr:
status: In Progress → Fix Committed
description: updated
Revision history for this message
GuilhemBichot (guilhem-bichot) wrote :

Hello John. Ignoring bug#494197, I continued my tests.

1) using the same weave merge as the one I described in a previous post ("frazer" into "sp1r-tomas"), I checked a few text-conflicted files, comparing:
- the file with its inline TREE/MERGE-SOURCE markers
- the merge done by "bzr extmerge" (using kdiff3) which uses the BASE/OTHER/THIS files (BASE being the one which your branch nicely produces).
They produce similar results, which suggests that your new BASE file looks good.
A detail: I could observe that when the inline-markers file shows a conflict, sometimes extmerge/kdiff3 would automerge correctly, and sometimes extmerge/kdiff3 would automerge wrongly (which is the worse thing for us - it introduces bugs silently). It's not a problem in bzr as extmerge/xxdiff does find a conflict (so it's rather a problem in kdiff3, which I reported to the maintainer).

2) I did a big merge (133 conflicted files) of two other trees, which was *not* criss-cross; I see merge3 and weave give the same BASE files with same content, which is good.

Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 40412] Re: create .BASE files for --weave (and --lca) merge
Download full text (3.4 KiB)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GuilhemBichot wrote:
> Hello John. Ignoring bug#494197, I continued my tests.
>
> 1) using the same weave merge as the one I described in a previous post ("frazer" into "sp1r-tomas"), I checked a few text-conflicted files, comparing:
> - the file with its inline TREE/MERGE-SOURCE markers
> - the merge done by "bzr extmerge" (using kdiff3) which uses the BASE/OTHER/THIS files
> (BASE being the one which your branch nicely produces).
> They produce similar results, which suggests that your new BASE file looks good.
> A detail: I could observe that when the inline-markers file shows a conflict,
> sometimes extmerge/kdiff3 would automerge correctly, and
> sometimes extmerge/kdiff3 would automerge wrongly (which is the
> worse thing for us - it introduces bugs silently). It's
> not a problem in bzr as extmerge/xxdiff does find a conflict
> (so it's rather a problem in kdiff3, which I reported to the
> maintainer).

Well, the .BASE file is a bit artificial, which means that there is
probably some amount of work that bzr could try to do to encourage
appropriate behavior with the external merge tool.

I know of one case specifically for --lca merge and how it generates
conflicts and marks lines. Specifically if you have:

 A
 |\
 B C
 |X|
 D E

With texts:

A:
foo
bar

B:
foo
b line
bar

C:
foo
c line
bar

D:
foo
b line
c line
bar

E:
foo
c line
b line
bar

In this circumstance:

1) bzr merge --weave of E => D will give E text, and D => E will give D
text. (So the direction of the merge changes the result, which is
usually not great.)

2) bzr merge --lca will conflict, and either preserve "b line" or "c
line" (based on direction), and mark double conflicts for the other
line. So you will get

foo
<<<<<
c line
=====
>>>>>
b line
<<<<<
=====
c line
>>>>>
bar

When figuring out the BASE for this, we can generally either do:

foo
b line
bar

Which causes a 3-way merge to end up with

foo
c line
b line
c line
bar

or We can start with a base of

foo
c line
b line
c line
bar

Which causes a 3-way merge to end up with

foo
b line
bar

Neither is great, as the 3-way tool resolve an --lca conflict with a
unconflicted but doubled (or removed) result. I chose to implement it
such that it omits the lines in BASE, so that they show up in the merge
result. (Easier to delete lines from the result than add lines that were
removed.)

Now, I can also quickly show places where weave works successfully but
- --lca fails, and similarly for 3way merge versus --weave. So there will
always some cases you get wrong.

If you go back to:
http://revctrl.org/CrissCrossMerge

It reminds that under the same circumstance as listed here 3-way merge
with A as a base gives double conflicts, with B or C as a base gives a
"incorrectly clean" result. (More importantly it does this even when the
texts are significantly altered.)

So this may not be a specific bug in kdiff3, just a limitation of 3-way
diff and some difficulties with BASE selection.

John
=:->

>
> 2) I did a big merge (133 conflicted files) of two other trees, which
> was *not* criss-cross; I see merge3 and weave give the same BASE files
> with same content, which is g...

Read more...

Revision history for this message
GuilhemBichot (guilhem-bichot) wrote :

Hi John. Thanks for the "food for thought" (by the way if you know of bugs in --weave, it could be a good idea to file them, so that we know about them :-).
I think that in my case it's really a kdiff3 bug, because it is repeatable without using bzr, on a simple case. I'll attach the script now (though this is off-topic from this bug report).

Revision history for this message
GuilhemBichot (guilhem-bichot) wrote :
Revision history for this message
GuilhemBichot (guilhem-bichot) wrote :

Back to the topic of "how good is the .BASE file generated by --weave", I just conducted another experiment.
I reproduced the criss-cross merge which led John to do all the work on improving --weave in Summer 2008 (the big support incident #00002413). It was a criss-cross merge of 5.1-telco-6.2-merge (<email address hidden>) into 6.0-ndb (<email address hidden>) (both can be branched from mysql-6.0-codebase-bugfixing on launchpad).
With --weave it gives 10 text conflicts.
The "gut feeling base" for this merge is the tip revision of 5.1-telco-6.2-merge during the *previous* 5.1-telco-6.2-merge->6.0-ndb merge (done a few months before).
It is *roughly* true that from this base, 5.1-telco-6.2-merge and 6.0-ndb diverged, and the merge I experimented with, has to reconcile this divergence.
It's only roughly true, precisely because the merge is criss-cross: it has multiple bases as the following debug printouts show:
[bzr_regression_test/6.0-ndb-take2 $] bzr log -r ancestor:../5.1-telco-6.2-merge
find_unique_lca step 1 input: ['<email address hidden>', '<email address hidden>']
find_unique_lca step 2 input: set(['sp1r-knielsen@loke.(none)-20080407060456-28260', 'sp1r-kostja@bodhi.(none)-20080520184326-10676', '<email address hidden>'])
                                                           ^^^^^^^^ this one is what I call the "gut feeling" base.
It's gut feeling but it's practically correct due to how we work in MySQL.
And when I compare the .BASE files generated by --weave, and the files of the "gut feeling base", they are close. It's understandable that they differ, because the "gut feeling base" is not really a base.
So I say "those BASE files are good work!".

Revision history for this message
John A Meinel (jameinel) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GuilhemBichot wrote:
> ** Attachment added: "script to repeat a simple merge bug in kdiff3 (wrong automerge)"
> http://launchpadlibrarian.net/36670982/kdiff3_bug.txt
>

When I tested this with 'diff3' it does cause a merge conflict:
<<<<<<< foo.THIS
    if (!thd->is_fatal_error && thd->spcont &&
||||||| foo.BASE
    if (!thd->is_fatal_error &&
=======
    if (!thd->is_fatal_error &&
        ! (MyFlags & ME_NO_SP_HANDLER) &&
>>>>>>> foo.OTHER
        thd->spcont->handle_error(error, MYSQL_ERROR::WARN_LEVEL_ERROR,
thd))
    {
      /*
        Do not push any warnings, a handled error must be completely
        silenced.
      */
      DBUG_VOID_RETURN;
    }

I guess the issue is that they don't really change the *same* line, they
just change neighboring lines. Certainly one could argue for a clean
merge to:

    if (!thd->is_fatal_error && thd->spcont &&
        ! (MyFlags & ME_NO_SP_HANDLER) &&
        thd->spcont->handle_error(error, MYSQL_ERROR::WARN_LEVEL_ERROR,
thd))
    {
      /*
        Do not push any warnings, a handled error must be completely
        silenced.
      */
      DBUG_VOID_RETURN;
    }

(I believe bzr conflicts in this case, as they are modifications on
'touching' lines. But it is at least arguable that the 'same' line was
not modified by both THIS and OTHER.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkshfzgACgkQJdeBCYSNAAO9bgCfaPOBypEZsxRGP5K69L0SHTzJ
qacAnR3g4k1p4VRluDjMYISTMLxCAjVH
=FqPM
-----END PGP SIGNATURE-----

Revision history for this message
GuilhemBichot (guilhem-bichot) wrote :

Yes, bzr --merge3/--weave conflicts, so does xxdiff, and diff3 as you verified. kdiff3 doesn't. I'll see what kdiff3's author thinks about this. I believe that using more lines of context would give a safer merge (a conflict) in kdiff3. That probably relates to what you call "modifications on touching lines".
For sure, as far as I know, no tool will properly resolve a conflict where one side added "a++;" on line 10 and the other side rather added "a++;" on line 20. All tools will generate an automatic merge with both "a++" statements (which yields a wrong program). But in my testcase, as involved lines are so contiguous to each other... maybe something can be done... we will see.

John A Meinel (jameinel)
Changed in bzr:
milestone: none → 2.1.0b4
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.