PATCH: cache basis inventory in .bzr

[Robert Collins]

On Sun, 2005-12-18 at 10:58 -0600, John A Meinel wrote:
> Robert Collins wrote:
...
> I realize I am opening up an old discussion, but I can't find the newer one.

I opened a bug report on it :)

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

Sounds good.

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

hmm. It *might* make sense for a remote branch to have a basis
inventory, though the costs of pulling down a full inventory vs a
knit/weave of one are not hugely different when compared to the cost of
reading one from the local dir.

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

There is a subtle difference though.
Branch has 'tip revision', WorkingTree has 'revision'. That is, a Branch
has a last_revision() method that makes sense- and we can choose to
either record the sequence as we do today, or just rev-id if-when the
revision-history file goes away. But WorkingTree does not have a 'last'
revision, it either has a revision it was updated to, or not. 

Putting it another way, if I want to be able to perform bzr status
without access to the Branch for a WorkingTree what do I need? I need
the revision-id of the basis revision, and the inventory for that basis
revision.

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

I think that if we want to have a basis-inventory for Branches, it
should be separate to the one for the WorkingTree. I say this because if
you consider the sequence for commit there is a clear gap where the
Branch is updated but the working tree(s) are not yet updated, and the
basis revision for those not yet updated working trees is different.

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

I hope I've convinced you above. I find it useful to consider this in
the case of :

Checkout (local), Branch (remote & slow), Repository (surrounds branch :
remote & slow).

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051219/eb912967/attachment.pgp