Fri, 01 May 2015 20:43:55 +0900 templater: tokenize decimal integer literal (issue4638) (BC)
Yuya Nishihara <yuya@tcha.org> [Fri, 01 May 2015 20:43:55 +0900] rev 25002
templater: tokenize decimal integer literal (issue4638) (BC) Before this patch, we had to quote integer literals to pass to template functions. It was error-prone, so we should allow "word(0, x)" syntax. Currently only decimal integers are allowed. It's easy to support 0x, 0b and 0 prefixes, but I don't think they are useful. This patch assumes that template keywords and names defined in map files do not start with digits, except for positional variables seen in the schemes extension.
Sat, 02 May 2015 18:05:04 +0900 templater: switch methods table on compileexp() of func args and inner expr
Yuya Nishihara <yuya@tcha.org> [Sat, 02 May 2015 18:05:04 +0900] rev 25001
templater: switch methods table on compileexp() of func args and inner expr The next patch will introduce integer literals, but the schemes extension expects that '{1}', '{2}', ... are interpreted as keywords. This patch allows us to process '{foo(1)}' as 'func(integer)', whereas '{1}' as 'symbol'.
Sun, 10 May 2015 13:33:51 -0400 templatefilters: don't stringify None into "None"
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Sun, 10 May 2015 13:33:51 -0400] rev 25000
templatefilters: don't stringify None into "None" A few template keywords can in fact return None, such as {bisect}. In some contexts, these get stringified into None instead of "". This is leaking Python details into the UI.
Sun, 10 May 2015 19:02:14 +0800 hgweb: clearly outline <tr> block in gitweb and spartan styles
Anton Shestakov <engored@ya.ru> [Sun, 10 May 2015 19:02:14 +0800] rev 24999
hgweb: clearly outline <tr> block in gitweb and spartan styles It's easy to miss the closing </tr> tag when it's not on its own line. Some neighboring blocks also already use this clearer style. (In 03f692eee31d I didn't even think grepping for this, but this patch should now cover every occurrence).
Thu, 07 May 2015 12:07:11 +0900 rebase: use dirstateguard instead of dirstate.invalidate
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 07 May 2015 12:07:11 +0900] rev 24998
rebase: use dirstateguard instead of dirstate.invalidate Before this patch, "rebase.concludenode()" uses "dirstate.invalidate()" as a kind of "restore .hg/dirstate to the original status" during a failure. But it just discards changes in memory, and doesn't actually restore ".hg/dirstate". Then, it can't work as expected, if "dirstate.write()" is executed while processing. This patch uses "dirstateguard" instead of "dirstate.invalidate()" to restore ".hg/dirstate" during a failure even if "dirstate.write()" is executed before a failure. This patch also removes "beginparentchage()" and "endparentchange()", because "dirstateguard" makes them useless. This is a part of preparations to fix the issue that the recent (in memory) dirstate isn't visible to external processes (e.g. "precommit" hook). After this patch, the changed dirstate becomes visible to external "precommit" hooks during "hg rebase" in "test-largefiles-misc.t", because "dirstateguard()" writes it out. But this content isn't yet correct, because: - "normal3" should be marked as "A"(dded) at committing It is newly added in the changeset being rebased. - but it is marked as "M"(odified) The result of "repo.setparents()" after "dirstateguard()" isn't yet written out before "precommit". So, merging is still in progress for "hg status" in it. This causes marking the file newly added on "other" branch as "A". This will be fixed by subsequent patch.
Thu, 07 May 2015 12:07:11 +0900 mq: use dirstateguard instead of dirstate.invalidate (qrefresh)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 07 May 2015 12:07:11 +0900] rev 24997
mq: use dirstateguard instead of dirstate.invalidate (qrefresh) Before this patch, "mq.queue.refresh()" uses "dirstate.invalidate()" as a kind of "restore .hg/dirstate to the original status" during a failure. But it just discards changes in memory, and doesn't actually restore ".hg/dirstate". Then, it can't work as expected, if "dirstate.write()" is executed while processing. This patch uses "dirstateguard" instead of "dirstate.invalidate()" to restore ".hg/dirstate" during a failure even if "dirstate.write()" is executed before a failure. This patch also removes "beginparentchage()" and "endparentchange()", because "dirstateguard" makes them useless. This is a part of preparations to fix the issue that the recent (in memory) dirstate isn't visible to external processes (e.g. "precommit" hook).
Thu, 07 May 2015 12:07:11 +0900 mq: use dirstateguard instead of dirstate.invalidate (qpush)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 07 May 2015 12:07:11 +0900] rev 24996
mq: use dirstateguard instead of dirstate.invalidate (qpush) Before this patch, "mq.queue.apply()" uses "dirstate.invalidate()" as a kind of "restore .hg/dirstate to the original status" during afailure. But it just discards changes in memory, and doesn't actually restore ".hg/dirstate". Then, it can't work as expected, if "dirstate.write()" is executed while processing. This patch uses "dirstateguard" instead of "dirstate.invalidate()" to restore ".hg/dirstate" at failure even if "dirstate.write()" is executed before failure. This is a part of preparations to fix the issue that the recent (in memory) dirstate isn't visible to external processes (e.g. "precommit" hook).
Thu, 07 May 2015 12:07:11 +0900 tryimportone: use dirstateguard instead of beginparentchange/endparentchange
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 07 May 2015 12:07:11 +0900] rev 24995
tryimportone: use dirstateguard instead of beginparentchange/endparentchange To fix the issue that the recent (in memory) dirstate isn't visible to external process (e.g. "precommit" hook), a subsequent patch makes "localrepository.commit()" invoke "dirstate.write()" in it. This change will make "beginparentchange()" and "endparentchange()" on dirstate in "cmdutil.tryimportone()" meaningless, because: - "dirstate.write()" writes changed data into ".hg/dirstate", but - aborting between "beginparentchange()" and "endparentchange()" doesn't cause any restoring ".hg/dirstate" it just discards changes in memory. This patch uses "dirstateguard" instead of "beginparentchange()" and "endparentchange()" in "cmdutil.tryimportone()" to restore ".hg/dirstate" during a failure even if "dirstate.write()" is executed before a failure. This patch uses "lockmod.release(dsguard)" instead of "dsguard.release()", because processing may be aborted before assignment to "dsguard" , and the "if dsguard" examination for safety is redundant.
Thu, 07 May 2015 12:07:10 +0900 import: use dirstateguard instead of dirstate.invalidate
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 07 May 2015 12:07:10 +0900] rev 24994
import: use dirstateguard instead of dirstate.invalidate Before this patch, "commands.import()" uses "dirstate.invalidate()" as a kind of "restore .hg/dirstate to the original status" during a failure. But it just discards changes in memory, and doesn't actually restore ".hg/dirstate". Then, it can't work as expected, if "dirstate.write()" is executed while processing. This patch uses "dirstateguard" instead of "dirstate.invalidate()" to restore ".hg/dirstate" at failure even if "dirstate.write()" is executed before failure. This patch also removes "beginparentchage()" and "endparentchange()", because "dirstateguard" makes them useless, too. This is a part of preparations to fix the issue that the recent (in memory) dirstate isn't visible to external process (e.g. "precommit" hook).
Thu, 07 May 2015 12:07:10 +0900 amend: use dirstateguard instead of dirstate.invalidate
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 07 May 2015 12:07:10 +0900] rev 24993
amend: use dirstateguard instead of dirstate.invalidate Before this patch, "cmdutil.amend()" uses "dirstate.invalidate()" as a kind of "restore .hg/dirstate to the original status" during a failure. But it just discards changes in memory, and doesn't actually restore ".hg/dirstate". Then, it can't work as expected, if "dirstate.write()" is executed while processing. This patch uses "dirstateguard" instead of "dirstate.invalidate()" to restore ".hg/dirstate" at failure even if "dirstate.write()" is executed before failure. This is a part of preparations to fix the issue that the recent (in memory) dirstate isn't visible to external process (e.g. "precommit" hook).
Thu, 07 May 2015 12:07:10 +0900 localrepo: use changelog.hasnode instead of self.__contains__
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 07 May 2015 12:07:10 +0900] rev 24992
localrepo: use changelog.hasnode instead of self.__contains__ Before this patch, releasing the store lock implies the actions below, when the 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 the store lock: resources are acquired in "wlock => dirstateguard => store lock" order, and are released in reverse order. This may cause that "dirstate.p1()" still refers to the changeset to be rolled-back at (4) above: pushing multiple patches by "hg qpush" is a typical case. When releasing the store lock, such changesets are: - not contained in "repo.changelog", if it is reloaded from ".hg/00changelog.i", as that file was 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 failures. 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 the "unknown working parent" warning irregularly, this patch uses "changelog.hasnode()" instead of "node in self" to examine existence of committed changeset.
Thu, 07 May 2015 12:07:10 +0900 cmdutil: add class to restore dirstate during unexpected failure
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 07 May 2015 12:07:10 +0900] rev 24991
cmdutil: add class to restore dirstate during unexpected failure Before this patch, after "dirstate.write()" execution, there was no way to restore dirstate to the original status before "dirstate.write()". In some code paths, "dirstate.invalidate()" is used as a kind of "restore .hg/dirstate to the original status", but it just avoids writing changes in memory out, and doesn't actually restore the ".hg/dirstate" file. To fix the issue that the recent (in memory) dirstate isn't visible to external processes (e.g. "precommit" hooks), "dirstate.write()" should be invoked before invocation of external processes. But at the same time, ".hg/dirstate" should be restored to its content before "dirstate.write()" during an unexpected failure in some cases. This patch adds the class "dirstateguard" to easily restore ".hg/dirstate" during unexpected failures. Typical usecase of it is: # (1) build dirstate up .... # (2) write dirstate out, and backup ".hg/dirstate" dsguard = dirstateguard(repo, 'scopename') try: # (3) execute somethig to do: # this may imply making some additional changes on dirstate .... # (4) unlink backed-up dirstate file at the end of dsguard scope dsguard.close() finally: # (5) if execution is aborted before "dsguard.close()", # ".hg/dirstate" is restored from the backup dsguard.release() For this kind of issue, an "extending transaction" approach (in https://titanpad.com/mercurial32-sprint) seems to not be suitable, because: - transaction nesting occurs in some cases (e.g. "shelve => rebase"), and - "dirstate" may be already modified since the beginning of OUTER transaction scope, then - dirstate should be backed up into the file other than "dirstate.journal" at the beginning of INNER transaction scope, but - such alternative backup files are useless for transaction itself, and increases complication of its implementation "transaction" and "dirstateguard" differ from each other also in "what it should do for .hg/dirstate" in cases other than success. ============== ======= ======== ============= type success fail "hg rollback" ============== ======= ======== ============= transaction keep keep restore dirstateguard keep restore (not implied) ============== ======= ======== ============= Some collaboration between transaction and dirstate will probably be introduced in the future. But this layer is needed in all cases.
Sun, 10 May 2015 14:45:13 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Sun, 10 May 2015 14:45:13 -0500] rev 24990
merge with stable
Sat, 09 May 2015 16:06:04 -0500 wix: add new json templates folder to MSI installers
Steve Borho <steve@borho.org> [Sat, 09 May 2015 16:06:04 -0500] rev 24989
wix: add new json templates folder to MSI installers
Mon, 04 May 2015 10:03:13 +0900 templater: rename parsestring() to unquotestring() (API)
Yuya Nishihara <yuya@tcha.org> [Mon, 04 May 2015 10:03:13 +0900] rev 24988
templater: rename parsestring() to unquotestring() (API) Since db7463aa080f, it doesn't parse string escapes.
Mon, 04 May 2015 10:01:03 +0900 templater: remove noop calls of parsestring(s, quoted=False) (API)
Yuya Nishihara <yuya@tcha.org> [Mon, 04 May 2015 10:01:03 +0900] rev 24987
templater: remove noop calls of parsestring(s, quoted=False) (API) Since db7463aa080f, parsestring(s, quoted=False) just returns s.
(0) -10000 -3000 -1000 -300 -100 -16 +16 +100 +300 +1000 +3000 +10000 tip