[MERGE] Remove interdependency between WorkingTree and RevisionTree

[John Arbash Meinel]

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

Robert Collins wrote:
> On Mon, 2006-07-17 at 08:04 -0500, John Arbash Meinel wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
> 
>>>> Separately, I suggest that rather than just using the inventory *IF*
>>>> supplied, you also emit a deprecation warning, so that supplying the
>>>> inventory is the expected behaviour, and we can move to having no if
>>>> block there eventually.
>>> Ok, makes sense.
>> I don't think I agree that supplying the inventory is expected.
>> *Most* of the time when you are getting a RevisionTree, you are
>> expecting the repository to have all the information. (The inventory,
>> the revision information, etc).
>> It so happens that we allow caching 1 inventory inside the working tree,
>> because it is referred to often, and extracting it from Weaves was very
>> slow. I don't know if we've benchmarked the speed for knits. But it
>> doesn't really matter as much... The next format is going to have it on
>> disk as well.
>>
>> Anyway, long ramble to say that this is the only case where you know the
>> inventory *before* you have the RevisionTree. And only because the
>> working tree is caching it.
> 
> I dont think conflating the interface of RevisionTree with how clients
> create one is useful.

I'm not sure where you are saying we are changing the RevisionTree
interface. I'm talking about the Repository.revision_tree() function.

> 
> Most (all?) RevisionTree instances are created from Repository instances
> via .revision_tree(revid). Or the new streaming one Aaron created. And
> that means that only one place has the questionable burden of creating
> an Inventory to give to the RevisionTree. I dont see any reason to make
> it optional, except perhaps because of demand loading plans - which I
> have not got a firm handle on yet - I'm just working on the .compare
> method at the moment.
> 
> Rob

So are you saying that there should be no ability to pass an inventory
to Repository.revision_tree?
I guess I'm unclear what you mean by 'no reason to make it optional'.
Are you saying it should be required, or that it shouldn't be allowed.

WorkingTree may have an out-of-date inventory, in which case it should
throw it away, and ask the Repository for a new one.

The old code created a RevisionTree directly, but to do a lightweight
bzr checkout of an svn repo, Jelmer needs to create an SVNRevisionTree,
rather than a bzr RevisionTree, because it is attached to the
repository, re-using Repository.revision_tree seemed a better way to
factor it, rather than having WorkingTree explicitly depend on RevisionTree.

I suppose we could expose 'Repository.tree_class' or something like that.

Or we could remove the ability for WorkingTree to cache its basis, but
we are planning on integrating that even more with the dirstate stuff....

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEu5sjJdeBCYSNAAMRAirwAJ9hnwuW1CvscsGjY4P1rP8O7U34ugCg1DTN
YGVdvmMKFn2rh7jmn5ejQII=
=trPn
-----END PGP SIGNATURE-----