[MERGE] deprecated EmptyTree

[Aaron Bentley]

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

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.

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

But if you want to be able to conveniently generate an 'empty tree' tree
that has a root, I have no problem with you adding convenience methods
for that.  It doesn't mean that the NULL_REVISION's tree must have a root.

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

iD8DBQFEwMOi0F+nu1YWqI0RAsgLAJ9eKii0dCEQZMv7KH2Q+KbLfOQWRACfa/Ua
goFUiRtl5MD7nYBzCONzU04=
=+pPe
-----END PGP SIGNATURE-----