Solving the commit-editor-locks-stuff-up problem.
Robert Collins
robert.collins at canonical.com
Fri Mar 20 23:28:33 GMT 2009
On Fri, 2009-03-20 at 17:05 -0400, Karl Fogel wrote:
> When 'bzr commit' brings up a commit message editor, bzr takes a
> dirstate-lock for the duration of the editing session, thus preventing
> other uses of the tree.
Actually, bzr takes a dirstate lock for the duration of a tree write
lock, and a tree write lock is one of our lockdir locks. So its nothing
specific to do with the editor.
> This is one symptom of http://bugs.launchpad.net/bzr/+bug/98836, but
> it's a particularly visible symptom that multiple users have noticed.
>
> In http://bugs.launchpad.net/bzr/+bug/98836/comments/6, I've outlined a
> solution that I think would be pretty easy to implement. Can we do
> something like this, and get this user-visible bug out of the way?
I think you need to know more about how commit in bzr works. I like that
you want to fix this bug and are proposing ways to do it.
What we do at the moment is:
acquire a tree write lock. This is abstract depending on the tree but
the requirements are:
- the tree bzr-data cannot be change while this is held, and other
bzr mutating operations are excluded;
- the branch is locked too [this excludes
pull/uncommit/push-into-this-branch]
- the repository is locked too [for some repositories this excludes all
writing, but only old repositories and repositories like bzr-hg.
bzr's pack repository format, and all the newer ones since are multi-
writer and do not get mutually excluded].
We create a inventory in the repository for the commit. All changed data
is written into the repository, and hooks that operate during this phase
execute. This is analogous to gits 'tree' object being created.
We callback to get a commit message. This is then used to create the
commit object, we unlock and are done,
Things to note:
- locking the branch early is an explicit choice to prevent starvation
of less well connected or slow clients.
- processing the tree more than once is expensive and something we've
put a lot of work into avoiding.
> Here's the proposal: When the user runs 'bzr commit', we
> lot of users, and could be fixed this other way. Let not the perfect be
> the enemy of the good, and all that.
>
> Thoughts?
Well, I'd rather not criticise your proposed solution, since you clearly
hadn't looked at how commit in bzr works. Rather I'd like to note that
the way I'd fix this is fix the root cause. Its less complex than
dealing with the race conditions and performance implications raised by
trying to reacquire a lock late in the piece, IMNSHO. IOW, the simplest
way forward here is to fix the root cause, not work around it - the good
and the perfect are in harmony.
-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090321/eaff8cf4/attachment.pgp
More information about the bazaar
mailing list