[MERGE] Tree.revision_tree

[Aaron Bentley]

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

Robert Collins wrote:
> On Tue, 2006-09-12 at 09:07 -0400, Aaron Bentley wrote:

>>>I dont really like the depth of handshaking we're getting into here:
>>>every call to repository.revision_trees() is going to have to ask an
>>>arbitrary number of trees for their *current* set of cached tree data.
>>
>>I don't think that's a good characterization.  I'm proposing registering
>>WorkingTrees with their repositories at object instantiation time.  We
>>rarely have more than two working trees active, and often just one.
>>
>>And in the case where the data *is* cached, it's a pretty good tradeoff, no?
> 
> 
> I've left this for a couple of weeks to think about, but it still
> doesn't make sense to me. We're saying that Repository will deliver data
> from a WorkingTree rather than having the WorkingTree deliver the data
> it can.

- From my POV, having a revision_tree method on Tree doesn't make sense.
Why would a tree have a tree in it?  It's not something that fits our model.

The proposed API is also painful to use, because after checking all
relevent trees, you must manually fall back to a repository.  (You do
need the tree, or else you wouldn't have asked for it, right?).

WorkingTree.basis() can be treated as a shortcut for
WorkingTree.branch.repository.revision_tree(WorkingTree.last_revision()).
 So that doesn't feel like a model violation.

Using the WorkingTree to store a cache is a bit of a hack.  Applying
that to all Trees makes it worse.  I would rather have a real cache, to
be honest.

Failing that, I would prefer to *use* active WorkingTrees as cache.

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

iD8DBQFFG+xY0F+nu1YWqI0RAiwUAJ9hbPFyi8ehJbflto6jw95RuJ3JigCfUnWt
ETix3kA2+KEMowpYx5kXOS4=
=0wPX
-----END PGP SIGNATURE-----