Wed, 14 Jan 2015 15:31:16 -0500 sslutil: drop support for clients of sslutil specifying a TLS version
Augie Fackler <augie@google.com> [Wed, 14 Jan 2015 15:31:16 -0500] rev 23849
sslutil: drop support for clients of sslutil specifying a TLS version We really just want to support the newest thing possible, so we may as well consolidate that knowledge into this module. Right now this doesn't change any behavior, but a future change will fix the defaults for Python 2.7.9 so we can use slightly better defaults there (which is the only place it's possible at the moment.)
Wed, 07 Jan 2015 00:07:29 -0800 discovery: run discovery on filtered repository
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 07 Jan 2015 00:07:29 -0800] rev 23848
discovery: run discovery on filtered repository We have been running discovery on unfiltered repository for quite some time. This was aimed at two things: - save some bandwith by prevent the repushing of common but hidden changesets - allow phases changes on secret/hidden changeset on bare push. The cost of this unfiltered discovery combined with evolution is actually really high. Evolution likely create thousand of hidden heads, and the discovery is going to try to discovery if each of them are common or not. For example, pushing from my development mercurial repository implies 17 discovery round-trip. The benefit are rare corner cases while the drawback are massive. So we run the discovery on a filtered repository again. We add some hack to detect remote heads that are known locally and adds them to the common set anyway, so the good behavior of most of the corner case should remains. But this will not work in all cases. This bring my discovery phase back from 17 round-trips to 1 or 2.
Sat, 10 Jan 2015 23:18:11 +0900 revset: check for collisions between alias argument names in the declaration
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 10 Jan 2015 23:18:11 +0900] rev 23847
revset: check for collisions between alias argument names in the declaration Before this patch, collisions between alias argument names in the declaration are ignored, and this silently causes unexpected alias evaluation. This patch checks for such collisions, and aborts (or shows a warning) when collisions are detected. This patch doesn't add a test to "test-revset.t", because a doctest is enough to test the collisions detection itself.
Sat, 10 Jan 2015 23:18:11 +0900 revset: parse alias declaration strictly by _parsealiasdecl
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 10 Jan 2015 23:18:11 +0900] rev 23846
revset: parse alias declaration strictly by _parsealiasdecl Before this patch, alias declaration is parsed by string base operations: matching against "^([^(]+)\(([^)]+)\)$" and splitting by ",". This overlooks many syntax errors like below (see the previous patch introducing "_parsealiasdecl" for detail): - un-closed parenthesis causes being treated as "alias symbol" - symbol/function name aren't examined whether they are valid or not - invalid argument list causes unexpected argument names To parse alias declaration strictly, this patch replaces parsing implementation by "_parsealiasdecl". This patch tests only one typical declaration error case, because error detection itself is already tested in the doctest of "_parsealiasdecl". This also removes class property "args" and "error", because these are certainly initialized in "revsetalias.__init__".
Sat, 10 Jan 2015 23:18:11 +0900 revset: introduce "_parsealiasdecl" to parse alias declarations strictly
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 10 Jan 2015 23:18:11 +0900] rev 23845
revset: introduce "_parsealiasdecl" to parse alias declarations strictly This patch introduces "_parsealiasdecl" to parse alias declarations strictly. For example, "_parsealiasdecl" can detect problems below, which current implementation can't. - un-closed parenthesis causes being treated as "alias symbol" because all of declarations not in "func(....)" style are recognized as "alias symbol". for example, "foo($1, $2" is treated as the alias symbol. - alias symbol/function names aren't examined whether they are valid as symbol or not for example, "foo bar" can be treated as the alias symbol, but of course such invalid symbol can't be referred in revset. - just splitting argument list by "," causes overlooking syntax problems in the declaration for example, all of invalid declarations below are overlooked: - foo("bar") => taking one argument named as '"bar"' - foo("unclosed) => taking one argument named as '"unclosed' - foo(bar::baz) => taking one argument named as 'bar::baz' - foo(bar($1)) => taking one argument named as 'bar($1)' To decrease complication of patch, current implementation for alias declarations is replaced by "_parsealiasdecl" in the subsequent patch. This patch just introduces it. This patch defines "_parsealiasdecl" not as a method of "revsetalias" class but as a one of "revset" module, because of ease of testing by doctest. This patch factors some helper functions for "tree" out, because: - direct accessing like "if tree[0] == 'func' and len(tree) > 1" decreases readability - subsequent patch (and also existing code paths, in the future) can use them for readability This patch also factors "_tokenizealias" out, because it can be used also for parsing alias definitions strictly.
Sat, 10 Jan 2015 23:18:11 +0900 revset: store full detail into revsetalias.error for error source distinction
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 10 Jan 2015 23:18:11 +0900] rev 23844
revset: store full detail into revsetalias.error for error source distinction Before this patch, any errors in the declaration of revset alias aren't detected at all, and there is no information about error source in the error message. As a part of preparation for parsing alias declarations and definitions more strictly, this patch stores full detail into "revsetalias.error" for error source distinction. This makes raising "Abort" and warning potential errors just use "revsetalias.error" without any message composing.
Sat, 10 Jan 2015 23:18:11 +0900 revset: factor out composing error message for ParseError to reuse
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 10 Jan 2015 23:18:11 +0900] rev 23843
revset: factor out composing error message for ParseError to reuse This patch defines the composing function not in "ParseError" class but in "revset" module, because: - "_()" shouldn't be used in "ParseError", to avoid adding "from i18n import _" i18n" to "error" module - generalizing message composition of"ParseError" for all code paths other than revset isn't the purpose of this patch we should also take care of showing "unexpected leading whitespace" for some code paths, to generalize widely.
Sat, 10 Jan 2015 23:18:11 +0900 revset: make tokenize extensible to parse alias declarations and definitions
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 10 Jan 2015 23:18:11 +0900] rev 23842
revset: make tokenize extensible to parse alias declarations and definitions Before this patch, "tokenize" doesn't recognize the symbol starting with "$" as a valid one. This prevents revset alias declarations and definitions from being parsed with "tokenize", because "$" may be used as the initial letter of alias arguments. BTW, the alias argument name doesn't require leading "$" itself, in fact. But we have to assume that users may use "$" as the initial letter of argument names in their aliases, because examples in "hg help revsets" uses such names for a long time. To make "tokenize" extensible to parse alias declarations and definitions, this patch introduces optional arguments "syminitletters" and "symletters". Giving these sets can change the policy of "valid symbol" in tokenization easily. This patch keeps original examination of letter validity for reviewability, even though there is redundant interchanging between "chr"/"ord" at initialization of "_syminitletters" and "_symletters". At most 256 times examination (per initialization) is cheaper enough than revset evaluation itself. This patch is a part of preparation for parsing alias declarations and definitions more strictly.
Fri, 09 Jan 2015 18:38:02 +0100 largefiles: make linear update set unsure largefiles normal if unchanged
Mads Kiilerich <madski@unity3d.com> [Fri, 09 Jan 2015 18:38:02 +0100] rev 23841
largefiles: make linear update set unsure largefiles normal if unchanged 'hg update' would hash all 'unsure' largefiles before performing the merge. It would update the standins but not detect the very common case where the largefile never had been changed by the user but just had been marked with an invalid dirstate mtime to make sure any changes done by the user in the same second would be detected. The largefile would remain in that state and would have to be hashed again next time even though it still not had been changed. Sad trombone. Instead, for largefiles listed as 'unsure' or 'modified', after updating the standin with the actual hash, mark the largefile as normal if it turns out to not be modified relative to the revision in the parent revision. That will prevent it from being hashed again next time.
Fri, 09 Jan 2015 18:38:02 +0100 debugdirstate: don't hide date field with --nodate, just show 'set'/'unset'
Mads Kiilerich <madski@unity3d.com> [Fri, 09 Jan 2015 18:38:02 +0100] rev 23840
debugdirstate: don't hide date field with --nodate, just show 'set'/'unset' The value of the dirstate date field cannot be used in tests and we thus have to use debugdirstate with --nodate. It is however still very helpful to be able to see whether the date field has been set or still is unset. The absence of that information made it hard to debug some largefile dirstate issues. This change _could_ make the test suite more unstable ... but that would be places where the test suite or the code should be made more stable. (Note: 'unset' with the magic negative sizes is reliable. 'unset' for normal sizes would probably not be reliable, but there is no such occurrences in the test suite and it should thus be reliable.) This output wastes more horizontal space in the --nodate output, but it also makes things simpler that the output format always is the same. It is just a debug command so let's keep it simple.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip