FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 25 May 2015 01:26:23 +0900] rev 25268
localrepo: pass hook argument txnid to pretxnopen hooks
Before this patch, hook argument `txnid` isn't passed to `pretxnopen`
hooks, even though `hooks` section of `hg help config` describes so.
``pretxnopen``
Run before any new repository transaction is open. The reason for the
transaction will be in ``$HG_TXNNAME`` and a unique identifier for the
transaction will be in ``HG_TXNID``. A non-zero status will prevent the
transaction from being opened.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 25 May 2015 01:26:19 +0900] rev 25267
transaction: separate calculating TXNID from creating transaction object
Before this patch, transaction ID (TXNID) is calculated from
`transaction` object itself by `id()`, but this prevents TXNID from
being passed to `pretxnopen` hooks, which should be executed before
starting transaction processing (also any preparations for it, like
writing journal files out).
As a preparation for passing TXNID to `pretxnopen` hooks, this patch
separates calculation of TXNID from creation of `transaction` object.
This patch uses "random" library for reasonable unique ID. "uuid"
library can't be used, because it was introduced since Python 2.5 and
isn't suitable for Mercurial 3.4.x stable line.
`%f` formatting for `random.random()` is used with explicit precision
number 40, because default precision for `%f` is 6. 40 should be long
enough, even if 10**9 transactions are executed in a short time (a
second or less).
On the other hand, `time.time()` is used to ensures uniqueness of
TXNID in a long time, for safety.
BTW, platform not providing `/dev/urandom` or so may cause failure of
`import random` itself with some Python versions (see Python
issue15340 for detail http://bugs.python.org/issue15340).
But this patch uses "random" without any workaround, because:
- "random" is already used directly in some code paths,
- such platforms are very rare (e.g. Tru64 and HPUX), and
http://bugs.python.org/issue15340#msg170000
- updating Python runtime can avoid this issue
Yuya Nishihara <yuya@tcha.org> [Sat, 23 May 2015 11:14:00 +0900] rev 25266
revbranchcache: return uncached branchinfo for nullrev (issue4683)
This fixes the crash caused by "branch(null)" revset. No cache should be
necessary for nullrev because changelog.branchinfo(nullrev) does not involve
IO operation.
Note that the problem of "branch(wdir())" isn't addressed by this patch.
"wdir()" will raise TypeError in many places because of None. This is the
reason why "wdir()" is still experimental.
Yuya Nishihara <yuya@tcha.org> [Sun, 24 May 2015 10:29:33 +0900] rev 25265
revset: drop magic of fullreposet membership test (issue4682)
This patch partially backs out d2de20e1451f and adds an alternative workaround
to functions that evaluate "null" and "wdir()". Because the new workaround is
incomplete, "first(null)" and "min(null)" don't work as expected. But they were
not usable until 3.4 and "null" isn't commonly used, we can postpone a complete
fix for 3.5.
The issue4682 was caused because "branch(default)" is evaluated to
"<filteredset <fullreposet>>", keeping fullreposet magic. The next patch will
fix crash on "branch(null)", but without this patch, it would make
"null in <branch(default)>" be True, which means "children(branch(default))"
would return all revisions but merge (p2 != null).
I believe the right fix is to stop propagating fullreposet magic on filter(),
but it wouldn't fit to stable release. Also, we should discuss how to handle
"null" and "wdir()" in revset before.
Matt Mackall <mpm@selenic.com> [Sat, 23 May 2015 15:55:04 -0500] rev 25264
merge with stable
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 22 May 2015 12:13:18 -0500] rev 25263
transaction: use the proper variable in '_addbackupentry' (issue4684)
The 'file' variable was undefined but resolved to the 'file' built-in.
This is why pylint complains about overwriting built-ins...