config: register the 'devel.serverexactprotocol' config

config: register the 'devel.servercafile' config

config: register the 'devel.disableloaddefaultcerts' config

config: register the 'devel.check-relroot' config

config: register the devel.check-locks config

config: register the 'devel.bundle2.debug' config Existing explicit default are dropped now that the default is centralised.

config: register the 'devel.all-warnings' config Let us start registering the existing option. I'm starting with the 'devel' section because it is full of useful things that are poorly documented. So registering these will more than other section.

rebase: always pass destination as revnum to _handleskippingobsolete() We were passing it as a revision number in one place and as a context in another. It worked because the only use was in "repo[dest].rev()", but it was confusing. By always passing a revision number, we can also remove that unnecessary lookup.

patch: remove unused fsbackend._join() The function lost its last caller in 2a095d3442e0 (patch: replace functions in fsbackend to use vfs, 2014-06-05) when the callers started relying on the opener to do the join.

patch: add close() to abstractbackend patchbackend() seems to call it on an arbitrary backend, so it seems to be part of the API. Since all subclasses do something in their close() methods, I decided to let this one raise an exception rather than just pass.

log: add an extension hook-point in changeset_printer Extensions sometimes wants to add other information in the default log output format (when no templating is used). Add an empty function named '_exthook' for easing the extension life. Extensions will be able to wrap this function and collaborate to display additional information. Exthook is called after displaying troubles and just before displaying the files, extra and description. Add a new test file to test it and not pollute other test files.

drawdag: support obsmarker creation in comments This patch adds special comment handling so one can create obsmarkers in drawdag comments like "# replace: A -> B -> C", "# prune: X, Y, Z", "split: P -> M, N" and they are just self-explained.

test-drawdag: add a test for drawdag.py The drawdag script is useful but does not have a formal test. This patch adds it.

filemerge: convert a couple of wvfs calls in internal mergetools to contexts One hitch is that sometimes fcd is actually an absentfilectx which does not expose any mutator functions. In order to still use the context functions, we look up the underlying workingfilectx to perform the write there. One alternate way would be to put the write functions on the absentfilectx and have them pass-through. While this makes the callsites cleaner, we would need to decide what its getter functions would return after this point, since returning None for `data` (and True for `isabsent()`) might no longer be correct after a write. I discussed with Sidd about just having the getters raise RuntimeErrors after a mutator has been called, but we actually call isabsent() in merge.py after running the internal merge tools.

configitems: support callable as a default value Yuya pointed out that using mutable value as the default could be problematic. To work around this we now support callable object as default value. This allows for creating new mutable objects on demand when needed.

obsutil: move 'getmarkers' to the new modules We have a new 'obsutil' module now. We move the high level utility there to bring 'obsolete.py' back to a more reasonable size.

obsutil: move the 'marker' class to the new modules We have a new 'obsutil' module now. We move high level utility there to bring 'obsolete.py' back to a more reasonable size.

obsolete: delete three unused utility functions None of this function has been used in the past 5 years, so I think it is safe to just kill them. All code accessing rich markers is using 'getmarkers(...)' instead (or raw markers).

obsutil: move 'foreground' to the new modules We have a new 'obsutil' module now. We move the high level utility there to bring 'obsolete.py' back to a more reasonable size.

obsutil: move 'allsuccessors' to the new modules We have a new 'obsutil' module now. We move the high level utility there to bring 'obsolete.py' back to a more reasonable size.

obsutil: move 'allprecursors' to the new modules We have a new 'obsutil' module now. We move the high level utility there to bring 'obsolete.py' back to a more reasonable size.

obsutil: move 'exclusivemarkers' to the new modules We have a new 'obsutil' module now. We move the high level utility there to bring 'obsolete.py' back to a more reasonable size.

obsutil: move 'successorssets' to the new modules We have a new 'obsutil' module now. We move this high level utility there to bring 'obsolete.py' back to a more reasonable size.

revlog: add an experimental option to mitigated delta issues (issue5480) The general delta heuristic to select a delta do not scale with the number of branch. The delta base is frequently too far away to be able to reuse a chain according to the "distance" criteria. This leads to insertion of larger delta (or even full text) that themselves push the bases for the next delta further away leading to more large deltas and full texts. This full text and frequent recomputation throw Mercurial performance in disarray. For example of a slightly large repository 280 000 files (2 150 000 versions) 430 000 changesets (10 000 topological heads) Number below compares repository with and without the distance criteria: manifest size: with: 21.4 GB without: 0.3 GB store size: with: 28.7 GB without 7.4 GB bundle last 15 00 revisions: with: 800 seconds 971 MB without: 50 seconds 73 MB unbundle time (of the last 15K revisions): with: 1150 seconds (~19 minutes) without: 35 seconds Similar issues has been observed in other repositories. Adding a new option or "feature" on stable is uncommon. However, given that this issues is making Mercurial practically unusable, I'm exceptionally targeting this patch for stable. What is actually needed is a full rework of the delta building and reading logic. However, that will be a longer process and churn not suitable for stable. In the meantime, we introduces a quick and dirty mitigation of this in the 'experimental' config space. The new option introduces a way to set the maximum amount of memory usable to store a diff in memory. This extend the ability for Mercurial to create chains without removing all safe guard regarding memory access. The option should be phased out when core has a more proper solution available. Setting the limit to '0' remove all limits, setting it to '-1' use the default limit (textsize x 4).

tests: fix variable name regular expression in _genrestoreenv() Update the code to correctly anchor the expression on the end of the name, to require that the entire name match this expression. It was already anchored at the start by using re.match(), but this does not anchor it at the end.

merge with stable

pushrace: avoid crash on bare push when using concurrent push mode If the remote is empty, we do now bother computing head changes and the 'pushbranchmap' attribute stays at None. We now handle and tests this case.

show: config option to register aliases for views As part of using `hg show` in my daily workflow, I've found it slightly annoying to have to type full view names, complete with a space. I've locally registered an alias for "swork = show work." I think others will have this same complaint and could benefit from some automation to streamline the creation of aliases. So, this commit introduces a config option that allows `hg show` views to be automatically aliased using a given prefix. e.g. a value of "s" will automatically register "swork" and "sbookmarks." Multiple values can be given for ultimate flexibility. This arguably isn't needed now. But since we don't register aliases if there will be a collision and we're bound to have a collision, it makes sense to allow multiple prefixes so specific views can avoid collisions by using different prefixes.

blackbox: use a human readable version of the default Now that the default value is also converted we can use a human readable version for it. This will be useful if we start to automatically display the default config value in various place.

configitems: register 'blackbox.maxsize' as an example of 'configbytes' This exercise the default value handling in 'configbytes'.

blackbox: minor code reordering The version declaration should come first in my opinion. This will help gather the command table with the config table.

configitems: add a devel warning for extensions items overiding core one We do not want such case to pass silently. In the future we'll likely have useful tool for an extension to alter the existing definition in core.

configitems: add an official API for extensions to register config item Extensions can have a 'configtable' mapping and use 'registrar.configitem(table)' to retrieve the registration function. This behave in the same way as the other way for extensions to register new items (commands, colors, etc).

configitems: extract the logic to build a registrar on any configtable Having the logic available independently from the mapping used is a necessary step toward extensions support.

obsolete: skip 'changectx' usage in unstable computation We simplify the unstable computation code, skipping the expensive creation of changectx object. We focus on efficient set operation and revnumber centric functions. In my mercurial development repository, this provides a 3x speedup to the function: before: 5.319 ms after: 1.844 ms repo details: total changesets: 40886 obsolete changesets: 7756 mutable (not obsolete): 293 unstable: 30

obsolete: provide a small function to retrieve all mutable revisions More obsolescence related algorithm focus on the mutable revision. We provide a tiny utility function to make it easy to access this set.

bundle2: add debug info about the number of stream params Seems like the %i was never substituted.

bundle2: add some debugging information to the not-a-bundle error I found this useful while trying to debug wireproto-related issues.

tests: more completely restore the environment in syshgenv Update the syshgenv function to attempt to completely restore the original environment, rather than only updating a few specific variables. run_tests.py now generates a shell script that can be used to restore the original environment, and syshgenv sources it. This is a bit more complicated than the previous code, but should do a better job of running the system hg in the correct environment. I've tested it on Linux using python 2.x, but let me know if it causes issues in other environments. I'm not terribly familiar with how the tests get run on Windows, for instance, and how the environment needs to be updated there.

tests: do not use system hg if it does not have "files" command Ancient hg does not have "hg files" so test-check-*.t will fail with "unknown command 'files'": $ hg files hg: unknown command 'files' $ hg --version Mercurial Distributed SCM (version 2.6.2) Test "hg files" and give up using syshg if it does not have "files" command.

rebase: also test abort from pretxnclose error Different hooks will have different properties so we cover more hooks to catch further regressions.

rebase: reinforce testing around precommit hook interrupting a rebase Different hooks will have different properties so we cover more hooks to catch further regression.

rebase: provides test case for (issue5610) The 4.2 release introduces a regression regarding the behavior of rebase with some hook failures. We add the tests from the bug report from Henrik Stuart to our test base to prevent further regression on this.

rebase: backed out changeset cf8ad0e6c0e4 (issue5610) Having a single transaction for rebase means the whole transaction gets rolled back on error. To work around this a small hack has been added to detect merge conflict and commit the work done so far before exiting. This hack works because there is nothing transaction related going on during the merge phase. However, if a hook blocks the rebase to create a changeset, it is too late to commit the work done in the transaction before the problematic changeset was created. This leads to the whole rebase so far being rolled back. Losing merge resolution and other work in the process. (note: rebase state will be fully lost too). Since issue5610 is a pretty serious regression and the next stable release is a couple day away, we are taking the backout route until we can figure out something better to do.

rebase: backed out changeset 2519994d25ca In the process of fixing issue5610 in 4.2.2, we are trying to backout cf8ad0e6c0e4. This changeset is making changes that depend on cf8ad0e6c0e4, so we need to back it out first. Since issue5610 is pretty serious regression and the next stable release is a couple of days away, we are taking the backout route until we can figure out something better to do.

setup: fix runcmd() usage on darwin Fix one invocation of runcmd() that was missed in the recent change to make runcmd() also return the process exit status.

py3: update the python3-whitelist with new tests which pass on Python 3 We have now 34 tests passing on Python 3.

setup: fix localhgenv It should return env as a dict instead of None.

tests: use the system hg for examining the local repository Most test scripts use "hg" to interact with a temporary test repository. However a few tests also want to run hg commands to interact with the local repository containing the mercurial source code. Notably, many of the test-check-* tests want to check local files and commit messages. These tests were previously using the version of hg being tested to query the source repository. However, this will fail if the source repository requires extensions or other settings not supported by the version of mercurial being tested. The source repository was typically initially cloned using the system hg installation, so we should use the system hg installation to query it. There was already a helpers-testrepo.sh script designed to help cope with different requirements for the source repository versus the test repositories. However, it only handled the evolve extension. This new behavior works with any extensions that are different between the system installation and the test installation.

tests: save the original PATH and PYTHONPATH variables When running the tests, define ORIG_PATH and ORIG_PYTHONPATH environment variables that contain the original contents of PATH and PYTHONPATH, before they were modified by run-tests.py This will make it possible for tests to refer to the original contents of these variables if necessary. In particular, this is necessary for invoking the correct version of hg for examining the local repository (the mercurial repository itself, not the temporary test repositories). Various tests examine the local repository to check the file lists and contents of commit messages.

setup: prefer using the system hg to interact with the local repository Add a findhg() function that tries to be smarter about figuring out how to run hg for examining the local repository. It first tries running "hg" from the user's PATH, with the default HGRCPATH settings intact, but with HGPLAIN enabled. This will generally use the same version of mercurial and the same settings used to originally clone the repository, and should have a higher chance of working successfully than trying to run the hg script from the local repository. If that fails findhg() falls back to the existing behavior of running the local hg script.

setup: replace runhg() with an hgcommand helper class Replace the runhg() function with an hgcommand helper class. hgcommand has as run() function similar to runhg(), but no longer requires the caller to pass in the exact path to python and the hg script, and the environment settings for invoking hg. For now this diff contains no behavior changes, but in the future this will make it easier for the hgcommand helper class to more intelligently figure out the proper way to invoke hg.

setup: move environment computation into a helper function Add a helper function to compute the environment used for invoking mercurial, rather than doing this computation entirely at global scope. This will make it easier to do some subsequent refactoring.

setup: update runcmd() to also return the exit status Update the runcmd() helper function so it also returns the process exit status. This allows callers to more definitively determine if a command failed, rather than testing only for the presence of data on stderr. I don't expect this to have any behavioral changes for now: the commands invoked by setup generally should print data on stderr if and only if they failed.

setup: fail if we cannot determine the version number If running hg fails, exit the setup script unsuccessfully, rather than proceeding to use a bogus version of "+0-". Using an invalid version number causes various tests to fail later. Failing early makes it easier to identify the source of the problem. It is currently easy for setup.py to fail this way since it sets HGRCPTH to the empty string before running "hg", which may often disable extensions necessary to interact with the local repository.

smartset: fix generatorset.last() to not return the first element (issue5609)

strip: respect the backup option in stripcallback The backup option was mistakenly ignored. It should be respected. Thanks Martin von Zweigbergk for finding this out!

py3: use pycompat.bytestr() to convert str to bytes

py3: pass the memoryview object into bytes() to get the value

py3: use pycompat.bytestr instead of str

py3: use '%d' to convert integers to bytes

py3: slice over bytes to prevent getting it's ascii value

py3: use pycompat.strkwargs() to convert kwargs keys to str

py3: use r'' to prevent the addition of b'' by transformer There are cases in opts handling in debugcommands.py where we don't need to convert opts keys back to bytes as there are some handful cases and no other function using opts value. Using r'', we prevent the transformer to add a b'' which will keep the value str.

py3: use pycompat.byteskwargs() to convert kwargs' keys to bytes This is used where ever required like where kwargs are passed into ui.formatter(), scmutil.match() or cmdutil.openrevlog() which expects bytes.

tests: use cgienv to minimize environment setup at hgweb tests This patch follows other hgweb tests.

tests: avoid test failure for mangling path-like string by MSYS

py3: make sure commands name are bytes in tests

py3: add b'' to make the regex pattern bytes

py3: use hex() to convert the hash to bytes

py3: add b'' to make a triple quoted string bytes on Python 3 Transformer does not adds b'' in front of triple quoted strings to prevent converting docs to bytes.

py3: add tests to show `hg bookmarks` and `hg branches` work on Python 3

py3: fix kwargs handling for `hg bookmarks`

identify: provide changectx to templater

formatter: proxy fm.context() through converter Otherwise nested template formatter would not see the context objects. It's just a boolean flag now. We might want to change it to 'ctxs -> items' function so changectx attributes are populated automatically in JSON, but I'm not sure.

identify: change p1/p2 to a list of parents It makes sense because the nested data structure is a list of items.

scmutil: add a cleanupnodes method for developers It's now common that an old node gets replaced by zero or more new nodes, that could happen with amend, rebase, histedit, etc. And it's a common requirement to do bookmark movements, strip or obsolete nodes and even moving working copy parent. Previously, amend, rebase, history have their own logic doing the above. This patch is an attempt to unify them and future code. This enables new developers to be able to do "replace X with Y" thing correctly, without any knowledge about bookmarks, strip or obsstore. The next step will be migrating rebase to the new API, so it works inside a transaction, and its code could be simplified.

strip: add a delayedstrip method that works in a transaction For long, the fact that strip does not work inside a transaction and some code has to work with both obsstore and fallback to strip lead to duplicated code like: with repo.transaction(): .... if obsstore: obsstore.createmarkers(...) if not obsstore: repair.strip(...) Things get more complex when you want to call something which may call strip under the hood. Like you cannot simply write: with repo.transaction(): .... rebasemod.rebase(...) # may call "strip", so this doesn't work But you do want rebase to run inside a same transaction if possible, so the code may look like: with repo.transaction(): .... if obsstore: rebasemod.rebase(...) obsstore.createmarkers(...) if not obsstore: rebasemod.rebase(...) repair.strip(...) That's ugly and error-prone. Ideally it's possible to just write: with repo.transaction(): rebasemod.rebase(...) saferemovenodes(...) This patch is the first step towards that. It adds a "delayedstrip" method to repair.py which maintains a postclose callback in the transaction object.

workingfilectx: add audit() as a wrapper for wvfs.audit()

workingfilectx: add backgroundclose as a kwarg to write() This is necessary because some callers in merge.py pass backgroundclose=True when writing. As with previous changes in this series, this should be a no-op.

merge: change repo.wvfs.setflags calls to a new wctx[f].setflags function As with previous changes in this series, this should be a no-op.

merge: convert repo.wwrite() calls to wctx[f].write() As with the previous patch in this series, workingfilectx.write() is a direct call to repo.wwrite(), so this change should be a no-op.

merge: replace repo.wvfs.unlinkpath() with calls to wctx[f].remove() The code inside workingfilectx.remove() is a straight call to repo.wvfs.unlinkpath, so this should be a no-op.

merge: pass wctx to batchremove and batchget We would like to migrate direct calls of repo.wvfs/wwrite/wread/etc to a call on the relevant workingfilectx, both as a cleanup (to reduce the number of working copy functions on `repo`), and also to facilitate an in-memory merge that doesn't write to the working copy. In order to do that, the first step is to ensure we pass the target wctx around and perform our writes and reads on it. Later, this object might become a memctx.

revset: add depth limit to descendants() (issue5374) This is naive implementation using two-pass scanning. Tracking descendants isn't an easy problem if both start and stop depths are specified. It's impractical to remember all possible depths of each node while scanning from roots to descendants because the number of depths explodes. Instead, we could cache (min, max) depths as a good approximation and track ancestors back when needed, but that's likely to have off-by-one bug. Since this implementation appears not significantly slower, and is quite straightforward, I think it's good enough for practical use cases. The time and space complexity is O(n) ish. revisions: 0) 1-pass scanning with (min, max)-depth cache (worst-case quadratic) 1) 2-pass scanning (this version) repository: mozilla-central # descendants(0) (for reference) *) 0.430353 # descendants(0, depth=1000) 0) 0.264889 1) 0.398289 # descendants(limit(tip:0, 1, offset=10000), depth=1000) 0) 0.025478 1) 0.029099 # descendants(0, depth=2000, startdepth=1000) 0) painfully slow (due to quadratic backtracking of ancestors) 1) 1.531138

dagop: make walk direction switchable so it can track descendants # ancestors(tip) using hg repo 2) 0.068527 3) 0.069097

dagop: factor out generator of ancestor nodes # ancestors(tip) using hg repo 1) 0.068976 2) 0.068527

dagop: factor out pfunc from revancestors() generator This generator will be reused for tracking descendants with depth limit. # ancestors(tip) using hg repo 0) 0.065868 1) 0.068976

dagop: use smartset.min() in revdescendants() generator All callers pass the result of revset.getset(), which should be a smartset.

dagop: change revdescendants() to include all root revisions Prepares for adding depth support. I want to process depth=0 in revdescendants() to make things simpler. only() also calls dagop.revdescendants(), but it filters out root revisions explicitly. So this should cause no problem. # descendants(0) using hg repo 0) 0.052380 1) 0.051226 # only(tip) using hg repo 0) 0.001433 1) 0.001425

