maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Michael Widenius <monty@xxxxxxxxxxxx> writes:

> K> In this case, Joe will instead have to do this:
>
> K>     bzr branch lp:maria  # or bzr pull lp:maria into an existing clean clone
> K>     bzr merge ../branch-with-patch
> K>     bzr commit -m"merged with trunk"
> K>     bzr push lp:maria
>
> K> Then the resulting history will be this:
>
> K> 1004 Joe (merge)
> K>   1000.1.1 Joe patch
> K> 1003 | Other
> K> 1002 | developer's
> K> 1001 | commits
> K> 1000 Starting point
>
> K> Which is much nicer, IMHO.
>
> K> So basically append_revisions_only enforces the merging style that I, Sanja,
> K> and Monty already proposed as a good practise.
>
> K> So I propose to add this option to the 5.1, 5.2, and 6.0 trees on
> K> Launchpad. This will provide a clear record of the push history in the
> K> repository, at the cost of enforcing the "good practise" merge style with one
> K> extra bzr step.
>
> K> Any opinions? Reasons not to do this?
>
> I like the end result of this approach, but I have got a couple of
> questions/concerns about this:
>
> - Doing the extra branch is a bit of a pain and slows down things if you
>   pushes a lot.  It would be nice to get this done internally in bzr as an
>   part of the merge.
>   Should we talk with canonical to get this option into bzr ?

Yes, this is the main pain point.

There are a couple of things that can help with this:

1. If bzr people were to implement `bzr pull --reverse`, then there would be
no additional step, so problem would be solved (as long as one remembers to
use the --reverse). The merge to be done is exactly the same one way or the
other, the only difference is which tree becomes the primary parent and which
becomes the secondary.

2. I suppose most people (like me) in any case keep a branch around of the
main trees that we pull into regularly. This can be used to do the merge to
avoid the need for an extra `bzr branch`. But then if someone else were to
push to the main branch in-between, the clean local branch would have to be
re-created of course.

3. I often use bzr with `bzr branch --no-tree` branches and seperate `bzr
checkout --lightweight` working trees. This sometimes greatly speeds up
operations when one can use `bzr switch` to avoid having to make bzr check out
a complete working tree (which it does really slowly). But it has its own
hassles also due to the need to keep track of more directories, so it is no
silver bullet.

With --lightweight checkouts, one can do something like this, all the steps of
which run in a few seconds (on my machine at least):

    (cd ~/repo && bzr branch --no-tree mariadb-5.1 mariadb-5.1-merge)
    bzr switch ~/repo/mariadb-5.1-merge
    bzr merge ~/repo/branch-with-patch
    # compile, test
    bzr push lp:maria

> - What is the sequence to do if someone does a push of this code at
>   between the step 3) and step 4):
>
> 1)    bzr branch lp:maria  # or bzr pull lp:maria into an existing clean clone
> 2)    bzr merge ../branch-with-patch
> 3)    bzr commit -m"merged with trunk"
>
> Someone else pushes here.
>
> 4)     bzr push lp:maria
>
> Doing the 'merge' again would be a real pain.

The issue is really the same no matter which of the two methods you use. If
someone else pushes in-between, you need to merge again.

> I assume one should in this case start again from step 1) and do the
> merge with the new tree?

Yes. One would need a new fresh branch of the now updated lp:maria tree, and
merge into that. One could merge in either the original branch-with-patch or
the branch with the first merge, depending on whatever works best (using the
original will save a merge changeset, but the line of primary parent commits
will be the same in the resulting push either way).

> K> If there is general agreement I will add the option (the process is somewhat
> K> inconvenient, but I tested a procedure using sftp and that works ok).

I discussed this with Monty on IRC. I will implement it later this week in out
Launchpad trees (and if there turns out to be unforseen problems with it, it
will be easy enough to remove it again).

Monty also will talk to Jani to get this method into autopush (in the autopush
case this should be no extra hassle at all for the person pushing).

 - Kristian.