Solving the commit-editor-locks-stuff-up problem.

[Robert Collins]

On Thu, 2009-03-26 at 07:36 +1100, Martin Pool wrote:
> 
> This does totally rule out doing incremental writes: all updates to
> the dirstate will do O(n_files*n_trees) work.  If you do 'bzr st
> README' and that file has changed and it causes it to rewrite the
> whole file it's potentially a lot slower.

With CHK we can drop the details of tree > 2 from dirstate with no
performance downgrade - its no longer used.

> However, it looks like there's no getting away from this if you want
> incremental reading and if you don't want to split it up into multiple
> files or some kind of journal structure.  So it's probably worth at
> least trying it, and maybe turning off dirstate updates from inside
> logical read operations, at least small ones.

A journal structure would look pretty similar, except we'd need some
more sophistication; we have to write new code to do partial updates
anyway, so we can wait for this.

As for turning off updates, I think a heuristic on the number of hash
results found is a good way to go.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090327/c8d57583/attachment.pgp