RFC: dirstate & locks

Martin Pool mbp at canonical.com
Wed Aug 6 07:03:54 BST 2008


On Wed, Aug 6, 2008 at 3:47 PM, Robert Collins
<robertc at robertcollins.net> wrote:
> So I have a proposal for loosening dirstates need for locks...
>
> turn dirstate in a pointer + contents file in a subdir. The extra IO to
> read the pointer and read the state file from a subdir will be lost in
> system noise.
>
> status updates that want to fill out sha1sums would:
> write a new state file
> exclusively os lock the pointer file
> check the pointer is unchanged from when status started
> update the pointer
> unlock
>
> mutating operations that take a normal wt lock out would:
> write a new state file
> exclusively lock the pointer file
> update the pointer
> unlock

So without tracing all the way through this: getting rid of the need
for an OS lock would be pretty high on my list; it is arguably the
root cause of half a dozen bugs.   (Arguable because there may be
other ways to fix them.)  In this scheme it seems like a regular
lockdir would be enough.

-- 
Martin <http://launchpad.net/~mbp/>



More information about the bazaar mailing list