Mon, 24 Feb 2014 22:42:14 +0100 parsers: introduce index_commonancestorsheads
Mads Kiilerich <madski@unity3d.com> [Mon, 24 Feb 2014 22:42:14 +0100] rev 21102
parsers: introduce index_commonancestorsheads This is an exact copy of index_ancestors but without the final "deepest" pruning.
Thu, 17 Apr 2014 19:49:56 +0200 ancestors: extract candidates function as commonancestorsheads
Mads Kiilerich <madski@unity3d.com> [Thu, 17 Apr 2014 19:49:56 +0200] rev 21101
ancestors: extract candidates function as commonancestorsheads
Thu, 17 Apr 2014 14:54:46 +0200 filemerge: better handling of failing remove of temporary files
Mads Kiilerich <madski@unity3d.com> [Thu, 17 Apr 2014 14:54:46 +0200] rev 21100
filemerge: better handling of failing remove of temporary files We have seen some failures on Windows that could seem like the unlinks of temporary files were failing. That could perhaps be because the merge tool somehow still held the files open. Instead of the bare bone os.unlink, use our util.unlink with special rename/retry handling on Windows.
Thu, 17 Apr 2014 14:54:46 +0200 contrib: remove mergetools.hgrc premerge=False for Beyond Compare and Araxis
Mads Kiilerich <madski@unity3d.com> [Thu, 17 Apr 2014 14:54:46 +0200] rev 21099
contrib: remove mergetools.hgrc premerge=False for Beyond Compare and Araxis There can be good reasons to disable premerge no matter which merge tool is used. Most tools will do just fine without premerge and handle the simple merges more or less automatic and silent. We _could_ thus disable premerge for most tools. But without premerge, the merge tool will be launched for each file - that makes it a slow and expensive process to perform big simple merges. It is thus better to consistently stick to the default premerge=True. The mergetools.hgrc configuration for most tools implicitly use the default premerge=True but Araxis and the Linux entry for Beyond Compare had premerge=False. These lines has been removed. These settings were introduced by 6b354a763617 without further explanation of why they should be good. (We have seen some crashes on Windows with Araxis where a merge failed after a lot of Araxis flashing. I haven't been able to reproduce it and do not know exactly what happened. Enabling premerge avoids the problems.)
Wed, 16 Apr 2014 03:05:00 +0900 obsolete: add '%' specifier to the format string to avoid TypeError at runtime
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 16 Apr 2014 03:05:00 +0900] rev 21098
obsolete: add '%' specifier to the format string to avoid TypeError at runtime Mapping operation on the format string not including any '%' specifiers causes TypeError at runtime.
Wed, 16 Apr 2014 03:05:00 +0900 check-code: detect "% inside _()" when there are leading whitespaces
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 16 Apr 2014 03:05:00 +0900] rev 21097
check-code: detect "% inside _()" when there are leading whitespaces Before this patch, "contrib/check-code.py" can't detect "% inside _()" correctly, when there are leading whitespaces before the format string, like below: _( "format string %s" % v) This patch adds regexp pattern "[ \t\n]*" before the pattern matching against the format string. "[\s\n]" can't be used in this purpose, because "\s" is automatically replaced with "[ \t]" by "_preparepats()" and "\s" in "[]" causes nested "[]" unexpectedly.
Wed, 16 Apr 2014 03:05:00 +0900 i18n: fix "% inside _()" problem
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 16 Apr 2014 03:05:00 +0900] rev 21096
i18n: fix "% inside _()" problem
(0) -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip