maria-developers team mailing list archive

[Michael Widenius <monty@xxxxxxxxxxxx>]

Hi!

>>>>> "Kristian" == Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> writes:

K> Following up on this, I just learned about the bzr option
K> append_revisions_only that can be set on a branch.

K> This option can be used to enforce that the main history (sequence of
K> primary/left-hand parents from the tip) correctly reflects the series of
K> pushes into the public tree.

K> So assume this sequence of events:

K> 1. Joe branches lp:maria (revision 1000), and starts hacking on a patch.
K> 2. Other developers push revisions 1001, 1002, and 1003 to lp:maria.
K> 3. Joe finishes the patch, the review is good. He runs `bzr merge lp:maria`,
K>    followed by `bzr push lp:maria`.

K> As it is now, the resulting history of lp:maria will look like this:

K> 1002 Joe (merge)
K>   1000.1.3 | Other
K>   1000.1.2 | developer's
K>   1000.1.1 | commits
K> 1001 Joe's patch
K> 1000 Starting point

K> So it is not at all clear that the other commits were at some point pushed
K> individually to lp:maria. And if someone goes to look at revision 1002
K> thinking to see one of the other developer's commits, it will be missing (or
K> worse refer to the wrong commit after further pushes).

K> But if we set the append_revisions_only option on lp:maria, instead of this
K> Joe will get this error:

K> bzr: ERROR: Server sent an unexpected error: ('error', 'Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "lp-139886317008592:///~knielsen/maria/tmp-buildbot-test".')

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 ?

- 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.

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

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).

K> (Incidentally, this way also makes it possible to correlate the branch history
K> directly with build history from Buildbot/Pushbuild, something I really missed
K> in the BitKeeper days).

Regards,
Monty