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

login
register
mail settings
Submitter Katsunori FUJIWARA
Date May 7, 2015, 3:15 a.m.
Message ID <cbc75b379738476e9037.1430968549@feefifofum>
Download mbox | patch
Permalink /patch/8935/
State Accepted
Delegated to: Pierre-Yves David
Headers show

Comments

Katsunori FUJIWARA - May 7, 2015, 3:15 a.m.
# HG changeset patch
# User FUJIWARA Katsunori <foozy@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.

In the case of scheduled "commithook()", it just wants to examine
whether "node ID" of committed changeset is still valid or not. Other
examinations implied in "changectx.__init__()" are meaningless.

To avoid showing "unknown working parent" warning irregularly, this
patch uses "changelog.hasnode()" instead of "node in self" to examine
existence of committed changeset.
Pierre-Yves David - May 12, 2015, 1:42 a.m.
On 05/06/2015 08:15 PM, FUJIWARA Katsunori wrote:
> # HG changeset patch
> # User FUJIWARA Katsunori <foozy@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?
Katsunori FUJIWARA - May 12, 2015, 3:55 p.m.
At Mon, 11 May 2015 18:42:46 -0700,
Pierre-Yves David wrote:
> 
> On 05/06/2015 08:15 PM, FUJIWARA Katsunori wrote:
> > # HG changeset patch
> > # User FUJIWARA Katsunori <foozy@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?

Re-loading from changed (in "timestamp second" view) file itself seems
expected behavior and to work correctly.

Would you mean that there may be code paths which potentially cause
similar problem when transaction crossing the border of timestamp
second is aborted ?


----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy@lares.dti.ne.jp

Patch

diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py
--- a/mercurial/localrepo.py
+++ b/mercurial/localrepo.py
@@ -1517,7 +1517,7 @@ 
         def commithook(node=hex(ret), parent1=hookp1, parent2=hookp2):
             # hack for command that use a temporary commit (eg: histedit)
             # temporary commit got stripped before hook release
-            if node in self:
+            if self.changelog.hasnode(ret):
                 self.hook("commit", node=node, parent1=parent1,
                           parent2=parent2)
         self._afterlock(commithook)
diff --git a/tests/test-mq-qpush-fail.t b/tests/test-mq-qpush-fail.t
--- a/tests/test-mq-qpush-fail.t
+++ b/tests/test-mq-qpush-fail.t
@@ -34,7 +34,23 @@ 
   $ $PYTHON -c 'print "\xe9"' > message
   $ cat .hg/patches/bad-patch >> message
   $ mv message .hg/patches/bad-patch
-  $ hg qpush -a && echo 'qpush succeeded?!'
+  $ cat > $TESTTMP/wrapplayback.py <<EOF
+  > import os
+  > from mercurial import extensions, transaction
+  > def wrapplayback(orig,
+  >                  journal, report, opener, vfsmap, entries, backupentries,
+  >                  unlink=True):
+  >     orig(journal, report, opener, vfsmap, entries, backupentries, unlink)
+  >     # Touching files truncated at "transaction.abort" causes
+  >     # forcible re-loading invalidated filecache properties
+  >     # (including repo.changelog)
+  >     for f, o, _ignore in entries:
+  >         if o or not unlink:
+  >             os.utime(opener.join(f), (0.0, 0.0))
+  > def extsetup(ui):
+  >     extensions.wrapfunction(transaction, '_playback', wrapplayback)
+  > EOF
+  $ hg qpush -a --config extensions.wrapplayback=$TESTTMP/wrapplayback.py  && echo 'qpush succeeded?!'
   applying patch1
   applying patch2
   applying bad-patch