Wed, 12 Mar 2014 13:21:30 -0400 test-wireproto: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:21:30 -0400] rev 20686
test-wireproto: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:21:17 -0400 test-url: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:21:17 -0400] rev 20685
test-url: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:21:02 -0400 test-filelog: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:21:02 -0400] rev 20684
test-filelog: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:20:42 -0400 templatekw: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:20:42 -0400] rev 20683
templatekw: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:20:24 -0400 minirst: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:20:24 -0400] rev 20682
minirst: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:20:04 -0400 webutil: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:20:04 -0400] rev 20681
webutil: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:19:43 -0400 run-tests: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:19:43 -0400] rev 20680
run-tests: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:19:20 -0400 util: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:19:20 -0400] rev 20679
util: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:29:07 -0400 webcommands: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:29:07 -0400] rev 20678
webcommands: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:15:37 -0400 hgwebdir_mod: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:15:37 -0400] rev 20677
hgwebdir_mod: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:15:09 -0400 filemerge: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:15:09 -0400] rev 20676
filemerge: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:14:31 -0400 changegroup: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:14:31 -0400] rev 20675
changegroup: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:13:42 -0400 extdiff: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:13:42 -0400] rev 20674
extdiff: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:13:10 -0400 bugzilla: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:13:10 -0400] rev 20673
bugzilla: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:12:26 -0400 synthrepo: move from dict() construction to {} literals
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:12:26 -0400] rev 20672
synthrepo: move from dict() construction to {} literals The latter are both faster and more consistent across Python 2 and 3.
Wed, 12 Mar 2014 13:00:51 -0400 wireproto: remove todict() and use {} literals instead
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:00:51 -0400] rev 20671
wireproto: remove todict() and use {} literals instead
Tue, 11 Mar 2014 16:19:08 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Tue, 11 Mar 2014 16:19:08 -0500] rev 20670
merge with stable
Mon, 10 Mar 2014 15:00:41 -0500 templater: deprecate --style now that -T exists
Matt Mackall <mpm@selenic.com> [Mon, 10 Mar 2014 15:00:41 -0500] rev 20669
templater: deprecate --style now that -T exists
Sat, 08 Mar 2014 17:38:50 -0600 templating: make -T much more flexible
Matt Mackall <mpm@selenic.com> [Sat, 08 Mar 2014 17:38:50 -0600] rev 20668
templating: make -T much more flexible It can now accept styles and paths and references to settings in [templates].
Sat, 08 Mar 2014 16:14:08 -0600 changeset_templater: remove use_template method
Matt Mackall <mpm@selenic.com> [Sat, 08 Mar 2014 16:14:08 -0600] rev 20667
changeset_templater: remove use_template method
Sat, 08 Mar 2014 16:01:58 -0600 cmdutil: make helper function to process template args
Matt Mackall <mpm@selenic.com> [Sat, 08 Mar 2014 16:01:58 -0600] rev 20666
cmdutil: make helper function to process template args
Sat, 08 Mar 2014 15:27:25 -0600 commands: add -T alternative to --template
Matt Mackall <mpm@selenic.com> [Sat, 08 Mar 2014 15:27:25 -0600] rev 20665
commands: add -T alternative to --template
Fri, 07 Mar 2014 14:29:26 -0500 config: clarify and exemplify the user name in the sample config file
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 07 Mar 2014 14:29:26 -0500] rev 20664
config: clarify and exemplify the user name in the sample config file
Mon, 10 Mar 2014 01:01:43 +0900 templater: make strings in template expressions be "string-escape"-ed correctly stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 10 Mar 2014 01:01:43 +0900] rev 20663
templater: make strings in template expressions be "string-escape"-ed correctly Changeset 64b4f0cd7336 (released with 2.8.1) fixed "recursively evaluate string literals as templates" problem (issue4102) by moving the location of "string-escape"-ing from "tokenizer()" to "compiletemplate()". But some parts in template expressions below are not processed by "compiletemplate()", and it may cause unexpected result. - 'expr' of 'if(expr, then, else)' - 'expr's of 'ifeq(expr, expr, then, else)' - 'sep' of 'join(list, sep)' - 'text' and 'style' of 'rstdoc(text, style)' - 'text' and 'chars' of 'strip(text, chars)' - 'pat' and 'repl' of 'sub(pat, repl, expr)' For example, '\n' of "{join(extras, '\n')}" is not "string-escape"-ed and treated as a literal '\n'. This breaks "Display the contents of the 'extra' field, one per line" example in "hg help templates". Just "string-escape"-ing on each parts above may not work correctly, because inside expression of nested ones already applies "string-escape" on string literals. For example: - "{join(files, '\n')}" doesn't return "string-escape"-ed string, but - "{join(files, if(branch, '\n', '\n'))}" does To fix this problem, this patch does: - introduce "rawstring" token and "runrawstring" method to handle strings not to be "string-escape"-ed correctly, and - make "runstring" method return "string-escape"-ed string, and delay "string-escape"-ing until evaluation This patch invokes "compiletemplate()" with "strtoken=exp[0]" in "gettemplate()", because "exp[1]" is not yet evaluated. This code path is tested via mapping ("expr % '{template}'"). In the other hand, this patch invokes it with "strtoken='rawstring'" in "_evalifliteral()", because "t" is the result of "arg" evaluation and it should be "string-escape"-ed if "arg" is "string" expression. This patch doesn't test "string-escape"-ing on 'expr' of 'if(expr, then, else)', because it doesn't affect the result.
Mon, 10 Mar 2014 01:01:43 +0900 templater: apply "stringify()" on sub expression to get string correctly stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 10 Mar 2014 01:01:43 +0900] rev 20662
templater: apply "stringify()" on sub expression to get string correctly Templating syntax allows nested expression to be specified as parts below, but they are evaluated as a generator and don't work correctly. - 'sep' of 'join(list, sep)' - 'text' and 'chars' of 'strip(text, chars)' In the former case, 'sep' returns expected string only for the first separation, and empty one for the second or later, because the generator has only one element. In the latter case, templating is aborted by exception, because the generator doesn't have 'strip()' method (as 'text') and can't be passed as the argument to 'str.strip()' (as 'chars'). This patch applies "stringify()" on these sub expression to get string correctly.
Mon, 10 Mar 2014 01:01:42 +0900 templater: avoid recursive evaluation of string literals completely stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 10 Mar 2014 01:01:42 +0900] rev 20661
templater: avoid recursive evaluation of string literals completely Changeset 3d8bfe2ecf6d (released with 2.8.1) fixed "recursively evaluate string literals as templates" problem (issue4103) by introducing "_evalifliteral()". But some parts in template expressions below are still processed by the combination of "compiletemplate()" and "runtemplate()", and may cause same problem unexpectedly. - 'init' and 'hang' of 'fill(text, width, init, hang)' - 'expr' of 'sub(pat, repl, expr)' - 'label' of 'label(label, expr)' This patch processes them by "_evalifliteral()" instead of the combination of "compiletemplate()" and "runtemplate()" to avoid recursive evaluation of string literals completely.
Thu, 06 Mar 2014 17:26:49 -0600 status: improve explanation of ' ' status
Matt Mackall <mpm@selenic.com> [Thu, 06 Mar 2014 17:26:49 -0600] rev 20660
status: improve explanation of ' ' status a) it shows for states other than 'A' b) it only shows with --copies
Tue, 18 Feb 2014 13:07:08 -0800 revset: changed methods in spanset to return ordered sets
Lucas Moscovicz <lmoscovicz@fb.com> [Tue, 18 Feb 2014 13:07:08 -0800] rev 20659
revset: changed methods in spanset to return ordered sets Now __sub__ and __and__ can smartly return ordered lazysets.
Tue, 25 Feb 2014 10:36:23 -0800 revset: added sort method to orderedlazyset
Lucas Moscovicz <lmoscovicz@fb.com> [Tue, 25 Feb 2014 10:36:23 -0800] rev 20658
revset: added sort method to orderedlazyset
Fri, 07 Feb 2014 08:44:18 -0800 revset: added order methods to lazyset classes
Lucas Moscovicz <lmoscovicz@fb.com> [Fri, 07 Feb 2014 08:44:18 -0800] rev 20657
revset: added order methods to lazyset classes This will allow revsets to ask for an ordered set when possible to be able to work lazily with it.
Thu, 06 Mar 2014 12:37:28 +0100 setdiscovery: document algorithms used
Olle Lundberg <geek@nerd.sh> [Thu, 06 Mar 2014 12:37:28 +0100] rev 20656
setdiscovery: document algorithms used This is taken from: http://programmers.stackexchange.com/questions/208998 And modified slightly.
Thu, 20 Feb 2014 09:17:22 +0100 doc: gendoc.py creates valid output for option descriptions with newlines
Simon Heimberg <simohe@besonet.ch> [Thu, 20 Feb 2014 09:17:22 +0100] rev 20655
doc: gendoc.py creates valid output for option descriptions with newlines gendoc.py did not handle the hanging indentation for descriptions. Work around this by joining all in one single line (same as in minirst since previous patch). This problem occurred when translations of option lines were very long. Do not bother the translators with this detail. On a long option description, the translator continued on a new line as usual. gendoc.py created invalid rst syntax like this: -o, --option Description line 1 description line 2 The new output is: -o, --option Description line 1 description line 2 The lines could theoretically become very long, but line breaking is handled when generating the final documentation.
(0) -10000 -3000 -1000 -300 -100 -50 -32 +32 +50 +100 +300 +1000 +3000 +10000 +30000 tip