Rethinking last-revision

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:

|>I think it's a mistake to have two last-revision indicators per
|>location.  It breaks our API, it breaks our UI, and it breaks our brains.
|
|
| So by "location" do you mean per bzrdir?

Yes.

| If I understand your proposal properly, we can still have two
| last-revision markers in play, one in the branch reference and one in
| the referred-to branch.  The question is just whether the one in the
| checkout's bzrdir is seen as part of the working tree or as part of the
| reference to the other branch.

Right.  And the major impact of this is that the last-revision of a
standalone branch's tree can't be out of sync with its branch.

Especially if you assume that branches have only a last-revision marker,
not a revision-history, lightweight checkouts start to look like bound
standalone branches that can't be unbound.

So this is a logical extension of my previous idea to make checkouts
look as much like bound branches as possible.

| In some ways it would be nice to have the working tree avoid knowing
| anything about revisions.  However it does need to know about
| pending-merges - and if we tracked partial merges then possibly in a
| slightly complex way.  The basis revision is quite similar which
| suggests perhaps it should be in there.

I'm certainly not claiming trees shouldn't make mention of revisions.
You're right in a sense, but I think the simplicity of
one-revno-per-location is worth it.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFELzlf0F+nu1YWqI0RAkpWAJ4ziDgs9LHN1T+F+8uiDQ0RqR7L9wCfSBZ/
L4qcdp0v780uJVD04dA1A9s=
=E1GN
-----END PGP SIGNATURE-----