[MERGE] Tree.revision_tree

[John Arbash Meinel]

Robert Collins wrote:
> On Tue, 2006-09-12 at 09:07 -0400, Aaron Bentley wrote:
>> -----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?
> 
> 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.
> 
> John, Martin - could guys read this thread and throw in your 2c as tie
> breakers ?
> 
> -Rob

So the 2 proposed alternatives are to add 'Tree.revision_tree()' which
may raise an exception if it doesn't have the revision, versus making
WorkingTree register itself with its repository, and then having
Repository.revision_tree() query any registered cache functions to see
if they have a requested tree.

The advantage of the former, is that it is transparent to someone who
wants a tree, they just always say:

tree = wt.branch.repository.revision_tree(revision_id)
<do stuff with tree>

If there is a cached copy, it is returned, otherwise, it goes and
extracts it out of the repo.

Versus:

try:
    tree = wt.revision_tree(revision_id)
except ???NoSuchRevision???:
    tree = wt.branch.repository.revision_tree(revision_id)
<do stuff with tree>


The flip side is worrying about possible model violations. Where now we
are telling a Repo about a WorkingTree.

However, as long as we phrase it that we are telling the Repository that
there is a possible cache, and here is the function you can call to get
revisions... It seems pretty clean to me. It gives us a hook if we
really want a generic cache, one that could even be implemented as a plugin.

It also means we could start removing stuff like Tree.basis_tree(),
which only really exists because of a storage optimization.

I'm not sure I fully agree with Aaron's concept of a generic cache,
because we need to define an expiration policy. And the nice property
about basis for a working tree is that there is an implicit expiration
when the tree is modified (commit, pull, update).

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/20060928/6966bf03/attachment.pgp