[MERGE] Remove interdependency between WorkingTree and RevisionTree

John Arbash Meinel john at arbash-meinel.com
Mon Jul 17 14:04:01 BST 2006

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.

Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the bazaar mailing list