[PATCH 2 of 9 V3] localrepo: use changelog.hasnode instead of self.__contains__

Pierre-Yves David pierre-yves.david at ens-lyon.org
Mon May 11 20:42:46 CDT 2015



On 05/06/2015 08:15 PM, FUJIWARA Katsunori wrote:
> # HG changeset patch
> # User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> # Date 1430968030 -32400
> #      Thu May 07 12:07:10 2015 +0900
> # Node ID cbc75b379738476e9037b4f1adda5669963a42af
> # Parent  449a46109f0c96bb8d82d4edf2c8855341558c2f
> localrepo: use changelog.hasnode instead of self.__contains__
>
> Before this patch, releasing store lock implies actions below, when
> transaction is aborted:
>
>    1. "commithook()" scheduled in "localrepository.commit()" is invoked
>    2. "changectx.__init__()" is invoked via "self.__contains__()"
>    3. specified ID is examined against "repo.dirstate.p1()"
>    4. validation function is invoked in "dirstate.p1()"
>
> In subsequent patches, "dirstate.invalidate()" invocations for
> discarding changes are replaced with "dirstateguard", but discarding
> changes by "dirstateguard" is executed after releasing sotre lock:
> resouces are acquired in "wlock => dirstateguard => store lock" order,
> and are released in reversed order.
>
> This may cause that "dirstate.p1()" still refers the changeset to be
> rollback-ed at (4) above: pushing multiple patches by "hg qpush" is
> typical case.
>
> At releasing store lock, such changesets are:
>
>    - not contained in "repo.changelog", if it is reloaded from
>      ".hg/00changelog.i" already truncated by "transaction.abort()"
>
>    - still contained in it, otherwise
>      (this "dirty read" problem is discussed in "Transaction Plan"
>       http://mercurial.selenic.com/wiki/TransactionPlan)
>
> Validation function shows "unknown working parent" warning in the
> former case, but reloading "repo.changelog" depends on the timestamp
> of ".hg/00changelog.i". This causes occasional test failure.

btw, this timestamp business sounds like a bug. Do we have an issue and 
repro for it?

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list