Hi!
"Kristian" == Kristian Nielsen <knielsen@knielsen-hq.org> writes:
Kristian> Kristian Nielsen <knielsen@knielsen-hq.org> writes:
Following up on this, I just learned about the bzr option append_revisions_only that can be set on a branch.
Kristian> Any opinions on this? Kristian> Having thought more on this, I really think we should enable Kristian> append_revisions_only. Kristian> There are many tools (and people as well) that depend on revision numbers and Kristian> have no knowledge about using revid: revision ids. And they often get confused Kristian> when a push changes the revision numbers of lots of recent commits. Kristian> Just two days ago on Tuesday, the merge of MySQL 5.1 changed the last 6 Kristian> revision numbers or so, and this seems to have confused the Buildbot Bzr code Kristian> to the point where it choose to not build the new merge at all. (I have written Kristian> and installed a new method for Buildbot to detect pushes that hopefully solves Kristian> this problem. But I fear there are more places in the Buildbot code which Kristian> assumes revision numbers are simple numbers that can be compared meaningfully Kristian> to determine their ordering). Kristian> In any case, having simple revision numbers that correctly reflect the push Kristian> history is just so much nicer to work with, and this is something I really Kristian> missed with Bitkeeper and Pushbuild. Kristian> So unless there are objections, I want to implement this change early next Kristian> week. At most, developers will need to do an extra pull into a fresh clone of Kristian> main trees before pushing, if they forget this when merging up. And if needed, Kristian> we can probably ask Bzr developers to implement a simple --reverse or Kristian> --use-other-as-base option to make even this extra step unnecessary. Kristian> - Kristian. Agree with above. Kurt, can you talk with the bzr devlopers to implement a --reverse merge option to bzr? Regards, Monty