Confused about stability of revno's

[Stephen J. Turnbull]

Stefan Haller writes:

 > - 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.

Don't do that.  Instead, Bob should merge his branch into master, then
pull master back into his branch.

 > 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*?

No, it means they're more useful if the workflow obeys certain
disciplines.

 > 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.)

Have you tried it?  AFAIK, QA *can* check out the revid and confirm
that the fix works there -- master contains *all* of the history (logs
*and* revisions to code) of all branches merged into it.  But in
principle they *also* need to check out the merge and make sure that
Bob's changes don't cause a regression.