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