Sat, 13 Feb 2016 23:54:24 +0900 templater: lift parsed and compiled templates to generic data types
Yuya Nishihara <yuya@tcha.org> [Sat, 13 Feb 2016 23:54:24 +0900] rev 28545
templater: lift parsed and compiled templates to generic data types Before this patch, parsed and compiled templates were kept as lists. That was inconvenient for applying transformation such as alias expansion. This patch changes the types of the outermost objects as follows: stage old new -------- -------------- ------------------------------ parsed [(op, ..)] ('template', [(op, ..)]) compiled [(func, data)] (runtemplate, [(func, data)]) New templater.parse() function has the same signature as revset.parse() and fileset.parse().
Tue, 15 Mar 2016 15:50:57 -0700 tests: python executable path should always be globbed
Danek Duvall <danek.duvall@oracle.com> [Tue, 15 Mar 2016 15:50:57 -0700] rev 28544
tests: python executable path should always be globbed Although this is coming in under the guise of consistency, part of the desire for this is that at least as part of the official Solaris builds, we build with a versioned python interpreter, such as "python2.7", which doesn't match "*python".
Mon, 14 Mar 2016 15:01:27 +0000 crecord: use ui.interface to choose curses interface
Simon Farnsworth <simonfar@fb.com> [Mon, 14 Mar 2016 15:01:27 +0000] rev 28543
crecord: use ui.interface to choose curses interface use ui.interface to select curses mode, instead of experimental.crecord
Mon, 14 Mar 2016 15:01:27 +0000 ui: add new config flag for interface selection
Simon Farnsworth <simonfar@fb.com> [Mon, 14 Mar 2016 15:01:27 +0000] rev 28542
ui: add new config flag for interface selection This patch introduces a new config flag ui.interface to select the interface for interactive commands. It currently only applies to chunks selection. The config can be overridden on a per feature basis with the flag ui.interface.<feature>. features for the moment can only be 'chunkselector', moving forward we expect to have 'histedit' and other commands there. If an incorrect value is given to ui.interface we print a warning and use the default interface: text. If HGPLAIN is specified we also use the default interface: text. Note that we fail quickly if a feature does not handle all the interfaces that we permit in ui.interface; in future, we could design a fallback path (e.g. blackpearl to curses, curses to text), but let's leave that until we need it.
Fri, 11 Mar 2016 10:30:08 +0000 extensions: also search for extension in the 'hgext3rd' package
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 11 Mar 2016 10:30:08 +0000] rev 28541
extensions: also search for extension in the 'hgext3rd' package Mercurial extensions are not meant to be normal python package/module. Yet the lack of an official location to install them means that a lot of them actually install as root level python package, polluting the global Python package namespace and risking collision with more legit packages. As we recently discovered, core python actually support namespace package. A way for multiples distinct "distribution" to share a common top level package without fear of installation headache. (Namespace package allow submodule installed in different location (of the 'sys.path') to be imported properly. So we are fine as long as extension includes a proper 'hgext3rd.__init__.py' to declare the namespace package.) Therefore we introduce a 'hgext3rd' namespace packages and search for extension in it. We'll then recommend third extensions to install themselves in it. Strictly speaking we could just get third party extensions to install in 'hgext' as it is also a namespace package. However, this would make the integration of formerly third party extensions in the main distribution more complicated as the third party install would overwrite the file from the main install. Moreover, having an explicit split between third party and core extensions seems like a good idea. The name 'hgext3rd' have been picked because it is short and seems explicit enough. Other alternative I could think of where: - hgextcontrib - hgextother - hgextunofficial
Sun, 13 Mar 2016 05:17:06 +0900 hgext: use templatekeyword to mark a function as template keyword
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 13 Mar 2016 05:17:06 +0900] rev 28540
hgext: use templatekeyword to mark a function as template keyword This patch replaces registration of template keyword function in bundled extensions by registrar.templatekeyword decorator all at once.
Sun, 13 Mar 2016 05:17:06 +0900 templatekw: use templatekeyword to mark a function as template keyword
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 13 Mar 2016 05:17:06 +0900] rev 28539
templatekw: use templatekeyword to mark a function as template keyword Using decorator can localize changes for adding (or removing) a template keyword function in source code. This patch also removes leading ":KEYWORD:" part in help document of each keywords, because using templatekeyword makes it useless. For similarity to decorator introduced by subsequent patches, this patch uses 'templatekeyword' instead of 'keyword' as a decorator name, even though the former is a little redundant in 'templatekw.py'. file name reason =================== ================= ================================== templatekw.py templatekeyword for similarity to others templatefilters.py templatefilter 'filter' hides Python built-in one templaters.py templatefunc 'func' is too generic
Sun, 13 Mar 2016 05:17:06 +0900 registrar: add templatekeyword to mark a function as template keyword (API)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 13 Mar 2016 05:17:06 +0900] rev 28538
registrar: add templatekeyword to mark a function as template keyword (API) _templateregistrarbase is defined as a super class of templatekeyword, for ease of adding template common features between "keyword", "filter" and "function". This patch also adds loadkeyword() to templatekw, because this combination helps to figure out how they cooperate with each other. Listing up loadkeyword() in dispatch.extraloaders causes implicit loading template keyword functions at loading (3rd party) extension. This change requires that "templatekeyword" attribute of (3rd party) extension is registrar.templatekeyword or so.
Wed, 16 Mar 2016 11:57:09 +0000 chgserver: do not keep repo object
Jun Wu <quark@fb.com> [Wed, 16 Mar 2016 11:57:09 +0000] rev 28537
chgserver: do not keep repo object The current chgserver design is to use one server to handle multiple repos which has same [extensions] config. Previously the client uses --cwd / to avoid creating a repo object. Now we need to set repo to None before we have code to make "serve" command norepo when it's chg.
Sat, 12 Mar 2016 04:24:11 +0000 chgserver: invalidate the server if extensions fail to load
Jun Wu <quark@fb.com> [Sat, 12 Mar 2016 04:24:11 +0000] rev 28536
chgserver: invalidate the server if extensions fail to load Previously, if extensions fail to load, chg server will just keep working without those extensions. It will print a warning message but only if a new server starts. This patch invalidates the server if any extension failed to load, but still serve the client (hopefully just) once. It will help chg pass some test cases of test-bad-extension.t.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip