PATCH: cache basis inventory in .bzr

[Robert Collins]

On Fri, 2005-11-25 at 07:21 +0100, Johan Rydberg wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robert Collins <robertc at robertcollins.net> writes:
> > 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... 
> 
> The reason I went with a more fine grained approach was to try to
> eliminate the need to read the inventory from the weave right after it
> has been written.  The normal procedure for adding a revision is:
> 
>    - record revision
>    - record inventory*
>    - update history via branch.append_revision

This is buggy;) - it must be
 - record texts
 - record inventory
 - record revision
 - update history via branch.append_revision

> * The new basis inventory is known and in memory
> 
> But being more fine grained might introduce some security risks.  What
> if append_revision fails for some reason, but the new basis inventory
> has already been written to disk?  With the current implementation of
> append_revision this can probably not happen, though.

So with separate working trees we want:
 - record texts
 - record inventory
 - record revision
 - unlink the old basis inventory cache (*)
 - update revision history via branch.append_revision. (Now
working_tree.update can cope if we are interrupted)
 - record the new revision we are at in the working tree (currently
there is no explicit code to do that, its inherited via the tip value of
revision_history)
 - write the new basis inventory cache to disk.

(*) This step can be eliminated if we teach the basis inventory to
identify itself, so that the presence of an incorrect basis can be
detected. I.e. <inventory format=5 revision_id="klasdjlasjdlkajsd">.
Once we have explicit markers for the working tree revision, we can also
just move the unlink to after the 'update revision history via...'

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/20051128/f598a2a6/attachment.pgp