Mon, 29 Apr 2013 15:58:15 +0900 merge: increase safety of parallel updating/removing on icasefs stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 29 Apr 2013 15:58:15 +0900] rev 19095
merge: increase safety of parallel updating/removing on icasefs "merge.applyupdates()" sorts "actions" in removal first order, and "workeractions" derived from it should be also sorted. If each actions in "workeractions" are executed in serial, this sorting ensures that merging/updating process is collision free, because updating the file in target context is always executed after removing the existing file which causes case-folding collision against the former. In the other hand, if each actions are executed in parallel, updating on a worker process may be executed before removing on another worker process, because "worker.partition()" partitions list of actions regardless of type of each actions. This patch divides "workeractions" into removing and updating, and executes the former first. This patch still scans "actions"/"workeractions" some times for ease of patch review, even though large list may cost much in this way. (total cost should be as same as before) This also changes some tests, because dividing "workeractions" affects progress indication.
Tue, 30 Apr 2013 13:53:49 +0200 hgweb: handle filtered "0" rev in navigation stable
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 30 Apr 2013 13:53:49 +0200] rev 19094
hgweb: handle filtered "0" rev in navigation Before this changeset, navigation generation crashed if revision "0" was filtered. We introduce a `_first` methods on revision navigation that return the lowest unfiltered element and use it in two place were the "0" changeset was explicitly referenced. Test case are introduced.
Tue, 30 Apr 2013 15:11:12 +0200 hgweb: fix empty navigation detection stable
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 30 Apr 2013 15:11:12 +0200] rev 19093
hgweb: fix empty navigation detection For some obscure reason, changelog.node(0) returns nullid if changelog is empty. this break empty navigation detection. We fix this code by using the length of the changelog. Using the length have some issue with revision filtering but this is a small step in the right direction. Proper fix comes in later changeset.
Tue, 30 Apr 2013 14:56:33 +0100 tests: AIX can't handle negative date in test-dirstate.t stable
Jim Hague <jim.hague@acm.org> [Tue, 30 Apr 2013 14:56:33 +0100] rev 19092
tests: AIX can't handle negative date in test-dirstate.t test-dirstate.t fails on AIX in the absurd date test. AIX touch errors on any date prior to 1970. AIX mktime() gives an error on such dates, so the problem is deeper than touch and attempts to work around touch in Python failed. Give up. Add an AIX test to hghave and skip the absurd date test on AIX.
Fri, 26 Apr 2013 01:12:03 +0900 win32: use explicit path to "python.exe" only if it exists stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 26 Apr 2013 01:12:03 +0900] rev 19091
win32: use explicit path to "python.exe" only if it exists Before this patch, "hg.bat" for Windows environment always uses "%~dp0..\python" as explicit path to "python.exe". This path may not be valid in some cases. For example, on the environment using "virtualenv" python package, both "python.exe" and "hg.bat" are placed in the same directory. In this case, "python.exe" should be found on PATH, because virtualenv activation script puts "python.exe" on the PATH. This patch uses explicit path to "python.exe" only if it exists, and expects that "python.exe" can be found on PATH otherwise.
Fri, 26 Apr 2013 22:07:25 -0700 test-mq-strip.t: add a test for strip --keep with clean working dir stable
Siddharth Agarwal <sid0@fb.com> [Fri, 26 Apr 2013 22:07:25 -0700] rev 19090
test-mq-strip.t: add a test for strip --keep with clean working dir This helped uncover a bug in a patchset I've been writing.
Sat, 27 Apr 2013 00:41:42 +0200 largefiles: use repo.wwrite for writing standins (issue3909) stable
Mads Kiilerich <madski@unity3d.com> [Sat, 27 Apr 2013 00:41:42 +0200] rev 19089
largefiles: use repo.wwrite for writing standins (issue3909)
Fri, 26 Apr 2013 19:04:01 +0200 largefiles: drop repo wrapping detection stable
Mads Kiilerich <madski@unity3d.com> [Fri, 26 Apr 2013 19:04:01 +0200] rev 19088
largefiles: drop repo wrapping detection After 257afe5489d4 I see: $ hg id -q largefiles: repo method 'commit' appears to have already been wrapped by another extension: largefiles may behave incorrectly largefiles: repo method 'push' appears to have already been wrapped by another extension: largefiles may behave incorrectly be207d9b7e4b The warning is bad: * The message gives no hint what the problem is and how it can be resolved. The message is useless. * Largefiles do have its share of problems, but I don't think I ever have seen a problem where this warning would have helped. The 'may' in the warning seems like an exaggeration of the risk. Having largefiles enabled in combination with for instance mq, hggit and hgsubversion causes a warning (depending on the configuration order) but do not cause problems. Extensions might of course be incompatible, but they can be that in many other ways. The check and the message are incorrect. It would thus be better to remove the check and the warning completely. Before 257afe5489d4 the check always failed. That change made the check work more like intended ... but the intention was wrong. This change will thus also back that change out.
Fri, 26 Apr 2013 23:36:12 +0900 config: discard "%unset" values defined in the other files read in previously stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 26 Apr 2013 23:36:12 +0900] rev 19087
config: discard "%unset" values defined in the other files read in previously Before this patch, "%unset" can't unset values defined in the other files read in previously, even though online help document says that it can. It can unset only values defined in the same configuration file. For example, the value defined in "~/.hgrc" can't be unset by "%unset" in ".hg/hgrc" of the repository. This patch records "%unset"-ed values in "config.parse()", and discards corresponding values in "config.update()".
Fri, 26 Apr 2013 23:16:25 +0900 tests: rename from test-config-case.t to test-config.t for centralization stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 26 Apr 2013 23:16:25 +0900] rev 19086
tests: rename from test-config-case.t to test-config.t for centralization Before this patch, there is no test script testing configuration handling generally. "test-config-case.t" seems to be specific for testing case sensitive configuration. This patch renames from "test-config-case.t" to "test-config.t" for centralization of tests around configuration handling.
Thu, 25 Apr 2013 20:48:49 +0900 i18n: show the non-ASCII password prompt text correctly stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 25 Apr 2013 20:48:49 +0900] rev 19085
i18n: show the non-ASCII password prompt text correctly Before this patch, the prompt text for asking password is directly passed to "getpass.getpass()" of Python standard library. In "getpass.getpass()" implementation on Windows environment, the prompt text is split into byte sequence and "msvcrt.putch()" is applied on each bytes in it. This splitting causes non-ASCII prompt text to be broken. This patch shows the prompt text for asking password on "ui.getpass()" side, and invokes "getpass.getpass()" with empty prompt text. This prevents non-ASCII prompt text from being broken in "getpass.getpass()" implementation. This patch also sets "ui.prompt" label to prompt text to follow "ui.prompt()" style.
Tue, 23 Apr 2013 17:26:00 -0500 tests: make sed usage in test-unionrepo.t cross-platform stable
Kevin Bullock <kbullock@ringworld.org> [Tue, 23 Apr 2013 17:26:00 -0500] rev 19084
tests: make sed usage in test-unionrepo.t cross-platform Usage of the 'i' command proves tricky. I tried to write a check-code rule, but failed.
Tue, 23 Apr 2013 16:57:51 -0500 check-code: fix sed 'i' command rule newline matching stable
Kevin Bullock <kbullock@ringworld.org> [Tue, 23 Apr 2013 16:57:51 -0500] rev 19083
check-code: fix sed 'i' command rule newline matching The regular expression was meant to match cases where an 'i' command was not followed by precisely a '\' and then a newline; it failed to match the newline, so cases with a '\' but no newline would erroneously pass.
Mon, 22 Apr 2013 18:00:59 -0700 blackbox: don't run permission tests on non-unix systems stable
Durham Goode <durham@fb.com> [Mon, 22 Apr 2013 18:00:59 -0700] rev 19082
blackbox: don't run permission tests on non-unix systems The windows and vfat test runs were failing due to read/write permissions not working the same on those systems. On vfat, permissions can't be changed at all, and on windows it seems the chmod emulation doesn't remove read permissions. We could theoretically get the 'cannot write to blacklog.log' test to pass on windows but there's no #if condition to let us exclude vfat only. Verified that test-blackbox passes on windows now.
Mon, 22 Apr 2013 16:50:08 -0500 check-code: expand sed rule to include more offenders stable
Kevin Bullock <kbullock@ringworld.org> [Mon, 22 Apr 2013 16:50:08 -0500] rev 19081
check-code: expand sed rule to include more offenders Expands the rule added in 5e4491c114b2 to include cases where the address is a line number instead of a regular expression, and fixes an instance of this pattern in test-unionrepo.t.
Mon, 22 Apr 2013 16:33:28 -0500 check-code: add a rule against a GNU sed-ism stable
Kevin Bullock <kbullock@ringworld.org> [Mon, 22 Apr 2013 16:33:28 -0500] rev 19080
check-code: add a rule against a GNU sed-ism BSD sed requires the 'i' command to be followed with a backslash and a newline, like so: $ sed -e '/^@/i\ > other' We've encountered this problem before, e.g. in test-mq.t (900767dfa80d). This change adds a check-code rule and fixes two instances of the problem in test-record.t.
Mon, 22 Apr 2013 12:27:56 +0400 hgweb: make help verbose again (issue3899) stable
Alexander Plavin <me@aplavin.ru> [Mon, 22 Apr 2013 12:27:56 +0400] rev 19079
hgweb: make help verbose again (issue3899) Due to regression introduced in f5db3092790f, help in hgweb was rendered in non-verbose form (issue3899)
Sun, 21 Apr 2013 17:33:51 -0500 merge with i18n stable
Matt Mackall <mpm@selenic.com> [Sun, 21 Apr 2013 17:33:51 -0500] rev 19078
merge with i18n
Sat, 20 Apr 2013 19:01:36 -0300 i18n-pt_BR: synchronized with 64ea454e7d76 stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Sat, 20 Apr 2013 19:01:36 -0300] rev 19077
i18n-pt_BR: synchronized with 64ea454e7d76
Sat, 20 Apr 2013 16:46:38 +0400 css: remove repeated property stable
Alexander Plavin <me@aplavin.ru> [Sat, 20 Apr 2013 16:46:38 +0400] rev 19076
css: remove repeated property 'margin' property was repeated for the same selector
Sat, 20 Apr 2013 22:09:17 +0400 css: fixed font-family stable
Alexander Plavin <me@aplavin.ru> [Sat, 20 Apr 2013 22:09:17 +0400] rev 19075
css: fixed font-family There is no 'sans' font-family, replaced with 'sans-serif'
Fri, 19 Apr 2013 22:03:59 -0700 color: add a test with extension loaded and ui.formatted=False stable
Siddharth Agarwal <sid0@fb.com> [Fri, 19 Apr 2013 22:03:59 -0700] rev 19074
color: add a test with extension loaded and ui.formatted=False
Fri, 19 Apr 2013 16:57:10 -0700 color: set _colormode to None when mode is unset (issue3895) stable
Siddharth Agarwal <sid0@fb.com> [Fri, 19 Apr 2013 16:57:10 -0700] rev 19073
color: set _colormode to None when mode is unset (issue3895) Previously, colorui assumed that it would only be called when mode wasn't None. 7ae12ce87594 changed that, so now colorui needs to care about whether it should colorize output.
Fri, 19 Apr 2013 16:57:20 -0700 color: turn colorui functions into forwards when color is None stable
Siddharth Agarwal <sid0@fb.com> [Fri, 19 Apr 2013 16:57:20 -0700] rev 19072
color: turn colorui functions into forwards when color is None colorui will be set to None as necessary in an upcoming patch.
Fri, 19 Apr 2013 18:26:35 -0300 largefiles: fix typos in documentation stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Fri, 19 Apr 2013 18:26:35 -0300] rev 19071
largefiles: fix typos in documentation
Fri, 19 Apr 2013 10:55:11 -0700 translations: change label integer error to not specify the kind of label stable
Durham Goode <durham@fb.com> [Fri, 19 Apr 2013 10:55:11 -0700] rev 19070
translations: change label integer error to not specify the kind of label The current error message used the kind (bookmark, branch, tag) in the message. Unfortunately this isn't easily translatable since some languages give different genders to these words. The fix is to not specify it at all, since it should be implicit based on the command the user just ran. Relevant discussions around this area: http://selenic.com/pipermail/mercurial-devel/2012-October/045567.html http://selenic.com/pipermail/mercurial-devel/2012-October/045600.html
Thu, 18 Apr 2013 23:50:15 -0500 Added signature for changeset 292cd385856d stable
Matt Mackall <mpm@selenic.com> [Thu, 18 Apr 2013 23:50:15 -0500] rev 19069
Added signature for changeset 292cd385856d
Thu, 18 Apr 2013 23:50:08 -0500 Added tag 2.6-rc for changeset 292cd385856d stable
Matt Mackall <mpm@selenic.com> [Thu, 18 Apr 2013 23:50:08 -0500] rev 19068
Added tag 2.6-rc for changeset 292cd385856d
(0) -10000 -3000 -1000 -300 -100 -50 -28 +28 +50 +100 +300 +1000 +3000 +10000 +30000 tip