RFC: dirstate & locks

John Arbash Meinel john at arbash-meinel.com
Thu Aug 14 21:51:07 BST 2008

Hash: SHA1

Robert Collins wrote:
> On Wed, 2008-08-06 at 08:02 -0500, John Arbash Meinel wrote:
>> My personal preference (in the short term) is to just get rid of the
>> OS
>> lock, and go back to rename-into-place for dirstate.  On windows 'bzr
>> status' with changes will fail to update the file when some other
>> action
>> is reading the file (but we already have that, and worse).
> This has several race conditions such as
> bzr commit -m foo &
> bzr st
> -> overwriting your last commit
> and commit can be made to error too by rename-into-place being racy on
> windows (can't delete open files, commit will have the file open, or
> status will be renaming etc).
> I think what I proposed has no problems for windows or linux of this
> nature, only a 'when do we delete things' problem, and thats solvable
> using one of a number of heuristics if the basic thing sounds ok.
> -Rob

I would just have "bzr status" take out a real write lock (since that is
basically what it is half-doing now) and check that the file isn't
modified before it writes its data out.

We avoid the race condition, and the need for an OS lock. If the write
lock fails right away, we just abort writing the new values, which is
what we do now.


Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the bazaar mailing list