star or parallele merge

[David Allouche]

On Tue, 2005-10-04 at 10:44 +1000, Martin Pool wrote:
-------------------------------------------------------------------------------------

> On 03/10/05, David Allouche <david at allouche.net> wrote:
> > In the Arch tradition, "missing" would only show G-H-I-M. In my
> > experience that is what one wants most of the time.
> >
> > However, I have found that I occasionally wanted recursive-in-revisions
> > missing, J-K-L listed a as part of M. Mostly, I found that useful when
> > trying to manually resolve complicated merge situations involving mesh
> > merges or cherrypicks.
> >
> > A flat listing including J-K-L is not really useful in my experience.
> >
> > I think the default should be: show only G-H-I-M with some indication
> > that M is a merge.

On Mon, 2005-10-03 at 09:14 -0500, John A Meinel wrote: 
> Well, I think that Gustavo Niemeyer just submitted a patch, which lets 
> "bzr log" show the merges for a given revision. Since I do believe that 
> "bzr missing" uses the LogFormatter (if it doesn't, it should), then I 
> think we will get the nested list by default.
> 
> So I guess the algorithm would be (in newformat):
> 
> show_missing(b_this, b_other, <extra_options>):
>    a_this = set(b_this.ancestry())
>    a_other = set(b_other.ancestry())
>    rh_other = b_other.revision_history()
> 
>    rh_other.reverse()
>    missing = []
>    for rev_id in rh_other:
>      if rev_id not in a_this:
>        missing.append(rev_id)
>      else:
>        # I'm guessing we don't need to go any
>        # farther, since once we have one of the
>        # revisions, we should have all the history
>        # Is this a true assumption?
>        break
> 
>    # I like logs going forward in time, some obviously
>    # prefer the opposite (since bzr log works that way)
>    missing.reverse()
> 
>    lf = LogFormatter(format=format)
>    for rev_id in missing:
>      lf.show_log(b_other, rev_id)

That's not quite what I have in mind. In a "missing" listing, you are
not really interested in the what a missing revision merged, but what it
merged that is still missing. That why I referred to the feature as
"recursive missing".

Typically, that's useful in mesh situations when you are missing a
revision B10 from branch B, which merged branch A, but you already
merged branch A (and possibly resolved conflicts).

In that case, merging revision B10 again is likely to cause conflicts
(because diff3 just does not cut it). So if you can see that B10 was not
merged, but all its changes were already merged, then you can safely
mark B10 as merged without worrying about the spurious conflicts.


On Tue, 2005-10-04 at 10:44 +1000, Martin Pool wrote:
> Yes, that sounds good.
> 
> The purpose of missing is to show what can/will be merged.
> 
> In the new weave format, which should become mainline this week, you
> can use get_ancestry() to speed calculation of what is missing.  It
> might be easiest to get a list of all missing revisions and then work
> out the nesting.

Probably easiest. But keep in mind that tens of thousands of revisions
of history is common. From the report about Mercurial from James
Blackwell, I think it's important to seriously worry about being really
fast.

> One use case is that someone looks at the list of missing revisions
> and decides they want only some of them.  They should then be able to
> take a revision number from the list and use that with 'merge -r' to
> get only up to that point.

That's not something I personally want to do often. Here are the common
uses cases from my daily Arch use.

USE CASE WhatsNew: Is my branch out of date? If yes, plain pull/merge.

        Flat missing is enough. But recursive missing can be useful here
        to tell what this "merge mainline" revision actually contains.

USE CASE WhatsPending: has my branch been merged? If yes, I can pull or
switch to the mainline. If no, I need to send some patches for review or
nag the reviewer.

        That's the use case for "baz missing --from". So it's only
        tangentially related to the current discussion. Flat listing is
        what we want here.

USE CASE WhatToPick: I want to pick a specific fix. Get missing listing,
and replay a chosen revision.

        Flat missing is definitely what I want here. Recursive is just
        clutter.

USE CASE WhatTheMergeHell: Merging caused spurious conflicts. What is
the situation? Which merge strategy can I apply to resolve the problem.

        Recursive missing is definitely what I want here.


> On 03/10/05, David Allouche <david at allouche.net> wrote:
> > Even better if that distinguishes pure merges, pure
> > cherrypicks, mixed merges (with additional changes or conflict
> > resolution), and mixed cherrypicks. Currently, in Arch, I'm making the
> > distinction by using a convention in the log message ([merge], [pick],
> > [merge conflicts], [pick conflicts]).

On Tue, 2005-10-04 at 10:44 +1000, Martin Pool wrote:
> That's probably a good convention even if we (try to) automatically
> track them.  Perhaps you could add something about your method to the
> wiki?

Okay. I'll do something.


On Mon, 2005-10-03 at 09:14 -0500, John A Meinel wrote: 
> Cherry picks are not well defined in bzr. Currently, if you merge a 
> revision, you just say that it is a parent of the next committed 
> revision. Which implies that you have merged all of OTHER's parents.

Making the tool aware of cherrypicked history is really useful. I
understand how explicit cherrypick support à la Arch can be problematic,
but I can imagine some way to get around it.

One solution would be to have, in addition to the regular ancestry which
has DAG topology invariants, a picked ancestry that names individual
cherrypicked revision (just like Arch patchlogs).

On commit (after merge or pick) any revision that has become part of the
regular ancestry would be removed from the picked ancestry. Pull would
only be allowed if the OTHER revision contains all the current picked
ancestry of THIS in its regular and picked ancestry.

Actually, I cannot come up with any solution that's satisfyingly useful
and simple and which does not degrade into this proposal when thinking
it through or involves a radically different model. Suggestions welcome!


On Mon, 2005-10-03 at 09:14 -0500, John A Meinel wrote: 
> I believe the "bzr merge" command can let you select the base, which 
> effectively does a cherry pick, but doesn't set the parent, so another 
> merge would try and re-apply the patches. 
> 
> However, since bzr uses diff3 (Merge3), to merge, it is very likely that 
> it won't conflict, as long as the area hasn't been changed.
> As we switch to Weaves, in theory WeaveMerge won't conflict, as long as 
> it sees that the change happened after a merge.
> 
> I'm not sure how weaves will work with cherry picked merging, but 
> theoretically the newly merged lines should be marked with the OTHER 
> revision.

diff3 does not cut it, and in practice, cherrypicking often does
conflict with diff3 merging.

Typically:

A abcde -> aBcde -> aBcDe -> aBcfe
     \                |
      \              pick
       \              v
B       `----------> abcDe


In that situation, merging A with B will cause a conflict. And this sort
of things happen very often in real life because on a given branch,
activity tends to be concentrated in specific areas of the code.

On the other hand, anything based on weave merge should be able to
handle that.

But the history is not just useful to merge tools, it's also intended
for human inspection, so cherrypicking needs some specific support even
if the merge logic does not need it.

> On 03/10/05, David Allouche <david at allouche.net> wrote:
> > An option, for examples -r, --recursive could recursively show the
> > missing merged revisions and, distinctively, the independently merged
> > revisions in missing revisions (without recursing in those).
> 
> We could use -R, --recursive since -r is already used for --revision.

I'm slightly uncomfortable with using both -R, and -r for things that do
not involve recursive filesystem traversal. However, the fact is I
always talked about "nested trees" or "nested missing" (for missing
revisions in nested trees), and never of recursive trees.

-r, --revision
-R, --recursive

Fine with me.
-- 
                                                            -- ddaa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051004/5104a915/attachment.pgp