test-revset: add a few more tests of descendants() I'll add depth support to descendants().

dagop: unnest inner generator of revdescendants() This just moves iterate() to module-level function.

smartset: fix default value of abstractsmartset.sort() It's unused, but it shouldn't lie.

keyword: wrap functions only once at loading keyword extension Before this patch, some functions are wrapped in reposetup(), but this causes redundant nested wrapping, if two ore more repositories enable keyword extension (e.g. hgweb serves multiple repositories). Now, there is no need to define these wrapper functions in reposetup(), because previous patches made them not directly refer to kwtemplater instanciated in reposetup(). This patch factors these wrapper functions out from reposetup(), and uses them to wrap functions only at once at loading keyword extension.

keyword: use _keywordkwt of repository instead of kwtools['templater'] Now, kwtemplater instance can be obtained via _keywordkwt property of repository.

keyword: obtain kwtemplater instance via repository at runtime Wrapper functions of keyword extension are defined in reposetup(), because they refer to kwtemplater instantiated in reposetup(). This patch makes them obtain kwtemplater instance via repository at runtime. For reviewability, this patch focuses on wrapper functions, which handle generator. This is a part of preparations for defining them statically.

keyword: obtain kwtemplater instance via repository at runtime Wrapper functions of keyword extension are defined in reposetup(), because they refer to kwtemplater instantiated in reposetup(). This patch makes them obtain kwtemplater instance via repository at runtime. This is a part of preparations for defining them statically.

keyword: make wrapped repository and kwtemplater refer to each other Wrapper functions of keyword extension are defined in reposetup(), because they refer to kwtemplater instantiated in reposetup(). But these functions can be defined statically, if kwtemplater can be obtained via repository at runtime. This is a part of preparations for defining them statically. To avoid cyclic reference, this patch makes kwtemplater use weakref to refer related repository instance.

keyword: add test for keyword expansion at serving multiple repositories This is safety for subsequent (and future) patches, which change function wrapping.

keyword: make comparison webcommand suppress keyword expansion Before this patch, diff in "comparison" webcommand doesn't suppress keyword expansion as same as diff output of other webcommands.

keyword: restore kwtemplater.match at the end of wrapped webcommands Before this patch, kwweb_skip doesn't restore kwtemplater.match after wrapped webcommands. This suppresses keyword expansion at wrapped webcommands. Typical usecase of this issue is "file" webcommand after annotate, changeset, filediff or so on. To ensure kwtemplater.match=util.never while original webcommand running, this patch makes kwweb_skip yield values returned by it, because it returns generator object.

keyword: restore kwtemplater.restrict at the end of wrapped patch.diff Before this patch, kwdiff doesn't restore kwtemplater.restrict after invocation of wrapped patch.diff(). This suppresses keyword expansion at subsequent filelog.read(). Typical usecase of this issue is "hg cat" after "hg diff" with command server. In this case, kwtemplater.restrict=True is kept in command server process even after "hg diff". To ensure kwtemplater.restrict=True while original patch.diff() running, this patch makes kwdiff() yield values returned by it, because it returns generator object. Strictly speaking, if filelog.read() is invoked before completely evaluating the result of previous patch.diff(), keyword expansion is still suppressed, because kwtemplater.restrict isn't restored yet. But this fixing should be reasonable enough, because patch.diff() is consumed immediately, AFAIK.

debugrevlog: align chain length, reach, and compression ratio I think this is what the max(...) exists for.

configitems: register 'ui.interactive' That item default value is a bit special (None) so this adds a second proof that everything is still working fine.

config: use '_config' within 'configbytes' This will prevent bugs from using None as the sentinel value (eg: 'ui.interactive')

config: use '_config' within 'configbool' This will prevent bugs from using None as the sentinel value (eg: 'ui.interactive')

config: extract the core config logic into a private method This will make it easier for the other 'configxxx' function to detect unset value.

debugrevlog: also display the largest delta chain span Mercurial read all data between the base of the chain and the last delta when restoring content (including unrelated delta). To monitor this, we add data about the size of the "delta chain span" to debugrevlog.

rebase: clean up rebasestate from active transaction Previously, rebase assumes the following pattern: rebase: with transaction as tr: # top-level ... tr.__close__ writes rebasestate unlink('rebasestate') However it's possible that "rebase" was called inside a transaction: with transaction as tr1: rebase: with transaction as tr2: # not top-level ... tr2.__close__ does not write rebasestate unlink('rebasestate') tr1.__close__ writes rebasestate That leaves a rebasestate on disk incorrectly. This patch adds "removefilegenerator" to notify transaction code that the state file is no longer needed therefore fixes the issue.

test-rebase: add a test showing rebasestate left behind The test demonstrates that .hg/rebasestate is left behind if "rebase" was called inside an existing transaction.

identify: rename 'changed' keyword -> 'dirty' I meant to do this before sending the initial templater support, but forgot. I'm quite surprised that 'dirty' doesn't occur in more user facing contexts, but there are a few, like the help for blackbox. It also more obviously mirrors the '(clean)' state printed by the summary command. I also didn't like that it was just one letter off from {changes} in the {latesttags} sub-keywords, which has a totally different meaning.

dispatch: remove unused _loaded Now, there is no user for dispatch._loaded.

extensions: register functions always at loading extension (issue5601) Before this patch, functions defined in extensions are registered via extra loaders only in _dispatch(). Therefore, loading extensions in other code paths like below omits registration of functions. - WSGI service - operation across repositories (e.g. subrepo) - test-duplicateoptions.py, using extensions.loadall() directly To register functions always at loading new extension, this patch moves implementation for extra loading from dispatch._dispatch() to extensions.loadall(). AFAIK, only commands module causes cyclic dependency between extensions module, but this patch imports all related modules just before extra loading in loadall(), in order to centralize them. This patch makes extensions.py depend on many other modules, even though extensions.py itself doesn't. It should be avoided if possible, but I don't have any better idea. Some other places like below aren't reasonable for extra loading, IMHO. - specific function in newly added module: existing callers of extensions.loadall() should invoke it, too - hg.repository() or so: no-repo commands aren't covered by this. BTW, this patch removes _loaded.add(name) on relocation, because dispatch._loaded is used only for extraloaders (for similar reason, "exts" variable is removed, too).

identify: add template support This is based on a patch proposed last year by Mathias De Maré[1], with a few changes. - Tags and bookmarks are now formatted lists, for more flexible queries. - The templater is populated whether or not [-nibtB] is specified. (Plain output is unchanged.) This seems more consistent with other templated commands. - The 'id' property is a string, instead of a list. - The parents of 'wdir()' have their own list of attributes. I left 'id' as a string because it seems very useful for generating version info. It's also a bit strange because the value and meaning changes depending on whether or not --debug is passed (short vs full hash), whether the revision is a merge or not (one hash or two, separated by a '+'), the working directory or not (node vs p1node), and local or not (remote defaults to tip, and never has '+'). The equivalent string built with {rev} seems much less useful, and I couldn't think of a reasonable name, so I left it out. The discussion seemed to be pointing towards having a list of nodes, with more than one entry for a merge. It seems simpler to give the nodes a name, and use {node} for the actual commit probed, especially now that there is a virtual node for 'wdir()'. Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes. I'm not sure if the plan is to fill in all of the context attributes in these items, or if these nested items should simply be made {p1node} and {p1rev}. I used ':' as the tag separator for consistency with {tags} in the log templater. Likewise, bookmarks are separated by a space for consistency with the corresponding log template. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html

show: show all namespaces in "work" view This commit addresses a number of deficiencies in `hg show work`'s output: * Failure to render tags (it just wasn't implemented) * Failure to render names associated with non-built-in namespaces (e.g. remotenames) * Color names were hardcoded instead of coming from the canonical source in the namespace This change has the intended effect of rendering tags and extra namespaces. It solves an immediate need at Mozilla of having names from a custom namespace printed, which is blocking us from switching from a custom `hg wip` revset/template combo to `hg show work`. Note that the order of branches and bookmarks changes. This is because bookmarks are registered before branches in namespaces.py. We may want to register them last, after tags and branches. Or we may want to added a weighted field to the namespace to control display order. Something to think about. I'm not a big fan of the complexity in the templating layer. There is a lot of code to basically filter out the special case of branch=='default' and tag=='tip'. Ideally, we would iterate over a data structure that had irrelevant/unwanted names pre-filtered. However, I wasn't sure how to best implement this. We probably want {namespaces} to emit everything (its current behavior). I was toying with the following: * {namespacesnondefaults} variation that filtered values * A filter function that operated on {namespaces} (I wasn't sure how to implement this since the filtering layer would see a "hybrid" instance as opposed to something that was definitely an iterable of namespaces.) * A namespaces(...) function where you could specify which values to return. I like this the most. But it really wants named arguments to control filtering and we only support named arguments on revsets, not templates. I figure perfect is the enemy of good and we can refine templating support for namespaces in the future. At least now we have a concrete example of a use case.

tests: add more tests for names rendering in `hg show work` This demonstrates some missing features. This will also help verify that a subsequent change has the intended effect.

namespaces: record and expose whether namespace is built-in Currently, the templating layer tends to treat each namespace as a one-off, with explicit usage of {bookmarks}, {tags}, {branch}, etc instead of using {namespaces}. It would be really useful if we could iterate over namespaces and operate on them generically. However, some consumers may wish to differentiate namespaces by whether they are built-in to core Mercurial or provided by extensions. Expected use cases include ignoring non-built-in namespaces or emitting a generic label for non-built-in namespaces. This commit introduces an attribute on namespace instances that says whether the namespace is "built-in" and then exposes this to the templating layer. As part of this, we implement a reusable extension for defining custom names on each changeset for testing. A second consumer will be introduced in a subsequent commit.

templatekw: expose color name in {namespaces} entries Templates make use of a "log.<namespace>" label. The <namespace> value here differs from the actual namespace name in that the namespace itself is plural but the label/color value is singular. Expose the color name to the templating layer so log.* labels can be emitted for {namespaces}. As part of this, we refactored the logic to eliminate a gnarly comprehension. We store color names in their own dict because the lookup can occur in tight loops and we shouldn't have to go to repo.names[ns] multiple times for every changeset.

show: construct changeset templater during dispatch Previously, we constructed a formatter from a specific template topic. Then from show() we reached into the internals of the formatter to resolve a template string to be used to construct a changeset templater. A downside to this approach was it limited us to having the entire template defined in a single entry in the map file. You couldn't reference other entries in the map file and this would lead to long templates and redundancy in the map file. This commit teaches @showview how to instantiate a changeset templater so we can construct a templater with full access to the map file. To prove it works, we've split "showwork" into components.

cmdutil: use named arguments for changeset_templater.__init__ This will make the API more extensible and easier to use.

bundle: inline applybundle1() We have now gotten rid of all but one caller, so let's inline it there.

bundle: make applybundle() delegate v1 bundles to applybundle1()

bundle: transpose transaction scope with bundle type switch This moves the transaction with-statements outside of the per-bundle-version switches, so the next patch will be a little simpler.

unbundle: move BundleUnknownFeatureError exception handling out This just moves the BundleUnknownFeatureError exception handling one level up so we collect the bundle2.applybundle{,1}() calls together. applybundle1() will never throw the exception, so it should have no functional consequence.

bundle: make applybundle1() return a bundleoperation See previous commit for motivation. It already lets us share a little bit more code in commands.py.

bundle: add a applybundle1() method This is one step towards removing a bunch of "if isinstance(gen, unbundle20)" by treating bundle1 and bundle2 more similarly. The name may sounds ironic for a method in the bundle2 module, but I didn't think it was worth it yet to create a new 'bundle' module that depends on the 'bundle2' module. Besides, we'll inline the method again later.

bundle: extract _processchangegroup() method The new method applies the changegroup and fills in op.records, sharing a little bit of code between the two callers. We'll add another caller soon.

bundle: make combinechangegroupresults() take a bundleoperation Both callers have a bundleoperation. Passing it in lets us share a bit more code.

bundle: move combineresults() from changegroup to bundle2 The results only need to be combined if they come from a bundle2. More importantly, we'll change its argument to a bundleoperation soon, and then it definitely will no longer belong in changegroup.py.

bundle: remove 'op' argument from applybundle() No callers pass in an operation.

test-rebase-conflicts: add a test case about turning obsstore on and off Turning obsstore and allowunstable on, rebase will skip the "can't remove original changesets with unrebased descendants" check. Then rebase could be interrupted (merge conflict), and the user has a chance to turn off obsstore. If rebase continues, the current code may strip irrelevant commits (in the test case added, "C" got stripped unexpectedly). The test case reproduces issue5606. It will be fixed by the "multidest" rebase refactoring being reviewed. The test case itself is relatively separate from the rebase refactoring, therefore sent separately hoping to reduce the number of patches of the main rebase series.

merge with stable

strip: include phases in bundle (BC) Before this patch, unbundling a stripped changeset would make it a draft (unless the parent was secret). This meant that one would lose phase information when stripping and unbundling secret changesets. The same thing was true for public changesets. While stripping public changesets is generally rare, it's done frequently by e.g. the narrowhg extension. We also include the phases in the temporary bundle, just in case stripping were to fail after that point, so the user can still restore the repo including phase information. Before this patch, the phases were left untouched during the bundling and unbundling of the temporary bundle. Only at the end of the transaction would phasecache.filterunknown() be called to remove phase roots that were no longer valid. We now need to call that also after the first stripping, i.e. before applying the temporary bundle. Otherwise unbundling the temporary bundle will cause a read of the phase cache which has stripped changesets in the cache and that fails. Like with obsmarkers, we unconditionally include the phases in the bundle when stripping (when using bundle2, such as when generaldelta is enabled). The reason for doing that for strip but not for bundle is that strip bundles are not meant to be shared outside the repo, so we don't care as much about compatibility.

bundle: add config option to include phases This adds an experimental.bundle-phases config option to include phase information in bundles. As with the recently added support for bundling obsmarkers, the support for bundling phases is hidden behind the config option until we decide to make a bundlespec v3 that includes phases (and obsmarkers and ...). We could perhaps use the listkeys format for this, but that's considered obsolete according to Pierre-Yves. Instead, we introduce a new "phase-heads" bundle part. The new part contains the phase heads among the set of bundled revisions. It does not include those in secret phase; any head in the bundle that is not mentioned in the phase-heads part is assumed to be secret. As a special case, an empty phase-heads part thus means that any changesets should be added in secret phase. (If we ever add a fourth phase, we'll include secret in the part and we'll add a version number.) For now, phases are only included by "hg bundle", and not by e.g. strip and rebase.

bundle2: record changegroup data in 'op.records' (API) When adding support for bundling and unbundling phases, it will be useful to have the list of added changesets. To do that, we return the list from changegroup.apply().

debugcommands: pass part, not read data, into _debugobsmarker() This matches how it's done for _debugchangegroup() and how we will soon do it for _debugphaseheads().

debugcommands: remove unused "all" argument from _debugobsmarkers

dagop: raise ProgrammingError if stopdepth < 0 revset.py should never send such a value.

make: add Debian 9 (Stretch) docker target

make: templatize Debian build target a la e63dfbbdbd07

make: add Ubuntu Zesty docker targets (.deb and ppa) Zesty Zapus was released on 2017-04-13 and will be supported until 2018-01.

docker: install less as a build-time dependency in deb-based distros It's needed since 387a76cac28e, otherwise dpkg-checkbuilddeps errors out.

py3: add utility to forward __str__() to __bytes__() It calls unifromlocal() instead of sysstr() because __bytes__() may contain locale-dependent values such as paths.

share: use dict literal instead of dict(key=value) check-code.py has the rule, but it isn't smart enough to catch this.

py3: use r'' to prevent conversion to bytes by transformer

py3: define __bytes__ for basefilectx class The implementation is shamely copied from the __str__ function

py3: check for bytes instead of str in isinstance

py3: convert kwargs' keys' to str using pycompat.strkwargs() On Python 3, we must have keys of keyword arguments as str.

py3: convert kwargs keys' back to bytes using pycompat.byteskwargs()

py3: use "%d" % val for int rather than pycompat.bytestr Earlier I used pycompat.bytestr() to convert integers to bytes, but we can do b"%d" % val to convert that int to bytes. b'' is already added by the transformer. Thanks to Yuya for suggesting this.

extensions: call afterloaded() with loaded=False for disabled extensions If an extension was loaded but disabled due to a minimumhgversion check it will be present in the _extensions map, but set to None. The rest of the extensions code treats the extension as if it were not present in this case, but the afterloaded() function called the callback with loaded=True.

fetch: remove shorthand of --edit colliding against -e/-ssh in remoteopts (BC) Before this patch, -e/--edit and -e/--ssh of fetch command collide against each other. This causes that -e is treated as shorthand of --edit but doesn't work as same as --edit. Therefore, -e works as neither --edit nor --ssh, in practice. This issue was introduced at 595a69a01129 (or 1.0), which renamed -f/--force-editor to -e/--edit. At that point, -e was already used as shorthand of --ssh. After this patch, -e is treated as shorthand of --ssh. This patch is marked as "(BC)", because -e as shorthand of --edit in existing scripts causes failure (or unexpected result) after this patch. This impact should be less enough, because --edit mainly focuses on interactive use. BTW, test-duplicateoptions.py (since 7d171c05a631 or 1.9) can't detect this kind of issues as expected, because direct invocation of extensions.loadall() doesn't involve registration of commands defined in extensions (this issue is fixed in subsequent patch).

releasenotes: improve parsing around bullet points Earlier, on parsing the bullet points from existing release notes the bullet points after the first one weren't written correctly to the notes file. This patch makes changes to parsereleasenotesfromfile() function that introduces a new bullet_points data structure that tracks the bullets and associated subparagraph. It also makes necessary changes to the tests related to merging of bullets.

bookmarks: factor method _printer out of for loop in printbookmarks This allows even further customization via extensions for printing bookmarks. For example, in hg-git this would allow printing remote refs by just modifying the 'bmarks' parameter instead of reimplementing the old commands.bookmarks method. Furthermore, there is another benefit: now multiple extensions can chain their custom data to bookmark printing. Previously, an extension could have conflicting bookmark output due to which loaded first and overrode commands.bookmarks. Now they can all play nicely together.

bookmarks: factor out bookmark printing from commands

commands: move activebookmarklabel to bookmarks module This is going to be used in an upcoming patch that moves more methods to bookmarks.py.

commands: replace locking code with a context manager Note that this means that we're unnecessarily creating a transaction in the pure "--inactive" (i.e. when deactivating the current bookmark), but that should be harmless.

bookmarks: factor out adding a list of bookmarks logic from commands We keep the lock in the caller so that future devs are aware of the locking implications.

bookmarks: factor out rename logic from commands We keep the lock in the caller so that future devs are aware of the locking implications.

bookmarks: factor out delete logic from commands We keep the lock in the caller so that future devs are aware of the locking implications.

merge with stable

revset: add startdepth limit to ancestors() as internal option This is necessary to implement the set{gen} (set subscript) operator. For example, set{-n} will be translated to ancestors(set, depth=n, startdepth=n). https://www.mercurial-scm.org/wiki/RevsetOperatorPlan#ideas_from_mpm The UI is undecided and I doubt if the startdepth option would be actually useful, so the option is hidden for now. 'depth' could be extended to take min:max range, in which case, integer depth should select a single generation. ancestors(set, depth=:y) # scan up to y-th generation ancestors(set, depth=x:) # skip until (x-1)-th generation ancestors(set, depth=x) # select only x-th generation Any ideas are welcomed. # reverse(ancestors(tip)) using hg repo 3) 0.075951 4) 0.076175

revset: add depth limit to ancestors() This is proposed by the issue5374, and will be a building block of set{gen} (set subscript) operator. https://www.mercurial-scm.org/wiki/RevsetOperatorPlan#ideas_from_mpm # reverse(ancestors(tip)) using hg repo 2) 0.075408 3) 0.075951

dagop: compute depth in revancestors() generator Surprisingly, this makes revset benchmark slightly faster. I don't know why, but it appears that wrapping -inputrev by tuple is the key. So I decided to just enable depth computation by default. # reverse(ancestors(tip)) using hg repo 1) 0.081051 2) 0.075408

dagop: just compare with the last value to deduplicate input of revancestors() Since we're using a max heap, the current rev should be a duplicate only if it equals to the previous one. We don't have to maintain the whole seen set. # reverse(ancestors(tip)) using hg repo 0) 0.086420 1) 0.081051

dagop: bulk rename variables in revancestors() generator - h -> pendingheap: "h" seems too short for variable of long lifetime - current -> currev: future patches will add current "depth" variable - parent -> prev or pctx: short lifetime, follows common naming rules

dagop: comment why revancestors() doesn't heapify input revs at once I wondered why we're doing this complicated stuff without noticing the input revs may be iterated lazily in descending order. c1f666e27345 showed why.

dagop: unnest inner generator of revancestors() This just moves iterate() to module-level function.

hgweb: plug followlines action in annotate view Add the followlines.js script and corresponding parameters as data attribute on <tbody class="sourcelines"> element. Extend CSS rules so that they also match the DOM structure of annotate view. As previously, only address paper and gitweb styles (other styles do not have followlines at all).

hgweb: parameterize the tag name of elements holding followlines selection While plugging followlines.js into "annotate" view, we'll need to walk a different DOM structure from that of "filerevision" view. In particular, the selectable source line element is a <tr> in annotate view (in contrast with a <span> in filerevision view). So make this tag name a parameter of followlines.js script by passing its value as a "selectabletag" data attribute of <pre class="sourcelines"> element. As <pre class="sourcelines"> tags are getting quite long in templates, rewrite them on several lines.

gitweb: wrap table rows of annotate view into a <tbody> element We will use this element to hook data attribute for the followlines.js script to be plugged in annotate view. Also this gets symmetrical with paper style which already has a <tbody> element.

tests: update regex check for fetch error in test-clonebundles.t On some systems, e.g. Docker container, the actual error may be: error fetching bundle: [Errno 99] Cannot assign requested address Update the regex to handle this case.

hgweb: use separate CSS class for navigation links in footer 2d93d2159e30 changed the styling of the "page_nav" CSS class to use flexbox to separate elements within the <div>. I didn't realize that this class was used outside of the links in the header. So this resulted in incorrectly formatting links in the footer of various pages. Fix that by introducing a new CSS class that preserves the old CSS behavior.

configitems: register 'ui.clonebundleprefers' as example for 'configlist' This exercise the default value handling in 'configlist'.

configitems: register 'patch.fuzz' as first example for 'configint' This exercise the default value handling in 'configint'.

configitems: issue a devel warning when overriding default config If the option is registered, there is already a default value available and passing a new one is at best redundant. So we issue a deprecation warning in this case. (note: there will be case were the default value will not be as simple as what is currently possible. We'll upgrade the configitems code to handle them in time.)

eol: fix 'error' parameter name in the commitctx wrapper Since its introduction in 9dfee83c93c8, the parameter has always been name "error". Yet the eol extension have been using 'haserror' as the argument name, breaking extensions with subclass passing 'error' as a keyword argument.

eol: import 'error' as 'errormod' We need the 'error' name available to fix another bug, so we rename the imported module.

configitems: register 'ui.quiet' as first example We now have a user and this works fine.

configitems: get default values from the central registry when available We do not have any registered config yet, but we are now ready to use them. For now we ignore this feature for config access with "alternates". On the long run, we expect alternates to be handled as "aliases" by the config item themself.

configitems: introduce a central registry for config option We now have the appropriate infrastructure to register config items. Usage will added in the next changeset.

configitems: add a basic class to hold config item information The goal of this class is allow explicit declaration for the available config option. This class will hold the data for one specific config item. To keep it simple we start centralizing the handling of the default config value. In the future we can expect more data to be carried on this class. For example: - documentation, - status (experimental, advanced, normal, deprecated), - aliases, - expected type, - etc...

run-tests: fix -i when "#testcases" is used in .t test The "#testcases" feature introduced by 7340465bd788 has issues with "-i" because "-i" uses "test.name.endswith('.t')" to test if a test is .t or not. test.name could now be something like "test-foo.t (caseA)" so the above endswith test is no longer valid. This patch changes the test to use "self.path" which won't have the issue.

run-tests: update .t reference output after reading the test The .t file is both test input and reference output. They should always match. However we have different code paths to read reference output (Test.__init__ -> Test.readrefout) and test input (TTest._run) so they might be inconsistent if somethings change the file between those two functions. This patch assigns "lines" read by "_run" back to "_refout" if "_refout" is not None (with --debug, see Test.readrefout) so reference output and test input will always match.

run-tests: do not prompt changes (-i) if a race condition is detected The race condition is like: 1. run-tests.py reads test-a.t as reference output, content A 2. run-tests.py runs the test (which could be content B, another race condition fixed by the next patch, but assume it's content A here) 3. something changes test-a.t to content C 4. run-tests.py compares test output (content D) with content A 5. with "-i", run-tests.py prompts diff(A, D), while the file has content C instead of A at this time This patch detects the above case and tell the user to rerun the test if they want to apply test changes.

patch: rewrite reversehunks (issue5337) The old reversehunks code accesses "crecord.uihunk._hunk", which is the raw recordhunk without crecord selection information, therefore "revert -i" cannot revert individual lines, aka. issue5337. The patch rewrites related logic to return the right reverse hunk for revert. Namely, 1. "fromline" and "toline" are correctly swapped [1] 2. crecord.uihunk generates a correct reverse hunk [2] Besides, reversehunks(hunks) will no longer modify its input "hunks", which is more expected. [1]: To explain why "fromline" and "toline" need to be swapped, take the following example: $ cat > a <<EOF > 1 > 2 > 3 > 4 > EOF $ cat > b <<EOF > 2 > 3 > 5 > EOF $ diff a b 1d0 <---- "1" is "fromline" and "0" is "toline" < 1 and they are swapped if diff from the reversed direction 4c3 | < 4 | --- | > 5 | | $ diff b a | 0a1 <---------+ > 1 3c4 <---- also "4c3" gets swapped to "3c4" < 5 --- > 4 [2]: This is a bit tricky. For example, given a file which is empty in working parent but has 3 lines in working copy, and the user selection: select hunk to discard [x] +1 [ ] +2 [x] +3 The user intent is to drop "1" and "3" in working copy but keep "2", so the reverse patch would be something like: -1 2 (2 is a "context line") -3 We cannot just take all selected lines and swap "-" and "+", which will be: -1 -3 That patch won't apply because of "2". So the correct way is to insert "2" as a "context line" by inserting it first then deleting it: -2 +2 Therefore, the correct revert patch is: -1 -2 +2 -3 It could be reordered to look more like a common diff hunk: -1 -2 -3 +2 Note: It's possible to return multiple hunks so there won't be lines like "-2", "+2". But the current implementation is much simpler. For deletions, like the working parent has "1\n2\n3\n" and it was changed to empty in working copy: select hunk to discard [x] -1 [ ] -2 [x] -3 The user intent is to drop the deletion of 1 and 3 (in other words, keep those lines), but still delete "2". The reverse patch is meant to be applied to working copy which is empty. So the patch would be: +1 +3 That is to say, there is no need to special handle the unselected "2" like the above insertion case.

profiling: cope with configwith default value handling changes Changeset 6ff6eb33f353 change 'configwith' behavior so that the default value is run through the conversion function. In parallel a new user of 'configwith' got introduced unaware of this coming behavior change. This broke profiling. We resolve the situation by having the new conversion function cope with a default value already using the right type.

py3: catch StopIteration from next() in generatorset IIUC, letting the StopIteration through would not cause any bugs, but not doing it makes the test-py3-commands.t pass. I have also diligently gone through all uses of next() in our code base. They either: * are not called from a generator * pass a default value to next() * catch StopException * work on infinite iterators * request a fixed number of items that matches the generated number * are about batching in wireproto which I didn't quite follow I'd appreciate if Augie or someone else could take a look at the wireproto batching and convince themselves that the next(batchable) calls there will not raise a StopIteration.

tests: adjust quoting to keep Windows happy with recent $PYTHON change I tried adding quotes to the $PYTHON variable, and also tried converting the path from the current 'c:/Python/python.exe' form to '/c/python/python.exe', but neither worked. I'm not sure why one of these needs '\"' around the variable and the other doesn't.

bundle2: don't use debug message "no-transaction" with transaction

py3: use pycompat.bytestr() in place of str()

py3: use r'' to access values from kwargs where keys are str These are the cases where either args is again passed as keyword argument or 1 or 2 elements are accessed. So it's better to add an r'' to prevent it converting to bytes rather than doing the conversion of args.

py3: convert keys of kwargs in template keywords functions to bytes This patch converts the args argument keys' to bytes wherever necessary as there are some places where either args is not used or using r'' is better or args is again passed as keyword arguments.

py3: make sure the commands name are bytes in test-devel-warnings.t

py3: replace str with bytes in isinstance() We were using str because on Python 2, str were bytes but now we have to use bytes. Otherwise the if conditions fails and we have weird results from commands on Python 3.

py3: catch binascii.Error raised from binascii.unhexlify Before Python 3, binsacii.unhexlify used to raise TypeError, now it raises binascii.Error.

shelve: allow unlimited shelved changes per name Previously, there is a 100 changes limit per name (bookmark or named branch). And the user will get "too many shelved changes named %s" when they are trying to shelve the 101th change. I hit that error message today. This limit was introduced by the shelve extension since the beginning. The function generating the names was called "gennames", under "getshelvename". There is another "gennames" under "backupfilename": def backupfilename(self): def gennames(base): yield base base, ext = base.rsplit('.', 1) for i in itertools.count(1): yield '%s-%d.%s' % (base, i, ext) "itertools.count" is an endless counter. Since the other "gennames" generates unlimited number of names, and the changeset introducing the limit (49d4919d21) does not say why the limit is useful. It seems safe to just remove the limit. The format "%02d" was kept intentionally so existing shelved changes won't break.

config: use the new '_unset' value for 'configsuboptions' This should let configsuboptions delegate all special processing of the default config value to the main 'config' method.

config: use the 'config' method in 'configsuboptions' There was unnecessary code duplication. It was getting in the way of the unification of the default value logic.

config: use the new '_unset' value for 'configpath' This should let 'configpath' delegate all special processing of the default config value to the main 'config' method.

config: use the new '_unset' value for 'configdate' This should let 'configdate' delegate all special processing of the default config value to the main 'config' method. The default value for date (None) is still enforced in this method if no other default were passed.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

changeset_templater: backport parts map of [templates] section from formatter

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.

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.)

formatter: add support for separator template This seems useful for writing JSON template.

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.

formatter: extract helper function to render template

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.

changeset_templater: simplify handling of verbosity postfix

merge with stable

tests: don't touch the network when using virtualenv

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.

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.

contrib: add check-code rule to enforce non-use of `python` in tests

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.

tests: enforce use of $PYTHON in tests

tests: use $PYTHON in #! so we always use the right Python

tests: sed away python #! in test-run-tests.t to avoid some upcoming insanity

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.

keyword: use context manager for rollback locking

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.

tests: remove unused IgnoreTest exception AFAICT its last use was removed in d839e4820da7.

tests: use unittest.SkipTest unittest.SkipTest was introduced in Python 2.7. We previously defined it with our own class so we could run on Python 2.6.

changegroup: delete "if True" and reflow

changegroup: let callers pass in transaction to apply() (API) I think passing in the transaction makes it a little clearer and more consistent with bundle2.

repair: create transaction for bundle1 unbundling earlier See earlier patch for motivation.

unbundle: create transaction for bundle1 unbundling earlier See earlier patch for motivation.

exchange: create transaction for bundle1 unbundling earlier changegroup.apply() currently creates a transation if there isn't already one. Having the callers of that method pass in an existing transaction seems a little cleaner. To do that, we need to make sure all callers have a transaction. Since the transaction name is used as a hook argument (HG_TXNNAME), we need to match the name from changegroup.apply().

changegroup: inline 'publishing' variable in apply()

repair: remove unnecessary locking for bookmarks The caller has already locked the repo.