[MERGE] deprecated EmptyTree

[Robert Collins]

Replying to you and John at the same time...

On Fri, 2006-07-21 at 08:08 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robert Collins wrote:
> > On Fri, 2006-07-21 at 01:10 -0400, Aaron Bentley wrote:
> >> Robert Collins wrote:
> >>> On Fri, 2006-07-21 at 00:48 -0400, Aaron Bentley wrote:
> >>>> In nested-trees, the empty tree has no root file-id.  The root id is
> >>>> introduced by the first commit.  It must be introduced in the first
> >>>> commit, because the inventory serializer throws an exception if there's
> >>>> no root id.
> >>> Can it still serialize existing trees?
> >> Yes.  I didn't modify the serializer; it already had that constraint.
> >>
> >>> Or does their ROOT_ID id count as
> >>> a root file-id ?
> >> Exactly.  TREE_ROOT counts as a root file-id.
> > 
> > What do you think of having the empty tree have a root with a file-id of
> > ROOT_ID ? I think it is a desirable property that an empty tree be able
> > to match precisely a tree committed with no files and no ancestors.
> 
> Actually, it doesn't appear to be very useful.  When I made that change,
> I had to fix every use that assumed EmptyTree had a root id.  Almost
> every use of EmptyTree was EmptyTree().inventory, so I replaced them
> with Inventory().

I find it hard to conceive of 'tree' without a root. In my prior
thinking, the root node is always present, because if it isn't, you dont
have a tree. 

> > I realise this is different to what you have done - so I'd like to know
> > what things it would impact negatively.
> 
> Well, I think it means a bit more special casing for operations that
> compare trees.  diff / status -r 0..1 shouldn't show deletion of the
> tree root.  (They don't show an add of the tree root right now, but I
> think that's at least plausible, even if we decide not to.)

So, if iter_entries yields the root, we have a choice of special casing
the change of root id value, or special casing the addition of a root
node. I'm not sure which is nicer..

> If we do a merge of unrelated trees, and BASE has a TREE_ROOT for a
> root, and OTHER has UNIQUE_ROOT-asdf for a root, and THIS has TREE_ROOT
> for a root, the merge will attempt to delete TREE_ROOT.  It won't
> succeed of course, but it will produce a conflict.  Preventing that
> conflict would require special-casing.

Well, I think there is a general-special-case for handling directory
nodes that is different to handling file nodes, for merge. Which we
haven't implemented yet. The point of this general-special case is to
make merging between trees with different directory ids nicer - merging
the contents rather than forcibly keeping them separate. I dont see the
root node needing root-specific-special casing if this is done.

> So it seems to me that having a root id for the empty tree doesn't fit
> our model very well, and doesn't provide much convenience (especially
> once EmptyTree is deprecated).

Well, an 'empty tree' will still remain, but it will just be accessed
via a repository request always.

Anyhow, AIUI you are saying 'when you deleted the root node from the
empty tree in your tree-roots branch, a lot of stuff had to be
changed.'. To me thats a sign that we might be better of not deleting
the root node at all, rather having it change value at the first commit.

John said 


> Well, it is a little unclean for EmptyTree to have a root node. Since
> it
> is theoretically empty.

But is a tree a tree without a root ? I mean, a tree is the contents of
a directory that has been blessed as the root. If that directory does
not exist, can we still claim to have a tree object? I think it makes a
great deal of sense to say that 'A tree always has a root node', just
like we require a directory node to exist to pass a directory around.

> Beyond that, once we get real root ids, the benefit pretty much
> disappears. Robert wants it so that a tree which is empty has no
> differences from EmptyTree. (Since right now all tree roots are
> ROOT_ID).

Well, I want it for consistency, to avoid special cases, and to allow
the tree interface to be understandable.

> If there are no other reasons, then I would be against giving
> EmptyTree
> a root id. There may be more theoretical reasons, like we want every
> tree to have a root, etc. I don't think having root change its id is
> any
> better than an explicit adding of the root id, but it isn't
> specifically
> worse.

For me, changing the id of the root is a lot cleaner than adding one,
but thats because I think a tree needs a root to be a tree. (In fact,
having Tree and the root be separate objects does not make all that much
sense to me, but thats a different discussion).

> I'm just concerned that's Roberts request is just pushing the bugs
> further down. Because once we have real roots, then even an empty
> working tree won't match EmptyTree. 

I dont see why it wont match :). In fact, my tree interface tests will
assure that it is. I think that an empty working tree *may* be different
to an empty tree, once its had a root id assigned to it, but only after
that.

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/20060722/3318f63f/attachment.pgp