[MERGE] Unique roots for bzr

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> Aaron Bentley wrote:
>>> John Arbash Meinel wrote:
> 
> ...
> 
>>> Anyhow, why does a doctest matter?  Especially given that it's said
>>> 'TREE_ROOT-12345678-12345678' since July 2005?
> 
> It has nothing to do with the doctest. It was just something that
> reminded me of this fact, which was something I wanted to bring up. I
> admit it isn't super critical, and we should change escaping in other
> ways. But I did see that using a default id of TREE_ROOT-foo for new
> trees is not as nice as using 'tree_root-foo'.

Okay, well, I can change the way root ids are generated.  Combining this
with Matt Fuller's email suggests we really need a new way of encoding
file ids, one that doesn't have percent signs or periods its output, and
distinguishes between capital and lowercase letters without using
capital letters.

> Further, I don't think there are Knit2 format repositories in real use
> (yet), so I think we can change it without breaking anything. But yes,
> that is a different thing. I was just discussing it. The doctest is fine
> as is.
> 
> ...
> 
>>>>> v- This seems pretty weird, what are you trying to do here?
>>> Avoid test failures from tests that assumed one blank tree was
>>> equivalent to another blank tree.
>>>
>>> I can't really say it better than the comment:
>>>             # If we happen to have a tree, we'll guarantee everything
>>>             # except for the tree root is the same.
> 
> ^- I'm not going to stick on this, but it does seem better to fix the
> tests, rather than have trees evaluate to equal when they aren't.
> 
> 
>>> Unfortunately, MemoryTree doesn't have a persistent inventory-- it's
>>> zapped on unlock.  So every time we locked, we'd get a different root
>>> id.  I don't understand why it's written this way.
> 
> Well, isn't that a problem with the inventory? Yes we get a new
> inventory each time, but IIRC it reads it from the branch.

In this case, it is reading the inventory of the empty tree, and that is
not a valid inventory for a WorkingTree.

> I think it
> was an attempt to move in the direction we want for WorkingTree's, where
> we don't load the inventory if we don't have to, and operations flush it
> to disk when unlocked

As far as I can tell, with a MemoryTree, there's no flushing going on.
It's just being thrown away.

> It looks fine to me. I think it is better than what we have, so I think
> it should be merged for 0.12. I'm a little concerned about the tree
> comparisons, but that is it.

Okay, in it goes.

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

iD8DBQFFMZpx0F+nu1YWqI0RAuriAJ9168xgalUTqFs2DqzoKDvwHkScswCfYm6j
m748ZozjzUrQ8lydEph2lcA=
=gIaq
-----END PGP SIGNATURE-----