Rethinking last-revision

[Aaron Bentley]

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

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

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

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

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

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.

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

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

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

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

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

iD8DBQFELyU50F+nu1YWqI0RAmQGAJkBiqZtYOOOZwsIEH0iSmIAAdsrxgCfUFgB
IMMfURMEedrkoZsdBCP9rZo=
=p3En
-----END PGP SIGNATURE-----