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

[Robert Collins]

On Mon, 2009-03-23 at 09:33 -0400, Aaron Bentley wrote:

> > Ignoring small trees where nearly any approach will work, with big
> > trees..
> > first commit - generating the revision is 99% of the work.
> > incremental commit - reading and writing the dirstate is something like
> > 15-20% of the work, as of the last heavily tuned commit status.
> > Conceptually, to commit a single file in a 100 file tree, dirstate
> > should be about 90% of the time, but we're not there yet.
> 
> And even in that case, we would usually be able to tell that dirstate
> hadn't been modified using os.stat...
>
> > So the main problem isn't write integrity... thats easy: write the new
> > dirstate to a tempfile and move it over before we release the tree lock.
> 
> If we release the lock (i.e. both os lock and directory lock) before we
> update the parent trees, that's potentially problematic, because another
> client could *write* and we would then need to abort or do something clever.

Right now, running 'bzr st' will write to the dirstate, even though it
doesn't take a lockdir lock on the tree; its the stat cache update.

> > The problem is, and always has been reader integrity *and* reader
> > lock-outs.
> 
> Right.  I'm kinda surprised we're not doing atomic updates of the
> dirstate, but it surely wouldn't be hard to add.

I think its straight forward - write a new dirstate file,and use a
pointer to the file rather than assuming the name is 'dirstate'.

> > A reader on windows will prevent the commit completing until
> > it has closed the file. Partial parsing is written and implemented, even
> > though its not switched on; I don't think we need to discard that when
> > its very easy to write new files, and nothing needs to be keeping open a
> > pointer file.
> 
> I don't understand.

partial parsing - readers read the file incrementally as they need to,
and on windows keeping a file handle open locks the file implicitly.

-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/20090324/532dada6/attachment.pgp