Hi!
>>>>> "Kristian" == Kristian Nielsen <kniel...@knielsen-hq.org> 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
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
