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

Aaron Bentley aaron at aaronbentley.com
Mon Mar 23 13:33:26 GMT 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
>> Do we even need the tree lock?  We certainly don't need to read from the
>> user files by that point, because the revision is almost entirely
>> committed.  We do need to write, however-- we need to update the tree
>> last-revision and the parent trees.  That means rewriting the dirstate.
>>  Would it be enough simply to detect changes to the dirstate file and
>> abort if substantive changes are made?  I imagine just reading the
>> dirstate file is cheap enough.
> 
> 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.

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

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

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknHj6IACgkQ0F+nu1YWqI34UwCeKWYsRQ4dmPScpal4Z+LAIwTd
X3kAn15sQ33bF+kL/R1JuATDdtr4Mf7u
=lwCM
-----END PGP SIGNATURE-----



More information about the bazaar mailing list