Confused about stability of revno's

[Harald Meland]

[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:

If the master had been init'ed with

  bzr init --append-revisions-only

Bob's push attempt would result in the following error:

bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "master".

... and revno 2 in master would remain an alias for the same
revision-id it was when that revision was first created in the master
branch.

For Bob to push his change in such a setup, he would then need to
merge his own branch into (a copy of) the master branch (and then push
the copy to master).

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

Umm, no -- in the non-append-revisions-only case, revnos can still be
useful locally.

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

... which would also include Bob's changes, which could have broken
things again.  If QA want to check whether the commit that claimed to
fix bug #123 really did fix that bug, they could check out the revid
from the master branch, but that checkout wouldn't be on the master
branch's "mainline".

It seems to me that you would really like your master branch to be
append-revisions-only.  You can add

append_revisions_only = True

to the master branch's .bzr/branch/branch.conf to make this so
after-the-fact.
-- 
Harald