Rethinking last-revision

[Robert Collins]

On Thu, 2006-03-30 at 19:00 -0500, Aaron Bentley wrote:

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

I don't think that there being two physical objects is a property of our
internal model - its a property of having two representations of
[roughly] the same thing : the branch data is one representation of a
source tree (heavily compressed etc etc), the working tree is another
representation - one that is use editable.

For a trivial conceptual demonstration of this, imagine that you have a
branch B with two commits in it.

bzr checkout B B-one
bzr checkout B B-two

cd B-one
bzr uncommit
bzr revert
cd ../B-two
bzr diff

B-two no longer has a last-revision in the history of B, and its content
is still unchanged.

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

or when you have two checkouts and commit or uncommit in one.

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

I disagree with this - my example above is not uncommon, and the
original SFTP example is actually hitting us right now on bzr.dev - we'd
be much better off in terms of user experience if we had no tree there.

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

Hmm. I see it the other way around - the physical consequence of having
two copies of something is that the things evolve separately. 'copying
is branching'. This is a variation on that - so I seek reasons
to /remove/ last-revision, because discarding the actual data makes it
much harder to provide an explainable ui. Note that this does not mean
'show all the data we have' - I'm cool with the idea of only showing one
last revision at any point in the ui.

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

I presume in a physical sense you mean 'inside the same dir in .bzr' -
but in a logical sense I'm still wildly confused.

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: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060402/800c4e0c/attachment.pgp