RFC: revno pertubation rules

[Robert Collins]

This is a draft, I'm trying to document exactly how and why revno's
change, to ensure any new logic written can accomodate that.

John, I'd appreciate a double-check on this, as you altered the code
last :)

Events that can change revision numbers->revision id mappings for a
branch:

 * commit
 * tip rollback
 * tip advance
 * ghost filling

commit
------

Commit adds a mapping of new-revid->new-revno, and also causes any
merges to get assigned branch numbers and revnos within that. I'm pretty
sure that it never renumbers older revisions.

ghost filling
-------------

A ghost being filled can cause previously allocated revision numbers
that actually should have been given to the ghost to get renumbered up
to a higher branch number. Note that in the event of mainline ghosts
(like arch conversions), this can renumber everything.

tip advance
-----------

This can be reduced down to commit

tip rollback
------------

If the tip is rolled back down the left hand side, all the revision
numbers for the popped revisions *and their merges* are invalidated.
Note that pull with a different LHS (whether --overwrite or convergence)
can be considered a case of rollback + advance.

-Rob


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080814/82081596/attachment.pgp