[MERGE] Remove interdependency between WorkingTree and RevisionTree

[John Arbash Meinel]

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

Jelmer Vernooij wrote:
> On Mon, Jul 17, 2006 at 12:29:17PM +1000, Robert Collins wrote:
>> On Sat, 2006-07-15 at 17:27 +0200, Jelmer Vernooij wrote:
>>> Hi,
> 
>>> The attached bundle removes the dependency of WorkingTree on a
>>> particular RevisionTree implementation (the standard RevisionTree
>>> implementation is weave-specific). This change is required to allow
>>> standard WorkingTree's with non-weave Repositories.
>> -1 (no tests).
> Sorry, I guess I'm getting a bit sloppy.

I was wondering about that :)

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

> 
>> A related thing is making RevisionTree demand-load the inventory, which
>> we want for dirstate refactoring.
> Mind if I leave that for some other time? - I'd like to get these
> changes into 0.9.
> 
> Cheers,
> 
> Jelmer

I don't think he was requesting you to *do* the lazy load of inventory.
Just mentioning that we want to do it.

So, I would say that inventory should not be required, but that we do
need tests.

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

iD8DBQFEu4rAJdeBCYSNAAMRAjDqAJ0SxCfdPT/9JYwUQk9gjDjYu2+K/QCfbLeD
zDNv82kDTtCVjbrwaBFfP2A=
=ZU5E
-----END PGP SIGNATURE-----