dirstate2 comments
John Arbash Meinel
john at arbash-meinel.com
Thu May 20 03:23:38 BST 2010
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert recently wanted to look at his dirstate2 branch, and wanted to
get some feedback on it. I've looked at it, but I won't say I've been
fully thorough.
1) Currently incomplete. Just reading what the docs mention, versus what
the code does. However, the docs seem to outline something that would work.
2) Initial thoughts is that it seems overly complicated. *Especially* on
platforms with atomic rename. Which also brings up the question of how
to make sure it is adequately tested on platforms where you can rename
open files. Maybe you've already solved this, or maybe it's why this
isn't fully complete yet.
3) Depending on renaming files in/out of the way to get correct behavior
seems like it could be extra problematic on NFS. Then again, things may
not be worse than where we already are.
4) I was a bit confused by the naming scheme ($MD5.check is the pointer
to the last file, while $MD5 is the new content, and $MD5.current is the
pointer to $MD5.) I don't have anything immediate, but giving an
extension to the new content, and possibly name the pointers as '.ptr'
or something, might make it a bit clearer what is what.
5) Adding a new directory under '.bzr/checkout' to hold this stuff seems
superfluous, especially since it seems to have yet-another format file.
Maybe I misunderstood, but it would be nice to just use .bzr/checkout.
6) If we are revisiting how dirstate works, what about splitting out the
stat file again. It seems that file is what gives us the most difficulty
(since it can be updated in a read lock). If we made it more clearly
separate, we might avoid some of the problems entirely. IIRC the main
desire to not have it was performance, but I wonder the real cost would
be if we structured it appropriately. Having to repeat all the paths
again would be bad, but maybe we can do better. IIRC we also do
something indexed on stat rather than by path, maybe that would be
useful here...
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkv0nSoACgkQJdeBCYSNAANaDgCdEd/sbkds0MV9lHBoDtvTXY8R
TrUAn1eYeXf3dzCwTrk6PjVQ1RDyChFD
=nTI0
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list