PATCH: cache basis inventory in .bzr

[John A Meinel]

Robert Collins wrote:
> On Thu, 2005-11-24 at 21:09 +0100, Johan Rydberg wrote:
>>> The attached patch caches the contents of the basis (last revision)
>>> inventory in a control file in .bzr.  This make it possible to get a
>>> copy of the basis tree without reading the inventory weave.  This
>> will
>>> (hopefully) speed up operations such as "bzr status", esp if someone
>>> gets a few minutes over to fix the hashcache which seems to be
>> broken
>>> right now (it never gets written out.)
>> Here's an updated version.
> 
>> === modified file 'bzrlib/branch.py'
>> --- bzrlib/branch.py    
>> +++ bzrlib/branch.py     
> 
> ...
> 
> 
> Couple of things: the code for this should be in WorkingTree, not
> Branch. (Its a property of the WorkingTree that it is at revision X, and
> thus that the cached inventory has value FOO.)
> 
> Secondly, there are other operations than commit that change the
> last_revision property of a working tree:
> pull
> push (with rsync)
> potentially undo/redo
> and currently anything that calls branch.set_revision_history (*)
> 
> So, I think that having a method on WorkingTree 'set_last_revision',
> which takes care of this, would be a good idea. The data does not need
> to be cached in the object, just blatted to disk. This allows the
> branch.set_revision_history method to call
> self.working_tree().set_last_revision(history[-1]) for now... and we
> should ensure that all the current code that expects to change the
> working tree does so via the tree, which will remove that temporary
> wart.
> 
> Cheers,
> Rob

I realize I am opening up an old discussion, but I can't find the newer one.

I was working on changing Inventories so that they record their revision
id. I think this is useful for consistency checking, and at the very
least, the basis-inventory should be cached in this form.
That way we can get rid of "basis-inventory.<revision_id>" which I agree
looks ugly, and has problems with rsync, (because it is a new file,
rather than just updating the old one).

However, I don't agree that the cached inventory is a WorkingTree
property. A cache of the last inventory is a property of a branch.
Because the last time you committed to a branch, it created a revision,
which you are then caching. It makes perfect sense to me to have a
remote branch, which has no working tree, still have a basis inventory.

The current/last revision is a property of *both* the working tree and a
branch. Right now because we have everything pushed together, we don't
record both separately. Ultimately, I think we'll need 2 records.
Especially considering checkouts, where there is no branch, and they can
very easily get out of sync.

Another way of thinking is what happens when you push to a branch and
can't update the working tree (because there isn't one).
I think the basis-inventory should point to the newly pushed revision.

Also, there were no tests for the basis-inventory behavior. I added some
minor ones into my integration branch, and then branched off of it to
create:
http://bzr.arbash-meinel.com/branches/bzr/inventory-w-revision-id

Where I moved basis_inventory into Branch, and updated Inventory to take
a revision_id.

Certainly some of this could be moved around if you convince me that it
does need to be a WorkingTree property.
And because of the controversy of it, I went ahead and did it in a
separate branch, rather than in integration.

John
=:->

PS> I thought it was Robert who complained about 1M basis-inventories
needing to be copied around by rsync. But I can't find the email. Do I
have the wrong person?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051218/70c87ae1/attachment.pgp