Fri, 19 Jul 2013 00:20:53 -0500 merge default into stable for 2.7 code freeze stable
Matt Mackall <mpm@selenic.com> [Fri, 19 Jul 2013 00:20:53 -0500] rev 19466
merge default into stable for 2.7 code freeze
Fri, 12 Jul 2013 11:14:42 +0900 osutil: consider WindowsError's behaviour to support python 2.4 on Windows
Shun-ichi GOTO <shunichi.goto@gmail.com> [Fri, 12 Jul 2013 11:14:42 +0900] rev 19465
osutil: consider WindowsError's behaviour to support python 2.4 on Windows This change treat the ESRCH error as ENOENT like WindowsError class does in python 2.5 or later. Without this change, some try..execpt code which expects errno is ENOENT may fail. Actually hg command does not work with python 2.4 on Windows. CreateFile() will fail with error code ESRCH when parent directory of specified path is not exist, or ENOENT when parent directory exist but file is not exist. Two errors are same in the mean of "file is not exist". So WindowsError class treats error code ESRCH as ENOENT in python 2.5 or later, but python 2.4 does not. Actual results with python 2.4: >>> errno.ENOENT 2 >>> errno.ESRCH 3 >>> WindowsError(3, 'msg').errno 3 >>> WindowsError(3, 'msg').args (3, 'msg') And with python 2.5 (or later): >>> errno.ENOENT 2 >>> errno.ESRCH 3 >>> WindowsError(3, 'msg').errno 2 >>> WindowsError(3, 'msg').args (3, 'msg') Note that there is no need to fix osutil.c because it never be used with python 2.4.
Wed, 17 Jul 2013 10:40:40 -0400 churn: split email aliases from the right
Matthew Turk <matthewturk@gmail.com> [Wed, 17 Jul 2013 10:40:40 -0400] rev 19464
churn: split email aliases from the right This splits churn email aliases from the right, to enable incorrectly-specified addresses that include equal signs to be mapped to correct addresses. This will enable aliasing of bad addresses (typically typos) such as: sername=myusername that appear in the churn output through a churn alias such as: sername=myusername = myusername whereas previously splitting from the left would not enable this behavior.
Sun, 14 Jul 2013 05:35:04 +0400 hgweb: highlight line which is linked to at annotate view
Alexander Plavin <me@aplavin.ru> [Sun, 14 Jul 2013 05:35:04 +0400] rev 19463
hgweb: highlight line which is linked to at annotate view
Sat, 13 Jul 2013 02:36:29 +0400 hgweb: always start log with searched revision
Alexander Plavin <me@aplavin.ru> [Sat, 13 Jul 2013 02:36:29 +0400] rev 19462
hgweb: always start log with searched revision This makes the specified revision be always on top of the list. Before the patch, for example with repo having revisions 0, 1, 2, 3 and user searching for '2', all revisions were shown and the specified one wasn't the first.
Mon, 01 Jul 2013 06:50:58 +0200 util: check if re2 works before using it (issue 3964)
Simon Heimberg <simohe@besonet.ch> [Mon, 01 Jul 2013 06:50:58 +0200] rev 19461
util: check if re2 works before using it (issue 3964)
Thu, 18 Jul 2013 23:22:59 -0500 run-tests: backout 4f32747879d1 line endings change
Matt Mackall <mpm@selenic.com> [Thu, 18 Jul 2013 23:22:59 -0500] rev 19460
run-tests: backout 4f32747879d1 line endings change It made the windows buildbot sad.
Sat, 13 Jul 2013 17:32:54 +0400 hgweb: highlight line which is linked to at comparison view
Alexander Plavin <me@aplavin.ru> [Sat, 13 Jul 2013 17:32:54 +0400] rev 19459
hgweb: highlight line which is linked to at comparison view
Sat, 13 Jul 2013 17:31:53 +0400 hgweb: change highlighted line color to be different from 'inserted' color
Alexander Plavin <me@aplavin.ru> [Sat, 13 Jul 2013 17:31:53 +0400] rev 19458
hgweb: change highlighted line color to be different from 'inserted' color This changes line highlight color from a fain yellow (#ffff99) to a faint blue (#bfdfff), because yellow color is used in comparison view for inserted lines. This new color is okay for people with different forms of color blindness (tested with a simulator): a) this color looks quite different from other used backgrounds b) text doesn't lose distinction on this color
Fri, 19 Jul 2013 01:40:57 +0200 convert: fix bad conversion of copies when hg.startrev is specified
Mads Kiilerich <madski@unity3d.com> [Fri, 19 Jul 2013 01:40:57 +0200] rev 19457
convert: fix bad conversion of copies when hg.startrev is specified The 'copynode' was looked up in self.keep as if it was a changeset node. It is however a filelog node, and self.keep would thus fail if it actually looked at its parameter ... which it only did if a startrev was specified. Instead we now don't check the copy node - we don't have to. It must have been copied from one of the parents, and we already check whether one of the parents have the copy source. We could perhaps use linkrev to see if the corresponding changeset was converted ... but that would sometimes be wrong. The existing test of this was wrong - now it is better, but it seems like it exposes a 'log' issue.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip