Confused about stability of revno's

[Stefan Haller]

Hi,

I seem to remember that I read somewhere in the bazaar documentation
that revno's are supposed to be stable within a given branch; i.e. that
"branchname + revno" is a stable identifier for a changeset.  I can't
find that place in the documentation any more, and some brief testing
shows that it doesn't appear to be true when merges are involved.  I'm
not sure I'm missing something.

Consider this simple scenario of a corporate environment: 

- There's a master branch on a central server, let's say it's at
  revision 1.

- Alice and Bob both branch from it. 

- Alice fixes bug #123, commits it locally in her branch, and pushes to
  master.  Her fix is revno 2 in master, so she adds "Fixed in
  master @r2" to the bug ticket #123.

- Meanwhile, Bob implements feature X in his branch, commits locally,
  tries to push, can't. So he merges master into his branch, commits
  locally, and pushes to master.

After this, master's history looks like this:

    revno: 3 [merge]
    committer: Bob
    branch nick: Bob
    message:
      Merged with master
        ------------------------------------------------------------
        revno: 1.1.1
        committer: Alice
        branch nick: Alice
        message:
          Fixed bug 123.
    ------------------------------------------------------------
    revno: 2
    committer: Bob
    branch nick: Bob
    message:
      Implemented feature X.
    ------------------------------------------------------------
    revno: 1
    ...

Now QA comes along, looks at the ticket for bug #123, checks out and
builds master @r2 to verify whether the bug is really fixed, and finds
that it isn't.

Doesn't this mean that revno's can't really be used for *anything*?

(I do realize that this issue could have been avoided if Bob had rebased
instead of merged, but I'm not sure if that's any help in general.)

And I wonder what else could have been used instead of the revno as a
reference to the changeset that fixes the bug.  The revid doesn't work
either, because QA wouldn't be able to check out master at that revid.
(They would have to do a bzr log -n0, find the merge that contains that
revid, and check out that revision.)

Could somebody shed some light on this?

Thanks,
   Stefan


-- 
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/