Hi!
"Kristian" == Kristian Nielsen <knielsen@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