[MERGE] Tree.revision_tree

Aaron Bentley aaron.bentley at utoronto.ca
Sun Sep 10 23:28:38 BST 2006


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

Robert Collins wrote:
> On Fri, 2006-09-08 at 09:22 -0500, John Arbash Meinel wrote:
>> Robert Collins wrote:
>>> Hi,
>>> * Add a new method ``Tree.revision_tree`` which allows access to cached
>>>   trees for arbitrary revisions. This allows the in development dirstate
>>>   tree format to provide access to the callers to cached copies of 
>>>   inventory data which are cheaper to access than inventories from the
>>>   repository.
>>>   (Robert Collins, Martin Pool)

I'm not very comfortable with this proposed interface.  It takes a
special case and tries to make it look general, when it's really not.
Providing the basis tree is supposed to be just an optimization.

Providing a call that looks like the Repository call, but only works for
the basis tree is confusing.  I wasn't especially happy with having
WorkingTree.basis_tree(), but this just compounds it.

I don't think that the working tree is the right place to be storing a
cache.  I would much rather make the Repository be aware of caches, and
use them where possible.

Why not have working trees register themselves with Repositories?  That
would allow us to use Repository.revision_tree(), but get cached
inventories if available.

Now that we've got a clean separation between repositories, branches,
and trees, I think we should be hesitant to go and blur those boundaries
again.

>> In my mental model, a tree is a snapshot of a specific revision. It
>> doesn't have other revisions present in its tree.

Fully agreed.

>> It seems like if you are going to add this at the Tree level, then it
>> should be implemented in RevisionTree(), as calling
>> self._repository.revision_tree()
> 
> No, because the client is asking the tree on the basis of 'locally
> present' and a RevisionTree's content may not be locally present. I had
> hoped the docstring on Tree.revision_tree() would make that clear - can
> you think of ways to improve that?

Part of the problem is the term "locally present".  My default
interpretation is that everything on my hard disk is "locally present".

And since only part of a tree is ever local to the WorkingTree (the
inventory), it's hard to say that the basis tree is "locally present",
either.

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

iD8DBQFFBJGW0F+nu1YWqI0RAg3cAKCA7Utal79urm9dQbWovApCQNJDNgCeOlRR
QeWXpNu6XD4tZmPC4cP+Pfc=
=gTjL
-----END PGP SIGNATURE-----




More information about the bazaar mailing list