[MERGE] Tree.revision_tree

[John Arbash Meinel]

Aaron Bentley wrote:

> 
> That was what I meant, yes.  Maybe as a weakref, so that the cache
> doesn't get too greedy.

You mean in case the WorkingTree dies before the Repository?

> 
>>> I suppose it
>>> might be possible for this to be during the tree constructor.
> 
> Yes, this is where I was thinking of putting it.
> 
>>> 4) Dirstate (at least) is written in such a way as to make it cheaper to
>>> do revision_trees(), because each tree is nested side-by-side with the
>>> other ones. I do wonder if it wouldn't be better to have another file
>>> for each one. I know we wanted to do it this way for faster
>>> 'changes_from' performance, because you get the parent entry at the same
>>> time as the child entry....
> 
> Well, if revision_trees is the most efficient API, let's support that,
> by all means.  But instead of raising NoSuchRevision (as
> Repository.revision_trees does), we'd just return the revision_trees
> that could be found.  (Maybe list the missing ones, but that can also be
> calculated easily.)
> 
> The point, though, is that it wouldn't be Tree.revision_tree, it would
> be WorkingTree._revision_trees, which would be passed to the repository
> at registration time.
> 
> Aaron

It would seem reasonable enough for WorkingTree._revision_trees to
return a dict from revision_id => RevisionTree, and unavailable ones are
either not present, or None.

I probably would prefer this layering as well. Since it makes the
Repository the place you go to get revisions, which may have a small
hint about faster places to get the data.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060911/9dd34316/attachment.pgp