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.
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.
Matt Mackall <mpm@selenic.com> [Sun, 10 May 2015 14:45:13 -0500] rev 24990
merge with stable
Steve Borho <steve@borho.org> [Sat, 09 May 2015 16:06:04 -0500] rev 24989
wix: add new json templates folder to MSI installers
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.
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.
Ryan McElroy <rmcelroy@fb.com> [Tue, 14 Apr 2015 12:45:15 -0700] rev 24986
bookmarks: simplify iscurrent to isactivewdirparent (API)
Previously this function accepted two optional parameters that were unused by
any callers and complicated the function.
Today, the terms 'active' and 'current' are interchangeably used throughout the
codebase in reference to the active bookmark (the bookmark that will be updated
with the next commit). This leads to confusion among developers and users.
This patch is part of a series to standardize the usage to 'active' throughout
the mercurial codebase and user interface.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Tue, 05 May 2015 14:45:09 -0400] rev 24985
tests: add a new commit to test-commandline-template
This commit modifies, adds, renames, removes files all at once. It
will be mostly interesting for an upcoming test relating to the status
log template.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 07 May 2015 23:25:13 -0700] rev 24984
run-tests: spread and document the content of time tuple
The spreading will make future modification clearer. The documentation improve
code readability.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 07 May 2015 23:16:57 -0700] rev 24983
run-tests: when building json, get time data in the same order as elsewhere
The json code was changing the order of the time tuple for unclear reasons. We
now use the same order as everywhere else.