[MERGE] Tree.revision_tree

[John Arbash Meinel]

Aaron Bentley wrote:
> Robert Collins wrote:

...

> No, I don't think we actually do agree here.  Because I'm thinking about
> this in terms of responsibilities, and you're thinking about it in terms
> of data layout.
> 
> I think the responsibility for providing revision_trees should lie with
> Repository.  That matches all our existing code's expectations.  What's
> the expected usage of this api?  It seems like it would be this:
> 
> try:
>     base_tree = tree.revision_tree(base_revision_id)
> except NoSuchRevision:
>     base_tree = branch.repository.revision_tree(base_revision_id)
> 
> Is there any case in which we would do something else?  If not, I think
> we should try to fix the API so that we don't have to repeat chunks like
> this everywhere.
> 
> 

...

> 
> My suggestion is to register working trees with their repositories, so
> that repository.revision_tree() will use a cached inventory if one is
> available in any live working tree that uses the repository.
> 
> A solution like this automatically upgrades all our code.  It also gets
> away from special-casing basis_tree.
> 
> What do you think?
> 
> Aaron


There are a few issues, which I think we need to work out:

1) WorkingTree will most likely be storing it in a different format. So
at the least, it can only register what revision ids it knows about, and
expect to be called at the appropriate time.

2) dirstate can be queried reasonably cheaply to see what revision ids
are cached. (You have to read a certain number of lines, but that is
fairly fixed).
However, we have to figure out when it should be registering itself with
the repository, and whether it registers just that it is a cache, or
that it has an explicit set of revision ids.

3) Roberts work is fairly interesting, in that with the cached
inventories locally, a lightweight checkout doesn't have to hit the
server for much of anything. Especially since he made 'lock_tree_write',
very few commands have to actually hit the repository.
Anyway, because of lightweight checkouts, it isn't like we can write a
control file into the repository to tell it where the cache is held. So
we have to have some sort of runtime registration going on. I suppose it
might be possible for this to be during the tree constructor.

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....

Anyway, there are layering and design issues that we need to think through.
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/ce0de52e/attachment.pgp