Mon, 18 Nov 2013 08:57:19 -0800 strip: hold wlock for entire duration stable
Siddharth Agarwal <sid0@fb.com> [Mon, 18 Nov 2013 08:57:19 -0800] rev 20096
strip: hold wlock for entire duration Previously, we'd acquire and release the wlock several times. This meant that other hg processes could come in and change state. Instead of that, retain the wlock for the entire duration of the strip.
Fri, 22 Nov 2013 17:26:58 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 22 Nov 2013 17:26:58 -0600] rev 20095
merge with stable
Sun, 10 Nov 2013 18:51:21 +0100 bisect: report "both good and bad" as such, not as "not directly related" stable
Mads Kiilerich <madski@unity3d.com> [Sun, 10 Nov 2013 18:51:21 +0100] rev 20094
bisect: report "both good and bad" as such, not as "not directly related"
Fri, 08 Nov 2013 11:49:13 +0100 phase: better error message when --force is needed stable
Martin Geisler <martin@geisler.net> [Fri, 08 Nov 2013 11:49:13 +0100] rev 20093
phase: better error message when --force is needed When trying to turn a draft changeset into a secret changeset, I was told: % hg phase -s . cannot move 1 changesets to a more permissive phase, use --force no phases changed That message struck me as being backwards -- the secret phase feels less permissive to me since it restricts the changesets from being pushed. We don't use the word "permissive" elsewhere, 'hg help phase' talks about "lower phases" and "higher phases". I therefore reformulated the error message to be cannot move 1 changesets to a higher phase, use --force That is not perfect either, but more in line with the help text. An alternative could be cannot move phase backwards for 1 changesets, use --force which fits better with the help text for --force.
Fri, 08 Nov 2013 09:48:01 +0100 hgweb: ignore non numeric "revcount" parameter values (issue4091) stable
Isaac Jurado <diptongo@gmail.com> [Fri, 08 Nov 2013 09:48:01 +0100] rev 20092
hgweb: ignore non numeric "revcount" parameter values (issue4091)
Tue, 12 Nov 2013 16:23:52 +0900 lock: take both vfs and lock file path relative to vfs to access via vfs
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 12 Nov 2013 16:23:52 +0900] rev 20091
lock: take both vfs and lock file path relative to vfs to access via vfs This patch makes "lock.lock.__init__()" take both vfs and lock file path relative to vfs, instead of absolute path to lock file. This allows lock file to be accessed via vfs.
Tue, 12 Nov 2013 16:23:52 +0900 vfs: add "makelock()" and "readlock()"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 12 Nov 2013 16:23:52 +0900] rev 20090
vfs: add "makelock()" and "readlock()"
Tue, 12 Nov 2013 16:23:52 +0900 hg: rewrite "copystore()" with vfs
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 12 Nov 2013 16:23:52 +0900] rev 20089
hg: rewrite "copystore()" with vfs This patch rewrites "copystore()" with vfs, because succeeding patch requires "lock.lock()" invocation with vfs. This patch uses 'dstbase + "/lock"' instead of "join()" with both elements even on Windows environment but it should be reasonable, because target files given from "store.copyfiles()" already uses "/" as path separator. "util.copyfiles()" between two vfs-s may have to be rewritten in the future.
Tue, 12 Nov 2013 16:23:52 +0900 localrepo: import "lock" module as "lockmod" for readability
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 12 Nov 2013 16:23:52 +0900] rev 20088
localrepo: import "lock" module as "lockmod" for readability Before this patch, "localrepo.py" has many methods defining local variable "lock", even though it imports "lock" module as "lock". This ambiguity decreases readability.
Tue, 12 Nov 2013 16:23:52 +0900 transaction: take journal file path relative to vfs to use file API via vfs
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 12 Nov 2013 16:23:52 +0900] rev 20087
transaction: take journal file path relative to vfs to use file API via vfs
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip