bzr revno always an integer?

[Eric Siegerman]

On Sat, 2011-05-21 at 03:51 -0500, Matthew D. Fuller wrote:
> Since dev1 is a
> superset of main, it can be pushed over main; now the revno has moved
> back 1, though the branch has moved forward.

It's possible to guarantee monotonicity for a given branch by
setting "append-revisions-only" -- http://bit.ly/lanYLi .

That forbids the sorts of operations that can cause the revno to
decrease, e.g. pushes and pulls.  Merges are still allowed, since
a merge (or rather, the following commit) adds a new rev rather
than "grafting on" existing ones.

Even absent your need for monotonically increasing revnos,
"append-revisions-only" can be desirable for a mainline branch.
Imagine this history:

  d
  |
  c
 /
B
|
A

A-B are the mainline; c-d are a feature branch.

As it happens, nothing has been committed to the mainline since
the branch point, B.  Here, as in Matthew's example [not quoted],
the feature branch is a superset of mainline, and so one could
push or pull the former into the latter.  But doing that would
produce:

d
|
c
|
B
|
A

All the feature-branch revs are now mainline revs (corollary:
they *all* have integer revnos), including the work in progress
-- false starts, ones that didn't pass tests yet, etc.  There's
not even any "punctuation" between the feature branch's revs and
what went before or will come after.  One might as well not have
used a feature branch at all.

If you instead merge the feature branch into mainline, you get
the typical Bazaar'ish history:

E
|\
| d
| |
| c
|/
B
|
A

in which the feature-branch revisions are still present in the
history, but their "branchiness" is preserved (they get dotted
revnos in the mainline branch).

"append-revisions-only" enforces the latter behaviour, which is
what many teams want for their project mainline.


<aside>
In another thread, the question of "bzr revert --forget-merges"
came up.  The sequence:
    bzr merge $feature_branch
    bzr revert --forget-merges
    bzr commit

would turn the original situation above:
  d
  |
  c          E
 /    into   |
B            B
|            |
A            A

Here, rev. E's content is identical to that of rev. E in the
previous example, where there was no --forget-merges, but its
recorded history is very different:  its feature-branch ancestors
have been discarded entirely.  (Revs c and d still exist over in
the feature branch itself, of course, but not in the mainline,
which is what matters for the long term.)

(Sorry; I don't understand rebasing well enough to write about
it with any confidence...)
</aside>

  - Eric