Rethinking last-revision

Robert Collins robertc at robertcollins.net
Mon Apr 3 01:25:07 BST 2006


On Sat, 2006-04-01 at 20:13 -0500, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robert Collins wrote:
> | On Thu, 2006-03-30 at 19:00 -0500, Aaron Bentley wrote:
> | 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.
> 
> It's a representation of a sequence of source trees.  Not really the
> same thing at all, I think.
> 
> I think permitting tree and branch to vary their last-revision is a
> choice we've made.

Well. The branch history is such a sequence, but the tip of the branch
which is what branch.last_revision() references is an alias to a tree.
As is the working tree. 

> | 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
> 
> Since this produces bound branches, I don't see the relevance.  So I'll
> assume you meant to add --lightweight.

In actual fact I did mean --lightweight. BUT: it should make no
difference, I would expect exactly the same behaviour from bound
branches in terms of UI.

> | 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.
> 
> Yes, but b-two's branch isn't B, it's reference-to-B.  I'm proposing
> that in addition to location, b-two's reference-to-B would also include
> a last-revision pointer.  So it would behave exactly the same as it does
> now.

Currently in a lightweight checkout B-two's branch *is* B. Its /located/
via a pointer, but that pointer has no additional state or behavioural
changes.

If you add a last-revision pointer to the branch-reference, and remove
it from the tree, I dont understand what we gain. We've /still/ got two
last-revision values for a single logical branch (B and B-two), and
still have the ui challenges that this gives rise to.

> |>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,
> 
> Your example above will behave exactly the same

In your proposal the tree in Branch B will have a different
last-revision to the branch in B-two, but you won't be *recording* that
difference. Thats a *fundamental* change to what we have now, and its
the linchpin I keep coming back to. 

It *will not* behave exactly the same.

> | 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.
> 
> I think the user experience would be much worse if it were a metadir
> tree,  because there's no indication that the tree is out of date.  At
> least if you run 'status' now, you get a tipoff that something's funky.

Huh? bzr info will tell you immediately that the tree is out of date.

> But since Martin wants to have a tree there, I think the best option for
> that case is to keep said tree up to date.

In a metadir tree they will immediately be able to do 'bzr update' and
get the latest code managed by bzr, rather than doing a bzr revert which
is counter-intuitive.

> |>- - 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.
> 
> This is the part that's a design choice.  There's no requirement to
> permit the branch and tree to vary.  This is obvious because we haven't
> done so in any release.

And we've had bugs reported consistently because of this. Do we want to
solve them ?

> | '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.
> 
> I am proposing not to need the data in the first place.

Sure. But I must still be failing to understand. All I see is moving the
data from from the place that varies in lockstep with it to the branch
reference, which sinks the ability to manage the branch B in the example
up top properly.

> | 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.
> 
> I'm not cool with the idea of having two last revisions and hiding one
> of them in the ui.  That's the situation we have, and it's confusing.

Ok. I'd like to focus on solving *this* issue, IMO its the key one.

> |>- - 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.
> 
> "tree inside the branch" would be laid out like this:
> 
> mybranch/
> mybranch/.bzr
> mybranch/.bzr/branch
> mybranch/.bzr/branch/revision-history
> mybranch/mytree
> mybranch/mytree/.bzr
> mybranch/mytree/.bzr/checkout ...
> mybranch/mytree/.bzr/branch
> mybranch/mytree/.bzr/branch/location
> mybranch/mytree/.bzr/branch/last-revision
> 
> "branch inside the tree" would be
> 
> mytree/.bzr
> mytree/.bzr/checkout ...
> mytree/.bzr/branch
> mytree/.bzr/branch/location
> mytree/.bzr/branch/last-revision
> mytree/mybranch
> mytree/mybranch/.bzr
> mytree/mybranch/.bzr/branch
> mytree/mybranch/.bzr/branch/revision-history
> 
> So when I say 'inside' I mean that one thing's root being inside the
> other thing's root, instead of having them at exactly the same location.

To me this seems to be rather orthogonal, I don't see at all how it
resolves the problem.

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/20060403/f32f124f/attachment.pgp 


More information about the bazaar mailing list