[MERGE] Tree.revision_tree

[Aaron Bentley]

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

Robert Collins 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?

> At this point, given there are no callers doing the try:
> aTree.revision_tree(); except: myrepository.revision_tree() dance, I am
> very unsure its needed.

Since aTree can't guarantee that it has a cached representation of any
trees, I don't see how it can be avoided.

> Also, consider what to do when we have two repositories open, and a
> working tree from one is registered with the other (so that its cached
> inventory is accessible)

I wouldn't do that.  The idea is to promote fast access to what the repo
already has, not to change what the repo has.

>, but its content access should come from which repository ? Meep.

If we did that, I think it's pretty obvious that the content access
would come from the WorkingTree's repo, the way it does with a basis_tree.

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

iD8DBQFFBrEp0F+nu1YWqI0RAgHNAJ91sEseG+EnOZfVupSZ2lwPVipbZwCeOhuw
4K0JoTeTR7cOYYNel6gkUu8=
=mBwd
-----END PGP SIGNATURE-----