Rethinking last-revision

[Aaron Bentley]

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

Robert Collins wrote:
| On Thu, 2006-03-30 at 09:47 -0500, Aaron Bentley wrote:
|
|>I tried to implement my proxy branch for checkouts yesterday, and I ran
|>into a snag:  my CheckoutBranch was creating a WorkingTree, and my
|>WorkingTree was creating a CheckoutBranch, ad infinitum.
|>
|>This sort of thing can be fixed, but not without pain, because it would
|>mean altering, say, the Branch.open API.  The real problem is that the
|>WorkingTree and CheckoutBranch both want to own the last-revision marker.
|
|
| Can you enlarge on what CheckoutBranch is? I'm not clear on it...

This is the idea I proposed in "[RFC] make checkouts as much like bound
branches as possible"

It is a Branch composed from a Checkout and a BranchReference, whose
last_revision is determined from the Checkout, with almost all other
data coming from the referenced branch.

There is some implementation here, but I don't expect to continue that
line of development:

http://panoramicfeedback.com/opensource/bzr/repo/proxybranch/

|>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.
|
|
| I think its unavoidable though, there are physically two things at the
| one place, and trying to manage that well without representing what
| exists is extremely hard.

That is true in our current design, but that's what I'm proposing to
alter.  I am proposing that there be only one last-revision indicator:
for a normal branch, the indicator is unchanged.  For a branch
reference, that would be a file containing the revision-id of a revision
in the revision-history of the referenced branch.  Working trees would
not have a last-revision indicator.

|>For those few cases where it's desired to separate the branch and
|>working tree's last-revision, we can simply put the tree inside the
|>branch, or the branch inside the tree.  This simplifies the UI for those
|>cases.

You argued against my earlier 'light bound branches' proposal, saying
you believed it was a good thing that the tree's last-revision could
vary from the branch's last-revision, as happens when you push into a
remote metadir standalone branch.

I am arguing that
- - Cases where it is advantageous to vary the tree's last-revision
independently from a branch at the same location are extremely rare.

- - Those cases are not, by themselves, a good enough reason to add
last_revision to the WorkingTree.

- - Those cases can be served by putting the tree inside the branch, or
the branch inside the tree.  The tree would then be a checkout, which
would have a branch reference format 2, and thus a last-revision.

- - This actually serves those cases better, because when the branch and
tree are at different locations, our current UI can distinguish between
them as targets for operations.

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

iD8DBQFELHEe0F+nu1YWqI0RAom8AJ95uFGAkFIyoMsLdlGZ7agGKxVcGACfXHaf
h2xtXfWyOgNr07j2ASxQbL4=
=aQPa
-----END PGP SIGNATURE-----