Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:54:04 +0200] rev 32963
config: use the new '_unset' value for 'configlist'
This should let 'configlist' delegate all special processing of the default
config value to the main 'config' method.
The default config value ([]) is still handled in this method.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:53:51 +0200] rev 32962
config: use the new '_unset' value for 'configbytes'
This should let 'configbytes' delegates all special processing of the default
config value to the main 'config' method.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:53:40 +0200] rev 32961
config: use the new '_unset' value for 'configint'
This should let 'configint' delegates all special processing of the default
config value to the main 'config' method.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:52:31 +0200] rev 32960
config: use the new '_unset' value for 'configwith'
This should let 'configwith' delegate all special processing of the default
config value to the main 'config' method.
This changeset introduce a small change in behavior since the default value is
run through the 'convert' function. This does not seems harmful and no actual
test break. This small change make the code simpler so I'm keeping it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:52:16 +0200] rev 32959
config: use the new '_unset' value for 'configbool'
This should let 'configbool' delegate all special processing of the default
config value to the main 'config' method.
The default value for bool (False) is still enforced in this method if no other
default were passed.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:51:11 +0200] rev 32958
config: explicitly track the use of the standard default value
We introduce a small object used to detect that no specific default value has
been passed to 'ui.config'. We need this explicit special value since "None" is
a valid and common default value.
The end goal here is to make progress on a centralised and explicit declaration
of the available config option. A first good usecase for this are "default"
value. Before starting looking further down this alley we needs to rework the
handling of default value in the 'ui' object to have all configxyz methods going
through the same logic. This is the first changeset on this trek.
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 22:14:37 -0700] rev 32957
clonebundle: update hook arguments (BC)
By calling applybundle() with 'clonebundles' and the url instead of
calling processbundle(), the hooks will get different arguments:
HG_SOURCE will be 'clonebundles' instead of 'bundle2' and HG_URL will
be the url instead of 'bundle2'. This is consistent with the bundle1
behavior and seems like a bug fix, but I'm marking it BC anyway.
Sean Farley <sean@farley.io> [Sat, 10 Jun 2017 23:42:38 -0700] rev 32956
commands: move checkconflict to bookmarks module
Again, commands.bookmark is getting too large. checkconflict already has
a lot of state and putting it in the bmstore makes more sense than
having it as a closure. This also allows extensions a place to override
this behavior.
While we're here, add a documentation string because, well, we should be
documenting more of our methods.
Sean Farley <sean@farley.io> [Sat, 10 Jun 2017 23:32:58 -0700] rev 32955
commands: move checkformat to bookmarks module
commands.bookmark has grown quite large with two closures already. Let's
split this up (and in the process allow extensions to override the
default behavior).
Danek Duvall <danek.duvall@oracle.com> [Tue, 20 Jun 2017 14:35:53 -0700] rev 32954
tests: tell pip not to check for a newer version
pip will check to see if it's the latest version, and complain if it isn't.
The --no-index flag implies the --disable-pip-version-check flag, and makes
the warning (and any associated network activity) go away.
Yuya Nishihara <yuya@tcha.org> [Sat, 22 Apr 2017 21:16:08 +0900] rev 32953
changeset_templater: backport parts map of [templates] section from formatter
Yuya Nishihara <yuya@tcha.org> [Sat, 22 Apr 2017 21:29:00 +0900] rev 32952
formatter: add support for parts map of [templates] section
Unlike a mapfile whose template is looked up by spec -> mapfile -> topic,
[templates] section is global. We use :sub-section syntax to define parts
per template.
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Jun 2017 16:32:20 +0900] rev 32951
changeset_templater: backport separator template from formatter
As commented, this should be used with docheader and docfooter, not with
header nor footer. That's one reason why no props are passed to templater
when rendering a separator. (See map-cmdline.changelog to understand what
the "header" is.)
Yuya Nishihara <yuya@tcha.org> [Sat, 22 Apr 2017 21:50:51 +0900] rev 32950
formatter: add support for separator template
This seems useful for writing JSON template.
Yuya Nishihara <yuya@tcha.org> [Sat, 22 Apr 2017 21:46:14 +0900] rev 32949
formatter: add support for docheader and docfooter templates
templatepartsmap() is a minimal copy of changeset_templater.__init__(). I
tried to factor out a common function, but it was unnecessarily complicated.
Yuya Nishihara <yuya@tcha.org> [Sat, 22 Apr 2017 21:38:08 +0900] rev 32948
formatter: extract helper function to render template
Yuya Nishihara <yuya@tcha.org> [Sat, 22 Apr 2017 21:09:07 +0900] rev 32947
changeset_templater: do not enable verbosity postfix for [templates] section
Since this postfix hack exists only for backward compatibility, we don't need
it for new [templates] section. This isn't a BC as templates defined in
[templates] section weren't loaded until recently.
Yuya Nishihara <yuya@tcha.org> [Sat, 22 Apr 2017 21:06:11 +0900] rev 32946
changeset_templater: simplify handling of verbosity postfix
Augie Fackler <augie@google.com> [Tue, 20 Jun 2017 16:33:46 -0400] rev 32945
merge with stable
Danek Duvall <danek.duvall@oracle.com> [Mon, 19 Jun 2017 16:08:20 -0700] rev 32944
tests: don't touch the network when using virtualenv
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Jun 2017 17:32:52 -0700] rev 32943
tests: removed ReportedTest exception
The only call site called addFailure before raising, which is
exactly what the failure exception handler does. So this
complexity is not needed.
We have test coverage of this "server failed to start" scenario
and nothing appeared to change.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Jun 2017 17:22:45 -0700] rev 32942
tests: remove support for warned tests
The previous changeset removed the last caller of addWarn(). So,
we rip out that method and all the code related to tracking warned
tests in the results system.
There was even a comment saying we may want to fold warned tests into
the "failed" state, which is what the previous changeset did.
Augie Fackler <augie@google.com> [Tue, 20 Jun 2017 09:49:43 -0400] rev 32941
contrib: add check-code rule to enforce non-use of `python` in tests
Augie Fackler <augie@google.com> [Tue, 20 Jun 2017 09:45:02 -0400] rev 32940
cleanup: use $PYTHON to run python in many more tests
Spotted one of these, then wrote a check-code rule that caught them
all. It will be the next change.
Augie Fackler <augie@google.com> [Thu, 15 Jun 2017 14:22:39 -0400] rev 32939
tests: enforce use of $PYTHON in tests
Augie Fackler <augie@google.com> [Thu, 15 Jun 2017 14:27:52 -0400] rev 32938
tests: use $PYTHON in #! so we always use the right Python
Augie Fackler <augie@google.com> [Tue, 20 Jun 2017 09:33:19 -0400] rev 32937
tests: sed away python #! in test-run-tests.t to avoid some upcoming insanity
Augie Fackler <augie@google.com> [Tue, 20 Jun 2017 08:44:56 -0400] rev 32936
tests: remove #! from primes.py in test-highlight.t
It's about to be a source of trouble, but removing it changes a ton of
test lines, so doing this change as a standalone commit.
Christian Ebert <blacktrash@gmx.net> [Tue, 20 Jun 2017 12:51:36 +0100] rev 32935
keyword: use context manager for rollback locking
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Jun 2017 17:13:35 -0700] rev 32934
tests: remove WarnTest
We would raise this if a test didn't return a result code. AFAICT
this can only occur if there is a logic error in the test harness
itself.
I don't think it is worth the code complexity to distinguish this
failure scenario from a regular test failure.