[PATCH STABLE RFC] transplant: avoid a dirstate race when transplanting multiple changesets
Patrick Mézard
pmezard at gmail.com
Wed Jan 26 16:57:07 UTC 2011
Le 26/01/11 15:18, Greg Ward a écrit :
> On Tue, Jan 25, 2011 at 5:48 PM, Matt Mackall <mpm at selenic.com> wrote:
>> On Tue, 2011-01-25 at 09:18 -0500, Greg Ward wrote:
>>> # HG changeset patch
>>> # User Greg Ward <greg-hg at gerg.ca>
>>> # Date 1295964871 18000
>>> # Branch stable
>>> # Node ID f501e673e1188511f3bd22959dd8ed693d458011
>>> # Parent d0e0d3d43e1439d63564ab4dddfe0daa69ae2d86
>>> transplant: avoid a dirstate race when transplanting multiple changesets
>>> (issue2264, issue2516)
>>
>> Queued for stable with title fixed to be robot-legible.
>
> Great, thanks! However, I may have thought of a better way to fix it.
> Here's my logic: the problem is that doing multiple commits in a row
> in the same process is prone to dirstate races. So don't fix the code
> that's doing the commits (transplant in this case) -- fix commit.
>
> Specifically, take the loop I added to transplant:
>
> + for fn in files:
> + repo.dirstate.normallookup(fn)
>
> and move it to localrepository.commitctx(), after the commit is done
> and the transaction closed. The penalty is pretty small, since
> normallookup() just modifies the in-memory dirstate.
I haven't looked at what you try to achieve here, but localrepo.commitctx() is probably not the right place since it does not deal at all with dirstate (or the working directory in general). Or it is really something related to transaction scope and in this case we could probably abstract this away with a callback. Can it be moved in localrepo.commit() instead? BTW, commit() already does something very similar to what you do.
--
Patrick Mézard
More information about the Mercurial-devel
mailing list