merge with stable

revlog: move part of "addrevision" to "addrawrevision" "addrawrevision" will be the public API to reuse revision rawdata elsewhere. It will be used by a future patch.

filectx: add an overlayfilectx class The end goal is to make it possible to avoid potential expensive fctx.data() when unnecessary. While memctx is useful for creating new file contexts, there are many cases where we could reuse an existing raw file revision (amend, histedit, rebase, process a revision constructed by a remote peer, etc). The overlayfilectx class is made to support such reuse cases. Together with a later patch, hash calculation and expensive flag processor could be avoided.

filectx: remove __new__ It does not seem to be used anywhere, and breaks a later patch.

filectx: add a rawflags method The new method returns the low-level revlog flag. We already have "rawdata" so a "rawflags" makes sense. Both "rawflags" and "rawdata" will be used in a later patch.

filectx: move size to basefilectx See previous patch for context - avoid code duplication.

filectx: make renamed a property cache See previous patch for context - mainly to avoid code duplication.

filectx: make flags a property cache Make basefilectx._flags a property cache, so basefilectx.flags() could be reasonably reused. This avoids code duplication between memfilectx and a class added in a later patch.

commandserver: move printbanner logic to bindsocket bindsocket now handles listen automatically. "printbanner" seems to be just a part of "bindsocket". This simplifies the interface a bit.

commandserver: move "listen" responsibility from service to handler This enables chg to replace a server socket in an atomic way: 1. bind to a temp address 2. listen 3. rename Currently 3 happens before 2 so a client may see the socket file but fails to connect to it.

hghave: remove py27+ capability It is now unused. And we require Python 2.7+ now so this check is not necessary.

tests: remove test targeting Python 2.6 We just removed support for Python 2.7. This test is dead since it only ran on <2.7.

setup: drop support for Python 2.6 (BC) Per discussion on the mailing list and elsewhere, we've decided that Python 2.6 is too old to continue supporting. We keep accumulating hacks/fixes/workarounds for 2.6 and this is taking time away from more important work. So with this patch, we officially drop support for Python 2.6 and require Python 2.7 to run Mercurial.

perf: move revlog construction and length calculation out of benchmark We don't need to measure the time it takes to open the revlog or calculate its length. This is more consistent with what other perf* functions do. While I was here, I also renamed the revlog variable from "r" to "rl" - again in the name of consistency.

perf: clear revlog caches on every iteration cmdutil.openrevlog() may return a cached revlog instance. This /may/ be a recent "regression" due to refactoring of the manifest API. I'm not sure. Either way, this perf command was broken for at least manifests because subsequent invocations of the perf function would get cache hits from previous invocations, invalidating results. In the extreme case, testing the last revision in the revlog resulted in near-instantanous execution of subsequent runs (since the fulltext is cached). A time of ~1us would be reported in this case.

perf: don't convert rev to node before calling revlog.revision()

revlog: rename _chunkraw to _getsegmentforrevs() This completes our rename of internal revlog methods to distinguish between low-level raw revlog data "segments" and higher-level, per-revision "chunks." perf.py has been updated to consult both names so it will work against older Mercurial versions.

perf: store reference to revlog._chunkraw in a local variable To prepare for renaming revlog._chunkraw, we stuff a reference to this metho in a local variable. This does 2 things. First, it moves the attribute lookup outside of a loop, which more accurately measures the time of the code being invoked. Second, it allows us to alias to different methods depending on their presence (perf.py needs to support running against old Mercurial versions). Removing an attribute lookup from a tigh loop appears to shift the numbers slightly with mozilla-central: $ hg perfrevlogchunks -c ! read ! wall 0.354789 comb 0.340000 user 0.330000 sys 0.010000 (best of 28) ! wall 0.335932 comb 0.330000 user 0.290000 sys 0.040000 (best of 30) ! read w/ reused fd ! wall 0.342326 comb 0.340000 user 0.320000 sys 0.020000 (best of 29) ! wall 0.332857 comb 0.340000 user 0.290000 sys 0.050000 (best of 30) ! read batch ! wall 0.023623 comb 0.020000 user 0.000000 sys 0.020000 (best of 124) ! wall 0.023666 comb 0.020000 user 0.000000 sys 0.020000 (best of 125) ! read batch w/ reused fd ! wall 0.023828 comb 0.020000 user 0.000000 sys 0.020000 (best of 124) ! wall 0.023556 comb 0.020000 user 0.000000 sys 0.020000 (best of 126)

revlog: rename internal functions containing "chunk" to use "segment" Currently, "chunk" is overloaded in revlog terminology to mean multiple things. One of them refers to a segment of raw data from the revlog. This commit renames various methods only used within revlog.py to have "segment" in their name instead of "chunk." While I was here, I also made the names more descriptive. e.g. "_loadchunk()" becomes "_readsegment()" because it actually does I/O.

fsmonitor: do not nuke dirstate filecache In the future, chg may prefill repo's dirstate filecache so it's valuable and should be kept. Previously we drop both filecache and property cache for dirstate during fsmonitor reposetup, this patch changes it to only drop property cache but keep the filecache.

perf: move gettimer() call This is more consistent with other perf* functions.

perf: don't clobber startrev variable Previously, the "startrev" argument would be ignored due to "startrev = 0" in the benchmark function. This meant that `hg perfrevlog` always started at revision 0. Rename the local variable to "beginrev" so the variable does the right thing.

bundle: add optional 'tagsfnodecache' data to on disk bundle (issue5543) This should help performance when unbundling.

bundle2: move tagsfnodecache generation in a generic function This will help us reusing the logic for `hg bundle`.

bundle: introduce an higher level function to write bundle on disk The current function ('writebundle') is focussing on getting an existing changegroup to disk. It is no easy ways to includes more part in the generated bundle2. So we introduce a slightly higher level function that is fed the 'outgoing' object (that defines the bundled spec) and the bundlespec parameters (to control the changegroup generation and inclusion of other parts). This is creating the third logic dedicated to create a consistent bundle2 (the other 2 are the push code and the getbundle code). We should probably reconcile them at some points but they all takes different types of input. So we need to introduce an intermediate "object" that each different input could be converted to. Such unified "bundle2 specification" could be fed to some unified code. We start by having the `hg bundle` related code on its own to helps defines its specific needs first. Once the common and specific parts of each logic will be known we can start unification.

bundle: handle compression earlier We can also handle that part before starting any generation.

bundle: check changegroup version earlier We can check if we know how to bundle this changegroup version before actually starting to generate the changegroup.

bundle: check lack of revs to bundle before generating the changegroup We already have the information so we can check it earlier.

extdiff: copy back files to the working directory if the size changed In theory, it should be enough to pay attention only to the modification time when detecting if a snapshotted working directory file changed. In practice, BeyondCompare preserves all file attributes when syncing files at the directory level. (If you open the file and sync individual hunks, then mtime does change, and everything was being copied back as desired.) I'm not sure how many other synchronization tools would trigger this issue, but it's annoyingly inconsistent (if a single file is diffed, it isn't snapshotted, so the same BeyondCompare file sync operation _is_ visible, because wdir() is updated in place. I filed a bug with them, and they stated it is on their wish list, but won't be fixed in the near term. This isn't a complete fix (there is still the case of the size not changing), but this seems like a trivial enough change to fix most of the problem. I suppose we could fool around with making files in the other snapshot readonly, and copy back if we see the readonly bit copied. That seems pretty hacky though, and only works if the external tool copies all attributes.

test-extdiff: enable a previously failing test on Windows

test-extdiff: narrow the range of an '#if execbit' block Now that output can be conditionalized, the few `chmod +x` specific outputs can be conditionalized, and the rest of the tests run as normal. Disable one test that is failing on Windows for now.

test-extdiff: deduplicate tests

test-extdiff: fill in a missing Windows test

policy: eliminate ".pure." from module name only if marked as dual So we can switch cext/pure modules to new layout one by one.

policy: add "cext" package which will host CPython extension modules I'm going to restructure cext/pure modules and get rid of our hgimporter hack. C extension modules will be moved to cext/ directory so old and new compiled modules can coexist in development tree. This is necessary to run 'hg bisect' without recompiling. New extension modules will be loaded by an importer function: base85 = policy.importmod('base85') # select pure.base85 or cext.base85 This will also allow us to split cffi from pure modules, which is currently difficult because pure modules can't be imported by name.

policy: mark all string literals as sysstr or bytes The policy module won't be imported early in future, which means string literals will be processed by our Python 3 loader.

debuginstall: check C extensions only if they are loadable per policy This check is useless in pure installation and I want to make it directly import C extension modules.

osutil: proxy through util (and platform) modules (API) See the previous commit for why. Marked as API change since osutil.listdir() seems widely used in third-party extensions. The win32mbcs extension is updated to wrap both util. and windows. aliases.

mpatch: proxy through mdiff module See the previous commit for why.

bdiff: proxy through mdiff module See the previous commit for why. mdiff seems a good place to host bdiff functions. bdiff.bdiff was already aliased as textdiff, so we use it.

base85: proxy through util module I'm going to replace hgimporter with a simpler import function, so we can access to pure/cext modules by name: # util.py base85 = policy.importmod('base85') # select pure.base85 or cext.base85 # cffi/base85.py from ..pure.base85 import * # may re-export pure.base85 functions This means we'll have to use policy.importmod() function in place of the standard import statement, but we wouldn't want to write it every place where C extension modules are used. So this patch makes util host base85 functions.

mdiff: move re-exports to top This style seems more common in our codebase.

test-commit-interactive-curses: remove unused import of parsers

strip: make tree stripping O(changes) instead of O(repo) The old tree stripping logic iterated over every tree revlog in the repo looking for commits that had revs to be stripped. That's very inefficient in large repos. Instead, let's look at what files are touched by the strip and only inspect those revlogs. I don't have actual perf numbers, since internally we don't use a true treemanifest, but simply iterating over hundreds of thousands of revlogs takes many, many seconds, so this should help tremendously when stripping only a few commits.

strip: move tree strip logic to it's own function This will allow external extensions to modify tree strip behavior more precisely.

manifest: remove unused property _oldmanifest The last use seems to have gone away in 7c7d845f8b64 (manifest: make manifestlog use it's own cache, 2016-11-10).

py3: convert key to str to make kwargs.pop work in mq The keys are passed here and there as unicodes and our transformer make things bytes. Due to that, mq was not poped and this results in error on Py3. Here we abuse r'' to make that str on Python 3.

py3: convert kwargs' keys to str before passing in cmdutil.getcommiteditor

diff: add a fast path to avoid loading binary contents When diffing binary contents, with certain configs, we can show "Binary file <name> has changed" without actual content. That allows a fast path where we could avoid providing actual binary contents. Note: in that case we still need to test if two contents are the same, that's done by using "filectx.cmp", which could have its own fast path.

diff: correct binary testing logic This seems to be more correct given the table drawn in the previous patch. Namely, "losedatafn" and "opts.git" are removed, "not opts.text" is added. - losedatafn: diff output (binary) should not be affected by "losedatafn" - opts.git: binary testing is helpful for detecting a fast path in the next path. the fast path can also be used if opts.git is False - opts.text: if it's set, we should treat the content as non-binary

diff: draw a table about binary diff behaviors The table should make it easier to reason about future changes.

diff: use fctx.size() to test empty fctx.size() could have a fast path that does not require loading content.

diff: use fctx.isbinary() to test binary The end goal is to avoid calling fctx.data() when unnecessary. For example, if diff.nobinary=1 and files are binary, the expected behavior is to print "Binary file has changed". That could avoid reading fctx.data() sometimes. This is mainly to enable an external LFS extension to skip expensive binary file loading sometimes (read: most of the time with diff.nobinary=1 and diff.text=0), without any behavior changes to mercurial (i.e. whether a file is LFS or not does not change any behavior, LFS could be 100% transparent to users).

pycompat: extract helper to raise exception with traceback It uses "raise excobj, None, tb" form which I think is simpler and more useful than "raise exctype, args, tb".

check-code: ignore re-exports of os.environ in encoding.py These are valid uses of os.environ.

check-code: exclude demandimport.py and policy.py from Python 3 checks These modules can't depend on pycompat.py, which means we have to write Py3 hacks in them.

check-code: rewrite py3 exclusion pattern with negative lookahead I want to add more patterns, but negative lookbehind requires patterns of the same length so not useful.

cleanup: remove useless re-raises of KeyboardInterrupt KeyboardInterrupt is no longer a subclass of Exception since Python 2.5. https://docs.python.org/2/whatsnew/2.5.html#pep-352-exceptions-as-new-style-classes

make: drop deprecated rule to process temporary copy of pure modules Pure modules never be copied to mercurial/ since 511a4384b033.

dirstate: optimize walk() by using match.visitdir() We already have the logic for restricting directory walks in match.visitdir() that we use for treemanifests. We should take advantage of it when walking the working copy as well. This speeds up "hg st -I rootfilesin:." on the Firefox repo from 0.587s to 0.305s on warm disk (and much more on cold disk). More time is spent reading the dirstate than walking the working copy after. I tried to find scenarios where calling match.visitdir() would be a noticeable overhead, but I couldn't find any. I encourage the reader to try for themselves, since this is performance-critical code.

match: optimize visitdir() for patterns matching only root directory Because _rootsanddirs() returns a list of directories to visit recursively and a list of directories to visit non-recursively. For patterns such as 'rootfilesin:foo/bar', we clearly need to visit the directory foo/bar, but we also need to visit its parents. The method therefore uses util.dirs() to find the parent directories of 'foo/bar'. That method does not include the root directory, but since we obviously need to visit the root directory, we always added '.' to the set of directories to visit non-recursively. The visitdir() method had special handling to consider set(['.']) to mean that no includes had been specified and would thus visit all directories. However, when the pattern is 'rootfilesin:.', set(['.']) is actually the real set of directories to visit and the special handling of that set meant that all directories got visited instead of just the root directory. The fix is simple: add '.' to the set of parent directories in _rootsanddirs() and stop treating set(['.']) specially. This makes hg files -r . -I rootfilesin:. in a treemanifest version of the Firefox repo go from 1.5s to 0.26s on warm disk (and a *much* bigger improvement on cold disk). Note that the -I is necessary for no good reason. We just haven't optimized visitdir() for regular (non-include, non-exclude) patterns yet.

rebase: don't update state dict same way for each root The update statement does not depend on anything in the loop, so just move it before the loop and do it once. There are no cases where update would happen 0 times before (and 1 now); the function returns early in all such cases.

forget: access status fields by name, not index

demandimport: add urwid.command_map to ignore list The useful pudb debugger can be used with Mercurial, but its import of urwid fails when demandimport is enabled. Add urwid.command_map to the ignore list so pudb can be used with hg without disabling all of demandimport.

outgoing: run on filtered repo outgoing has been using an unfiltered repo since fe67107094fd (discovery: outgoing pass unfiltered repo to findcommonincoming (issue3776), 2013-01-28). If I'm reading code and history correctly, it should be safe to run _outgoing() on a filtered repo since c5456b64eb07 (discovery: run discovery on filtered repository, 2015-01-07). By running _outgoing() on a filtered repo, we can also remove the workaround there for ignoring filtered revisions.

manifest: remove check for non-contexts in _dirmancache It looks like the _dirmancache has contained only manifest contexts since d79c141fdf41 (manifest: remove usages of manifest.read, 2016-11-10).

bundle: factor the 'getchangegroup' out The call in the two branches is identical, so we can just issue it outside of the conditional.

bundle: avoid reset of the 'outgoing' variable We have a cleaner way to achieve the same effect. Not resetting the variable will help us to simplify the code.

changegroup: deprecate 'getlocalchangroup' (API) We have 'getchangegroup' with a shorter name for the exactly same feature. Now that all users are gone we can formally deprecate it.

tests: directly 'getchangegroup' It is identical to 'getlocalchangegroup' with a shorter name.

exchange: directly 'getchangegroup' It is identical to 'getlocalchangegroup' with a shorter name.

commands: directly 'getchangegroup' It is identical to 'getlocalchangegroup' with a shorter name.

changegroup: deduplicate 'getlocalchangegroup' The two functions 'getlocalchangegroup' and 'getchangegroup' have been strictly identical for multiple years ('getchangegroup' had a deprecated docstring) We'll drop one of them (getlocalchangegroup, since it has the longest name). However, we needs to migrate all users of the dropped one to the new one before we can deprecate it. In the mean time we drop one of the duplicated definition and the outdated docstring.

py3: add test to show 'hg log -Tjson' works

py3: add test to show 'hg log -G' works

py3: rename test-check-py3-commands.t to test-py3-commands.t test-check-*.t is a set of tests which tests certain coding style checks. So this test was wrongly named, thanks to marmoute for pointing this out.

py3: use list of bytes rather than bytestring while extending bytes into lists Python 2: >>> ls = [] >>> ls.extend(b'abc') >>> ls ['a', 'b', 'c'] Python 3: >>> ls = [] >>> ls.extend(b'abc') >>> ls [97, 98, 99] So to make sure things work fine in Py3, this patch does: >>> ls = [] >>> ls.extend([b'a', b'b', b'c']) >>> ls [b'a', b'b', b'c'] After this `hg log -G` works!

py3: use pycompat.byteskwargs to converts kwargs to bytes baseformatter._item must contain both keys and values in bytes. So to make sure that, we convert the opts back to bytes.

py3: make adefaults keys str to be compatible with getattr getattr passes a str value of the attribute to be looked and keys in adefaults dict are bytes which resulted in AttributeError. This patch abuses r'' to make the keys str.

py3: abuse r'' to access keys in keyword arguments

py3: use pycompat.bytechr instead of chr

py3: use %d to format integers into bytestrings

py3: use pycompat.bytestr instead of bytes

py3: slice over bytes to prevent getting ascii values

py3: use encoding.unitolocal instead of .encode(encoding.encoding)

rebase: use matcher to optimize manifestmerge The old merge code would call manifestmerge and calculate the complete diff between the source to the destination. In many cases, like rebase, the vast majority of differences between the source and destination are irrelevant because they are differences between the destination and the common ancestor only, and therefore don't affect the merge. Since most actions are 'keep', all the effort to compute them is wasted. Instead, let's compute the difference between the source and the common ancestor and only perform the diff of those files against the merge destination. When using treemanifest, this lets us avoid loading almost the entire tree when rebasing from a very old ancestor. This speeds up rebase of an old stack of 27 commits by 20x. In mozilla-central, without treemanifest, when rebasing a commit from default~100000 to default, this speeds up the manifestmerge step from 2.6s to 1.2s. However, the additional diff adds an overhead to all manifestmerge calls, especially for flat manifests. When rebasing a commit from default~1 to default it appears to add 100ms in mozilla-central. While we could put this optimization behind a flag, I think the fact that it makes merge O(number of changes being applied) instead of O(number of changes between X and Y) justifies it.

changegroup: delete unused 'bundlecaps' argument (API)

localrepo: reuse exchange.bundle2requested() It seems like localrepo.getbundle() is trying to do the same thing, so let's just call the method. That way we get the same condition as there (matching any "HG2" prefix, not only "HG20").

py3: use raw strings while accessing class.__dict__ The keys of class.__dict__ are unicodes on Python 3.

py3: handle opts correctly for `hg add` opts in add command were passed again to cmdutil.add() as kwargs so we need to convert them again to str. Intstead we convert them to bytes when passing scmutil.match(). Opts handling is also corrected for all the functions which are called from cmdutil.add().

py3: handle opts correctly for rollback dryrun and force are just check for None, the value is not used. So its better to leave opts as unicodes as that wont harm us.

py3: handle opts correctly for unbundle There is just a check whether the value is None or not. So even having optupdate as unicodes won't harm us.

py3: convert opts to bytes in cmdutil.dorecord() commands.commit() calls cmdutil.dorecord() where opts are passed as unicodes being keyword arguments. This patch converts them back to bytes as they are required.

py3: make sure opts are passed and used correctly in help command opts are converted back to bytes in help.help_() where they are used. Before that it's ensured that we have a bytes value for keep variable.

py3: handle opts uniformly in commands.py Since keyword arguments can't be bytes on Python 3, we converted then to unicodes before passing into different command functions. We need to adopt a certain pattern to convert opts back to bytes. Following are some of the functions which are called from inside these command functions and should always be feeded bytes to follow the right behaviour. ui.fomattter() scmutil.match() patch.diffallopts() hg.peer() cmdutil.{show_changeset|copy|graphrevs|checkunsupportedflag} server.{createservice|runservice} There are few commands which are left out where opts is again passed to a function as keyword arguments or converting opts back to bytes is kind of not necessary. Those are cat, revert, help, unbundle and rollback. Following patches will deal with them. This patch apart from these five commands, convert opts back to bytes for rest of the commands. This fixes a lot of things which are hidden like --git works now. Similarly more flags of commands which run on Python 3 currently get fixed.

merge with stable

webcommands: use fctx.isbinary

annotate: use fctx.isbinary

fileset: use fctx.isbinary instead of util.binary(fctx.data()) filectx provides "isbinary" to test if the data is binary. Let's use it. This enables other filectx implementations (like LFS) to override the isbinary test.

internals: document that "branches" is a legacy wire command Modern clients use a different discovery mechanism.

match: make subinclude construction lazy The matcher subinclude functionality allows us to have .hgignore files that include subdirectory hgignore files. Today it parses the entire repo at once, even if we only need to test a file in one subdirectory. This patch makes the subinclude tree creation lazy, which speeds up matcher creation significantly in large repos with very large trees of ignore patterns.

bisect: allow resetting with unfinished graft/rebase/etc "hg bisect --reset" just deletes the state file (it doesn't move back to the starting point like rebase does); it can not conflict with an ongoing rebase etc. checkunfinished() has this documentation: It's probably good to check this right before bailifchanged(). So that's where I moved it.

py3: use %d instead of %s for integers dispatch._runcatch() always returns an integer value.

py3: make posix.getuser return a bytes

py3: replace str with bytes in isinstance()

py3: use pycompat.bytestr() instead of str() This is because str() on python 3 return unicodes

py3: alias long to int on Python 3

setup: sys.version_info always exists It is documented as existing since Python 2.0, and empirically from other OSS projects I maintain, there is no problem relying on its existance.

filelog: fix parsemeta docstring 75bb7c702317 changed the return type of filelog.parsemeta but forgot to update its docstring.

util: remove doc of long gone 'targetsize' argument Gone since fa836e050c50 (chunkbuffer: removed unused method and arg, 2007-10-11).

cleanup: drop the deprecated 'localrepo._link' method This was deprecated in favor of 'localrepo.wvfs.islink'. We can now drop it for the future 4.3.

cleanup: drop the deprecated 'localrepo.wfile' method This was deprecated in favor of 'localrepo.wvfs.join'. We can now drop it for the future 4.3.

cleanup: drop the deprecated 'localrepo.join' method This was deprecated in favor of 'localrepo.vfs.join'. We can now drop it for the future 4.3.

cleanup: drop the deprecated 'localrepo.tag' method This was deprecated in favor of 'mercurial.tags.tag'. We can now drop it for the future 4.3.

cleanup: drop the deprecated 'localrepo.opener' method This was deprecated in favor of 'localrepo.vfs'. We can now drop it for the future 4.3.

cleanup: drop the deprecated 'localrepo.wopener' method This was deprecated in favor of 'localrepo.wvfs'. We can now drop it for the future 4.3.

cleanup: drop vfs compatibility layer in scmutil All these constructors are deprecated in 4.2. We can now drop them on the default branch (future 4.3).

test-worker: exercise more about "killworkers" situation This patch adds some sleep and increases numcpus to exercise the "killworkers" situation. So race conditions could be discovered more easily, if someone changes worker.py incorrectly. Currently worker.py should be free of such issues.

test-worker: capture tracebacks more reliably The traceback test may have traceback caused by SIGTERM. Instead of grepping "Traceback", explicitly grep the exception we care about. This makes the test less flaky.

worker: rewrite error handling so os._exit covers all cases Previously the worker error handling is like: pid = os.fork() --+ if pid == 0: | .... | problematic .... --+ try: --+ .... | worker error handling --+ If a signal arrives when Python is executing the "problematic" lines, an external error handling (dispatch.py) will take over the control flow and it's no longer guaranteed "os._exit" is called (see 86cd09bc13ba for why it is necessary). This patch rewrites the error handling so it covers all possible code paths for a worker even during fork. Note: "os.getpid() == parentpid" is used to test if the process is parent or not intentionally, instead of checking "pid", because "pid = os.fork()" may be not atomic - it's possible that that a signal hits the worker before the assignment completes [1]. The newly added test replaces "os.fork" to exercise that extreme case. [1]: CPython compiles "pid = os.fork()" to 2 byte codes: "CALL_FUNCTION" and "STORE_FAST", so it's probably not atomic: def f(): pid = os.fork() dis.dis(f) 2 0 LOAD_GLOBAL 0 (os) 3 LOAD_ATTR 1 (fork) 6 CALL_FUNCTION 0 9 STORE_FAST 0 (pid) 12 LOAD_CONST 0 (None) 15 RETURN_VALUE

dispatch: take over SignalInterrupt handling from scmutil dispatch handles KeyboardInterrupt already. This makes the code more consistent, and makes worker not print "killed!" if it receives SIGTERM in most cases (in rare cases there is still "killed!" printed, which will be fixed by the next patch).

merge stable into default

Added signature for changeset 26c49ed51a69

Added tag 4.2.2 for changeset 26c49ed51a69

help: cleanup grammar in the hooks section

merge with i18n

revlog: backed out changeset e9d325cfe071 We'll move this to the default branch.

i18n-pt_BR: synchronized with efebc9f52ecb

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

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.

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.

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.

largefiles: avoid a crash when archiving a subrepo with largefiles disabled This path is also used for extdiff, which is how I crossed paths with it. Without this, an AttributeError occurs looking for 'lfstatus' on localrepository. See also d414c28db84d. The other archive method is for the archival.py override, so it doesn't need to be special cased like this. (It looks like it is only called for the top level repo.) Likewise, the transplant override is also for commands.py. The other overrides set lfstatus before examining it.

help: correct description of "glob:foo/*" matching Unlike what the description says, it does not match recursively. Also add an example of "glob:foo/**" (which does match recursively).

Added signature for changeset c850f0ed54c1

Added tag 4.2.1 for changeset c850f0ed54c1

status: don't crash if a lookup file disappears This can happen if another process (even another hg process!) comes along and removes the file at that time. This partly resolves issue5584, but not completely -- a bogus dirstate update can still happen. However, the full fix is too involved for stable.

help: clarify the choice of pager This follows the change made in d83e51654c8a to use environment variables between system and user configuration.

i18n-pt_BR: fix syntax error on translation

i18n-pt_BR: synchronized with 870248603a4e

merge with i18n

i18n-pt_BR: synchronized with a0e46f6b248b

zsh_completion: install as _hg not hg The contrib/zsh_completion file itself says to name it _hg. With a name like `hg`, if the user has a line like `autoload ${^fpath}/*(N-.:t)` in their zshrc, it will create a shell function named `hg` that will hide the actual hg command and make hg unusable. Separately from that though, the underscore prefix makes it actually work. The zsh man page states: The convention for autoloaded functions used in completion is that they start with an underscore This does not seem to just be a "convention", though. With the ill-advised line removed from my zshrc and the file named `/usr/local/share/zsh/site-functions/hg` (without the underscore), these completions did not seem to get loaded and the ones from the zsh installation were loaded instead. If I renamed them to be `/usr/local/share/zsh/site-functions/_hg`, however, they were loaded. I manually tested the above statement by starting a new zsh instance with the file in `/usr/local/share/zsh/site-functions` with the following names: - As `hg`, `which _hg_labels` did not show anything - As `_hg`, `which _hg_labels` showed the expected function.

osx: override default exclude filter for pkgbuild To quote `man 1 pkgbuild`: --filter filter-expression By default, --root will include the entire contents of the given root-path in the package payload, except for any .svn or CVS directories, and any .DS_Store files. You can override these default filters by specifying one or more --filter options. Each filter-expression is an re_format(7) ``extended'' expression: any path in the root which matches any of the given expressions will be excluded from the pack- age payload. (Note that specifying even one --filter inhibits the default filters, so you must respecify the default fil- ters if you still want them to be used.) It turns out the default filter these days *also* includes .git and .hg. Notice how that filter expression is a regular expression? That (presumably unintentionally) prevents a file named "chg" or "_hg" from getting included in the distribution. Many many thanks to spectral@ for trying to include a _hg file which led us to figure this bug out. Bug filed with Apple for this as rdar://problem/32437369, mentioning both the gap in documentation and the wrong defaults.

bugzilla: fix typo in help text

help: fix typos

win32mbcs: avoid unintentional failure at colorization Since 176ed32dc159, pycompat.bytestr() wrapped by win32mbcs returns unicode object, if an argument is not byte-str object. And this causes unexpected failure at colorization. pycompat.bytestr() is used to convert from color effect "int" value to byte-str object in color module. Wrapped pycompat.bytestr() returns unicode object for such "int" value, because it isn't byte-str. If this returned unicode object is used to colorize non-ASCII byte-str in cases below, UnicodeDecodeError is raised at an operation between them. - colorization uses "ansi" color mode, or Even though this isn't default on Windows, user might use this color mode for third party pager. - ui.write() is buffered with labeled=True Buffering causes "ansi" color mode internally, regardless of actual color mode. With "win32" color mode, extra escape sequences are omitted at writing data out. For example, with "win32" color mode, "hg status" doesn't fail for non-ASCII filenames, but "hg log" does for non-ASCII text, because the latter implies buffered formatter. There are many "color effect" value lines in color.py, and making them byte-str objects isn't suitable for fixing on stable. In addition to it, pycompat.bytestr will be used to get byte-str object from any types other than int, too. To resolve this issue, this patch does: - replace pycompat.bytestr in checkwinfilename() with newly added hook point util._filenamebytestr, and - make win32mbcs reverse-wrap util._filenamebytestr (this is a replacement of 176ed32dc159) This patch does two things above at same time, because separately applying the former change adds broken revision (from point of view of win32mbcs) to stable branch. "_" prefix is added to "filenamebytestr", because it is win32mbcs specific hook point.

debian: add less as a build dependency For builds that run on hermetic environments, it's possible that the "less" package is not installed by default, yet it's needed for tests to pass after revision bf5e13e38390 (which sets less as the fallback pager).

wix: add 'ro' and 'ru' locales Also noticed when diffing an MSI installation against an Inno installation. OTOH, the Inno install doesn't include 'i18n' with the *.po files.

wix: include zstd.pyd in the installation When trying to create a zstd bundle, the MSI based install said: abort: compression engine zstd could not be loaded The Inno installer is unaffected. The name will need to be updated to include 'cext' when merging into default.

clonebundles: fix missing newline character Previously, the line displayed as '( )' instead of '(\n)'.

exchange: print full reason variable This commit essentially reverts 69ac9aebbc55. urllib2.URLError receives a "reason" argument. It isn't always a tuple. Mozilla has experienced at least IndexError failures due to the reason[1] access. https://bugzilla.mozilla.org/show_bug.cgi?id=1364687

dispatch: setup color before pager for correct console information on windows Before this patch, "hg CMD --pager on" on Windows shows output unintentionally decorated with ANSI color escape sequences, if color mode is "auto". This issue occurs in steps below. 1. dispatch() invokes ui.pager() at detection of "--pager on" 2. stdout of hg process is redirected into stdin of pager process 3. "ui.formatted" = True, because isatty(stdout) is so before (2) 4. color module is loaded for colorization 5. color.w32effects = None, because GetConsoleScreenBufferInfo() fails on stdout redirected at (2) 6. "ansi" color mode is chosen, because of "not w32effects" 7. output is colorized in "ansi" mode because of "ui.formatted" = True Even if "ansi" color mode is chosen, ordinarily redirected stdout makes ui.formatted() return False, and colorization is avoided. But in this issue case, "ui.formatted" = True at (3) forces output to be colorized. For correct console information on win32, it is needed to ensure that color module is loaded before redirection of stdout for pagination. BTW, if any of enabled extensions has "colortable" attribute, this issue is avoided even before this patch, because color module is imported as a part of loading such extension, and extension loading occurs before setting up pager. For example, mq and keyword have "colortable".

obsolete: invalidate "volatile" set cache after merging marker Adding markers to the repository might affect the set of obsolete changesets. So we most remove the "volatile" set who rely in that data. We add two missing invalidations after merging markers. This was caught by code change in the evolve extensions tests. This issues highlight that the current way to do things is a bit fragile, however we keep things simple for stable.

win32mbcs: wrap underlying pycompat.bytestr to use checkwinfilename safely win32mbcs wraps some functions, to prevent them from unintentionally treating backslash (0x5c), which is used as the second or later byte of multi bytes characters by problematic encodings, as a path component delimiter on Windows platform. This wrapping assumes that wrapped functions can safely accept unicode string arguments. Unfortunately, d1937bdcee8c broke this assumption by introducing pycompat.bytestr() into util.checkwinfilename() for py3 support. After that, wrapped checkwinfilename() always fails for non-ASCII filename at pycompat.bytestr() invocation. This patch wraps underlying pycompat.bytestr() function to use util.checkwinfilename() safely. To avoid similar regression in the future, another patch series will add smoke testing on default branch.

hghave: prefill more version of Mercurial The previous code was unable to go above version 4.0.

graft: fix graft across merges of duplicates of grafted changes Graft used findmissingrevs to find the candidates for graft duplicates in the destination. That function operates with the constraint: 1. N is an ancestor of some node in 'heads' 2. N is not an ancestor of any node in 'common' For our purpose, we do however have to work correctly in cases where the graft set has multiple roots or where merges between graft ranges are skipped. The only changesets we can be sure doesn't have ancestors that are grafts of any changeset in the graftset, are the ones that are common ancestors of *all* changesets in the graftset. We thus need: 2. N is not an ancestor of all nodes in 'common' This change will graft more correctly, but it will also in some cases make graft slower by making it search through a bigger and unnecessary large sets of changes to find duplicates. In the general case of grafting individual or linear sets, we do the same amount of work as before.

graft: test coverage of grafts and how merges can break duplicate detection This demonstrates unfortunate behaviour: extending the graft range cause the graft to behave differently. When the graft range includes a merge, we fail to detect duplicates that are ancestors of the merge.

churn: use the non-deprecated template option in the examples

sslutil: reference fingerprints config option properly (issue5559) The config option is "host:fingerprints" not "host.fingerprints". This warning message is bad and misleads users.

largefiles: make sure debugstate command is populated before wrapping Copied the hack from 869d660b8669, which seemed the simplest workaround. Perhaps debugcommands.py should have its own commands table.

help: describe about choice of :prompt as a fallback merge tool explicitly "merge-tools" help topic has described that the merge of the file fails if no tool is found to merge binary or symlink, since c77f6276c9e7 (or Mercurial 1.7), which based on (already removed) MergeProgram wiki page. But even at that revision, and of course now, merge of the file doesn't fail automatically for binary/symlink. ":prompt" (or equivalent logic) is used, if there is no appropriate tool configuration for binary/symlink.

wix: only one KeyPath is allowed per Component

help: call out specific replacement configuration settings As an aside, I'm having trouble parsing the help text meaning for HG when it is unset or empty. How can it be the frozen name or searched if it is empty?

help: spelling fixes

help: attempt to clarify that pager usage is not output length based This may be too subtle of a change to get the point across, but when I first read the original text, I thought maybe the pager would only be invoked if writing more than a screenful. The distinction between this and a pager that simply exits after printing less than a screenful is important on Windows, given the inability of `more` to color output.

help: document color/pager pitfalls on Windows Even though I figured this out a few weeks ago, I was initially puzzled where the color went when I upgraded to 4.2 on a different Windows machine. Let's point users reading the help into the right direction. I wonder if we should be even more explicit about cmd.exe/MSYS/pager/color interplay, but at least all of the breadcrumbs are here (I think).

test-diff-color: disable pager for expected output on Windows (issue5555) Windows uses `more.com`, which unhelpfully adds an extra trailing line consisting only of '\r'. It also converts tab characters to spaces, which throws off the last two tests. Setting the 'ui.formatted' option is what allowed the pager to be used by these tests in the first place.

Added signature for changeset bb96d4a49743

Added tag 4.2 for changeset bb96d4a49743

merge with i18n

i18n-ja: synchronized with 6e0368b6e0bb

pager: drop the support for 'pager.enable=<bool>' This option was never released except for a release candidate. Dropping compatibility with this option will free the 'pager.enable' config option for other usage in the future.

pager: rename 'pager.enable' to 'ui.paginate' This aligns with what we do for color (see 7fec37746417). Pager is a central enough notion that having the master config in the [ui] section makes senses. It will helps with consistency, discoverability. It will also help having a simple and clear example hgrc mentioning pager. The previous form of the option had never been released in a non-rc version but we keep it around for convenience. If both are set, 'ui.pager' take priority.

color: special case 'always' in 'ui.color' This lift the confusing case, where 'ui.color=always' would actually not always use color.

color: turn 'ui.color' into a boolean (auto or off) Previously, 'ui.color=yes' meant "always show color", While "ui.color=auto" meant "use color automatically when it appears sensible". This feels problematic to some people because if an administrator has disabled color with "ui.color=off", and a user turn it back on using "color=on", it will get surprised (because it breaks their output when redirected to a file.) This patch changes ui.color=true to only move the default value of --color from "never" to "auto". I'm not really in favor of this changes as I suspect the above case will be pretty rare and I would rather keep the logic simpler. However, I'm providing this patch to help the 4.2 release in the case were others decide to make this changes. Users that want to force colors without specifying --color on the command line can use the 'ui.formatted' config knob, which had to be enabled in a handful of tests for this patch. Nice summary table (credit: Augie Fackler) That is, before this patch: +--------------------+--------------------+--------------------+ | | not a tty | a tty | | | --color not set | --color not set | | | | | +--------------------+--------------------+--------------------+ | [ui] | | | | color (not set) | no color | no color | | | | | +--------------------+--------------------+--------------------+ | [ui] | | | | color = auto | no color | color | | | | | +--------------------+--------------------+--------------------+ | [ui] | | | | color = yes | *color* | color | | | | | +--------------------+--------------------+--------------------+ | [ui] | | | | color = no | no color | no color | | | | | +--------------------+--------------------+--------------------+ (if --color is specified, it always clobbers the setting in [ui]) and after this patch: +--------------------+--------------------+--------------------+ | | not a tty | a tty | | | --color not set | --color not set | | | | | +--------------------+--------------------+--------------------+ | [ui] | | | | color (not set) | no color | no color | | | | | +--------------------+--------------------+--------------------+ | [ui] | | | | color = auto | no color | color | | | | | +--------------------+--------------------+--------------------+ | [ui] | | | | color = yes | *no color* | color | | | | | +--------------------+--------------------+--------------------+ | [ui] | | | | color = no | no color | no color | | | | | +--------------------+--------------------+--------------------+ (if --color is specified, it always clobbers the setting in [ui])

pager: document the 'pager.enable' option The 'config' helps was missing help about pager enabling/disabling.

pager: advertise the config option in the default hgrc Same as for 'ui.color', this is a critical part of the UI and we want user to find this config knob easily.

pager: document the 'pager' config section There as a 'hg help pager' section but the 'hg help config.pager' was missing.

pager: test the 'enable' config option While poking at this option I realised it was not tested.

config: drop pager from the recommended extension The extension is deprecated, we should having exposing it to users.

config: use "churn" as an example extension "Churn" is not the useful example we have, but this is the one used in 'hg help config.extensions'. As we need something to replace the deprecated 'pager' extension in the example config, we are adding 'churn'.

discovery: prevent crash caused by prune marker having no parent data If a marker has no parent information, parents field is set to None, which caused TypeError. I think this shouldn't normally happen, but somehow I have such marker in my repo.

color: point to the global help in the example hgrc This is probably the best way to have users learn more is they need too.

color: reflect the new default in the example hgrc Color is enabled by default so un-commenting the line would not have any effect. We'll point to the help in the next changeset.

color: point to the config help in global help topic We point out at the help of the config option for user who wants to learn more about the possible config value. The suggested command returns some other extra (color related) results, but this is bug to fix outside of the freeze.

color: reflect the new default in global help topic We point out that color is enabled by default.

docs: describe ui.color consistently with --color The --color option is described to accept "boolean, always, auto, never, or debug". Let's use a similar description for ui.color. Also fix the formatting to use double quotes as we seem to use for about half the values in config.txt (the other half uses double backticks). Also use uppercase Boolean for consistency within the file.

test: glob out variation from 'HGPORT' length On system where HGTEST_PORT is configured to a value an order a magnitude lower or higher than the default. The number of digit in the HGPORT changes and this test breaks.

lock: avoid unintentional lock acquisition at failure of readlock Acquiring lock by vfs.makelock() and getting lock holder (aka "locker") information by vfs.readlock() aren't atomic action. Therefore, failure of the former doesn't ensure success of the latter. Before this patch, lock is unintentionally acquired, if ENOENT causes failure of vfs.readlock() while 5 times retrying, because lock._trylock() returns to caller silently after retrying, and lock.lock() assumes that lock._trylock() returns successfully only if lock is acquired. In this case, lock symlink (or file) isn't created, even though lock is treated as acquired in memory. To avoid this issue, this patch makes lock._trylock() raise LockHeld(EAGAIN) at the end of it, if lock isn't acquired while retrying. An empty "locker" meaning "busy for frequent lock/unlock by many processes" might appear in an abortion message, if lock acquisition fails. Therefore, this patch also does: - use '%r' to increase visibility of "locker", even if it is empty - show hint message to explain what empty "locker" means

lock: avoid unintentional lock acquisition at failure of readlock Acquiring lock by vfs.makelock() and getting lock holder (aka "locker") information by vfs.readlock() aren't atomic action. Therefore, failure of the former doesn't ensure success of the latter. Before this patch, lock is unintentionally acquired, if self.parentlock is None (this is default value), and lock._readlock() returns None for ENOENT at vfs.readlock(), because these None are recognized as equal to each other. In this case, lock symlink (or file) isn't created, even though lock is treated as acquired in memory. To avoid this issue, this patch retries lock acquisition immediately, if lock._readlock() returns None "locker". This issue will be covered by a test added in subsequent patch, because simple emulation of ENOENT at vfs.readlock() easily causes another issue. "raising ENOENT only at the first vfs.readlock() invocation" is too complicated for unit test, IMHO.

httppeer: unify hint message for PeerTransportError Another raising PeerTransportError for "incomplete response" in httppeer.py uses this (changed) hint message. This unification reduces cost of translation.

revset: add i18n comments to error messages for followlines predicate This patch also includes un-quoting "descend" keyword for similarity to other error messages (this seems too trivial as a separated patch).

help: apply bulk fixes for indentation and literal blocking issues There are some paragraphs, which aren't rendered in online help as expected because of indentation and literal blocking issues. - hgext/rebase.py - paragraph before example code ends with ":", which treats subsequent indented paragraphs as normal block => replace ":" with "::" to treat subsequent paragraphs as literal block - help/pager.txt - paragraph before a list of --pager option values ends with "::", which treats subsequent indented paragraphs as literal block => replace "::" with ":" to treat subsequent paragraphs as normal block - the second line of explanation for no/off --pager option value is indented incorrectly (this also causes failure of "make" in doc) => indent correctly - help/revisions.txt - explanation following example code of "[revsetalias]" section isn't suitable for literal block => un-indent explanation paragraph to treat it as normal block - indentation of "For example" before example of tag() revset predicate matching is meaningless - descriptive text for tag() revset predicate matching isn't suitable for literal block => un-indent concatenated two paragraphs to treat them as normal block

rebase: fix incorrect configuration example This configuration example doesn't make rebase require a destination, even though help document wants to show such example.

help: use hg role of mini reST to make hyper link in HTML page

help: use mercurial as a subject of colorization and pagination Now, colorization and pagination are in Mercurial core.

packaging: add make target for linux wheels Having linux wheels is going to helps system without compiler or python-dev plus speed up the installation for everyone. I followed the manylinux example repository https://github.com/pypa/python-manylinux-demo to add a make target (build-linux-wheels) using official docker image to build python 2 linux wheels for mercurial. It generates Python 2.6 and Python 2.7 for both 32 and 64 bits architectures. I had to blacklist several test cases for various reasons: * test-convert-git.t and test-subrepo-git.t because of the git version * test-patchbomb-tls.t because of warning using tls 1.0 It's likely because the docker image is based on centos 5.0 and openssl is outdated.

tests: fix two http tests to also pass inside manylinux1 docker This will let us build Linux wheels.

pager: use less as a fallback on Unix This seems reasonable choice per discussion, and the default-default of Git. See also the inline-comment for why. https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/097042.html

test-bookmarks: factor hooks out to a shell script for Windows The previous incarnation of the hooks weren't being run on Windows, which altered the DAG and hashes[1]. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096987.html

help: explain how to access subtopics in internals

log: document the characters ---graph uses to draw The meaning of : vs | was undocumented and non-obvious.

tests: demonstrate that pager.attend-<abbreviated> doesn't work A pager.attend-* value that isn't a full command or alias name doesn't work. We add explicit test coverage of this to demonstrate it.

tests: test that abbreviated command alias is also paged Explicit test coverage is good.

tests: drop unnecessary pager attend in test `log` is attended by default. We don't need to specify pager.attend-log in this test.

hgweb: change text of followlines links to "older / newer" DAG directions "descending" / "ascending" arguably do not make much sense in the web interface where changes are usually listed by "dates".

hgweb: do not show "descending" link in followlines UI for filelog heads When on a filelog head, we are certain that there will be no descendant so the target of the "descending" link will lead to an empty log result. Do not display the link in this case.

context: optimize linkrev adjustment in blockancestors() (issue5538) We set parent._descendantrev = child.rev() when walking parents in blockancestors() so that, when linkrev adjustment is perform for these, it starts from a close descendant instead of possibly topmost introrev. (See `self._adjustlinkrev(self._descendantrev)` in filectx._changeid().) This is similar to changeset c82d88dfaf59, which added a "f._changeid" instruction in annotate() for the same purpose. However, here, we set _descendantrev explicitly instead of relying on the '_changeid' cached property being accessed (with effect to set _changeid attribute) so that, in _parentfilectx() (called from parents()), we go through `if '_changeid' in vars(self) [...]` branch in which instruction `fctx._descendantrev = self.rev()` finally appears and does what we want. With this, we can roughly get a 3x speedup (including in example of issue5538 from mozilla-central repository) on usage of followlines revset (and equivalent hgweb request).

record: update help message to use operation instead of "record" (issue5432) Update the hunk selector help message to use the operation name instead of using "record" for all operations. Extract the help message in the same way as other single and multiple message line. Update tests to make sure that both "revert" and "discard" variants are tested.

tests: add lots of regex matching to test-http-bad-server.t This makes the test pass in Python 2.6. It's all one of two problems: 1) abort: error: '' (2.7) vs abort: error: (2.6) 2) 65537 (2.7) vs -1 (2.6) With some...unfortunate escaping required due to how regular expressions work. Sigh.

tests: pass only one file at a time to tail(1) It looks like the verison on Solaris only tails one file at a time.

debian: configure editor and pager to sensible-\1 by default Now that environment variables override system-wide hgrc settings, we can default Mercurial to sensible-editor and sensible-pager by default for debian users.

tests: work around flaky test failure on FreeBSD and relatives test-http-bad-server has a flaky output case that reproduces fairly often (20% or more of runs on my Mac) on BSD-family OSes. So that tests can be green for the 4.2 release, let's more or less give up on this output, and plan to pursue it in the future.

context: start walking from "introrev" in blockancestors() Previously, calling blockancestors() with a fctx not touching file would sometimes yield this filectx first, instead of the first "block ancestor", because when compared to its parent it may have changes in specified line range despite not touching the file at all. Fixing this by starting the algorithm from the "base" filectx obtained using fctx.introrev() (as done in annotate()). In tests, add a changeset not touching file we want to follow lines of to cover this case. Do this in test-annotate.t for followlines revset tests and in test-hgweb-filelog.t for /log/<rev>/<file>?linerange=<from>:<to> tests.

sshpeer: try harder to snag stderr when stdout closes unexpectedly Resolves test failures on FreeBSD, but I'm not happy about the fix. A previous version of this also wrapped readline by putting the hack in the _call method on doublepipe. That was confusing for readers and wasn't necessary - just doing this on read() is sufficient to fix the bugs I'm observing. We can always come back and do readline later if needed.

test-worker: disable tests of forked workers on Windows The number of the "Traceback" lines differs on Windows because the main process does not raise SystemExit.

test-profile: allow negative time in JSON output (issue5542) I don't know why it can be a negative number, but that shouldn't be important here.

show: add basic labels to work template `hg show work` is much more usable if output is colored. This patch implements coloring via label() in a very hacky way. In a default Mercurial install, you'll see yellow node labels for all phases. Branches and bookmarks use the same formatting as the commit message. So this change doesn't help much in a default install. But if you have a custom colors defined for these things, output is much more readable. The implementation obviously needs some work. But for a minor change on a feature that isn't convered by BC, this seems like a clear win for the feature in 4.2.

show: rename "underway" to "work" Durham and I both like this better than "underway." We can add aliases and bikeshed on the name during the 4.3 cycle, as this whole extension is highly experimental.

histedit: make check for unresolved conflicts explicit (issue5545) Previously, we'd rely on the implicit check that `localrepo.commit` did. The problem is that that check only happened when the working copy was dirty. With a "clean" working copy but unresolved conflicts we'd get into a broken state. To fix that, do what rebase does and check for unresolved conflicts at the start of histedit --continue.

Added signature for changeset 616e788321cc

Added tag 4.2-rc for changeset 616e788321cc

freeze: merge default into stable for 4.2 code freeze

Merge stable with security patch.

Added signature for changeset 77eaf9539499

Added tag 4.1.3 for changeset 77eaf9539499

dispatch: protect against malicious 'hg serve --stdio' invocations (sec) Some shared-ssh installations assume that 'hg serve --stdio' is a safe command to run for minimally trusted users. Unfortunately, the messy implementation of argument parsing here meant that trying to access a repo named '--debugger' would give the user a pdb prompt, thereby sidestepping any hoped-for sandboxing. Serving repositories over HTTP(S) is unaffected. We're not currently hardening any subcommands other than 'serve'. If your service exposes other commands to users with arbitrary repository names, it is imperative that you defend against repository names of '--debugger' and anything starting with '--config'. The read-only mode of hg-ssh stopped working because it provided its hook configuration to "hg serve --stdio" via --config parameter. This is banned for security reasons now. This patch switches it to directly call ui.setconfig(). If your custom hosting infrastructure relies on passing --config to "hg serve --stdio", you'll need to find a different way to get that configuration into Mercurial, either by using ui.setconfig() as hg-ssh does in this patch, or by placing an hgrc file someplace where Mercurial will read it. mitrandir@fb.com provided some extra fixes for the dispatch code and for hg-ssh in places that I overlooked.

progress: retry ferr.flush() and .write() on EINTR (issue5532) See the inline comment how this could mitigate the issue. I couldn't reproduce the exact problem on my Linux machine, but there are at least two people who got EINTR in progress.py, and it seems file_write() of Python 2 is fundamentally broken [1]. Let's make something in on 4.2. [1]: https://hg.python.org/cpython/file/v2.7.13/Objects/fileobject.c#l1850

progress: extract stubs to restart ferr.flush() and .write() on EINTR

filemerge: optionally strip quotes from merge marker template (BC) For consistency with the other template options. Quotes are necessary if you want to preserve leading/trailing whitespace, which would be stripped by config parser.

commit: optionally strip quotes from commit template (BC) For consistency with the other template options.

graphlog: optionally strip quotes from graphnode template (BC) For consistency with the other template options.

dispatch: ignore further SIGPIPE while handling KeyboardInterrupt I got the following error by running "hg log" and quitting the pager immediately. Any output here may trigger another SIGPIPE, so only thing we can do is to swallow the exception and exit with an error status. Traceback (most recent call last): File "./hg", line 45, in <module> mercurial.dispatch.run() File "mercurial/dispatch.py", line 83, in run status = (dispatch(req) or 0) & 255 File "mercurial/dispatch.py", line 167, in dispatch req.ui.warn(_("interrupted!\n")) File "mercurial/ui.py", line 1224, in warn self.write_err(*msg, **opts) File "mercurial/ui.py", line 790, in write_err self._write_err(*msgs, **opts) File "mercurial/ui.py", line 798, in _write_err self.ferr.write(a) File "mercurial/ui.py", line 129, in _catchterm raise error.SignalInterrupt mercurial.error.SignalInterrupt Perhaps this wasn't visible before de5c9d0e02ea because the original stderr handle was restored very late.

worker: print traceback for uncaught exception unconditionally This is what a Python interpreter would do if there were no os._exit().

worker: propagate exit code to main process Follows up 86cd09bc13ba.

dispatch: print traceback in scmutil.callcatch() if --traceback specified Otherwise, traceback wouldn't be printed for a known exception occurred in worker processes.

dispatch: mark callcatch() as a private function

templatefilters: fix crash by string formatting of '{x|splitlines}' Before, it crashed because mapping['templ'] was missing. As it didn't support the legacy list template from the beginning, we can simply use hybridlist().

templatekw: factor out showdict() helper Make it less cryptic for common cases.

templatekw: have showlist() take mapping dict with no **kwargs expansion (API) See the previous commit for why. splitlines() does not pass a mapping dict, which would probably mean the legacy template didn't work from the beginning.

templatekw: change _showlist() to take mapping dict with no **kwargs expansion There was a risk that a template keyword could conflict with an argument name (e.g. 'name', 'values', 'plural', etc.) Let's make it less magical.

templatekw: rename 'args' to 'mapping' in showlist() The name 'args' provides no information. Call it 'mapping' as in templater.py.

templatekw: eliminate unnecessary temporary variable 'names' from _showlist() Replace 'names' with the optional argument 'plural'.

color: update the help with the new default The default is now "auto" we update the help to match reality.

upgrade: register all format variants in a list Now that all known format variants exists outside of the function, we can gather them in a lists. This build a single entry point other code can use (current target: extensions). The repository upgrade code is updated to simply use entries from this list. As a side effect this will also allow extensions to register their own format variants, to do this "properly" we should introduce a "registrar" for this category of object. However I prefer to keep this series simple, and that will be adventure for future time.

upgrade: move descriptions and selection logic in individual classes Our goal here is to get top level definition for all the format variants. Having them defined outside of the function enabled other users of that logic. They are two keys components of a format variant: 1) the name and various descriptions of its effect, 2) the code that checks if the repo is using this variant and if the config enables it. That second items make us pick a class-based approach, since different variants requires different code (even if in practice, many can reuse the same logic). Each variants define its own class that is then used like a singleton. The class-based approach also clarify the definitions part a bit since each are simple assignment in an indented block. The 'fromdefault' and 'fromconfig' are respectively replaced by a class attribute and a method to be called at the one place where "fromconfig" matters. Overall, they are many viable approach for this, but this is the one I picked.

upgrade: introduce a 'formatvariant' class The 'deficiency' type has multiple specificities. We create a dedicated class to host them. More logic will be added incrementally in future changesets.

upgrade: implement '__hash__' on 'improvement' class The pythonomicon request its implementation.

upgrade: implement '__ne__' on 'improvement' class The pythonomicon request its implementation.

color: also enable by default on windows I've not found anything related to color + windows on the bug tracker. So I'm suggesting we get bolder and turn it on for windows too in the release candidate. We can always backout this changeset if we find serious issue on windows.

color: turn on by default (but for windows) Color support is all in core for a couple of months. I've browsed the bug tracker without finding any blocker bug. So I'm moving forward and enable color on by default before '4.2-rc'. In the worse case, having it on in the release candidate will help us to find blocker bug and we can turn it off for the final release. I remember people talking about issue with Windows during the freeze so I'm keeping it off by default on that OS. We could do various cleaning of the color used and the label issued. However the label are probably already in our backward compatibility envelope since the color extensions has been around since for ever and I do not think the color choice themself should be considered BC. So I think we should rather gives color to all user sooner than later. A couple of test needs to be updated to avoid having color related control code spoil the tested output.

pager: stop using the color extension in tests The feature is in core so let us use the core config knob directly.

bundle2: ignore errors seeking a bundle after an exception (issue4784) Many have seen a "stream ended unexpectedly" error. This message is raised from changegroup.readexactly() when a read(n) operation fails to return exactly N bytes. I believe most occurrences of this error in the wild stem from the code changed in this patch. Before, if bundle2's part applicator raised an Exception when processing/applying parts, the exception handler would attempt to iterate the remaining parts. If I/O during this iteration failed, it would likely raise the "stream ended unexpectedly" exception. The problem with this approach is that if we already encountered an I/O error iterating the bundle2 data during application, then any further I/O would almost certainly fail. If the original stream were closed, changegroup.readexactly() would obtain an empty string, triggering "stream ended unexpectedly" with "got 0." This is the error message that users would see. What's worse is that the original I/O related exception would be lost since a new exception would be raised. This made debugging the actual I/O failure effectively impossible. This patch changes the exception handler for bundle2 application to ignore errors when seeking the underlying stream. When the underlying error is I/O related, the seek should fail fast and the original exception will be re-raised. The output changes in test-http-bad-server.t demonstrate this. When the underlying error is not I/O related and the stream can be seeked, the old behavior is preserved.

error: rename RichIOError to PeerTransportError This is a more descriptive name. RichIOError was introduced just hours ago, so it doesn't need to be marked as BC.

httppeer: don't send empty Vary request header As part of writing test-http-bad-server.t, I noticed that some requests include an empty Vary HTTP request header. The Vary HTTP request header indicates which headers should be taken into account when determining if a cached response can be used. It also accepts the special value of "*". The previous code unconditionally added a Vary header. This could lead to an empty header value. While I don't believe this violates the HTTP spec, this is weird and just wastes bytes. So this patch changes behavior to only send a Vary header when it has a value. Some low-level wire protocol byte reporting tests changed. In some cases, the exact point of data termination changed. However, the behavior being tested - that clients react when the connection is closed in the middle of an HTTP request line or header - remains unchanged.

badserverext: explicitly flush each log write No idea why, but without this, there was no content in the error logs that are `cat`d in the test on Windows.

test-http-bad-server: conditionalize error output for Windows

test-tag: make hook runnable on Windows Simply setting the hook to *.sh causes Windows to open a dialog asking how to open *.sh files.

obsolescence: add test for the "branch replacement" logic during push, case D7 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. This changeset adds test for the improved "branch replacement" logic introduce in an earlier commits. This tests initially lived in the evolve extensions. Since we now have the code handling this logic in core, it make sense to have the tests in core too. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case D5 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. This changeset adds test for the improved "branch replacement" logic introduce in an earlier commits. This tests initially lived in the evolve extensions. Since we now have the code handling this logic in core, it make sense to have the tests in core too. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case D3 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. This changeset adds test for the improved "branch replacement" logic introduce in an earlier commits. This tests initially lived in the evolve extensions. Since we now have the code handling this logic in core, it make sense to have the tests in core too. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case B8 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. This changeset adds test for the improved "branch replacement" logic introduce in an earlier commits. This tests initially lived in the evolve extensions. Since we now have the code handling this logic in core, it make sense to have the tests in core too. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case B7 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. This changeset adds test for the improved "branch replacement" logic introduce in an earlier commits. This tests initially lived in the evolve extensions. Since we now have the code handling this logic in core, it make sense to have the tests in core too. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case B6 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. This changeset adds test for the improved "branch replacement" logic introduce in an earlier commits. This tests initially lived in the evolve extensions. Since we now have the code handling this logic in core, it make sense to have the tests in core too. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case B5 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. This changeset adds test for the improved "branch replacement" logic introduce in an earlier commits. This tests initially lived in the evolve extensions. Since we now have the code handling this logic in core, it make sense to have the tests in core too. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case B4 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. This changeset adds test for the improved "branch replacement" logic introduce in an earlier commits. This tests initially lived in the evolve extensions. Since we now have the code handling this logic in core, it make sense to have the tests in core too. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case B2 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. This changeset adds test for the improved "branch replacement" logic introduce in an earlier commits. This tests initially lived in the evolve extensions. Since we now have the code handling this logic in core, it make sense to have the tests in core too. See inline documentation for details about the test case added in this changeset.

checkheads: upgrade the obsolescence postprocessing logic (issue4354) The previous logic had many shortcoming (eg: looking at the head only, not handling prune, etc...), the new logic use a more robust approach: For each head, we check if after the push all changesets exclusive to this heads will be obsolete. If they are, the branch considered be "replaced". To check if a changeset will be obsolete, we simply checks: * the changeset phase * the existence of a marker relevant to the "pushed set" that affects the changesets.. This fixes two major issues of the previous algorithm: * branch partially rewritten (eg: head but not root) are no longer detected as replaced, * Prune are now properly handled. (This implementation was introduction in the evolve extension, version 6.0.0.) This new algorithm has an extended number of tests, a basic one is provided in this patch. The others will be introduced in their own changeset for clarity. In addition, we stop trying to process heads unknown locally, we do not have enough data to take an informed decision so we should stop pretending we do. This reflect a test that is now update.

test-http: add a (glob) for Windows I'm not sure why the glob was ineffective with $TESTTMP here, but replacing it with '*' works.

testlib: move the prune alias into a shell script for Windows Cramming all of this directly into an alias doesn't play nicely on Windows. Various test-exchange-obsmarkers-case-XX.t were failing with: abort: cannot select revision when creating marker It turned out that inside debugcommands.debugobsolete(), the following differed from Linux (where they were empty, at least in the case I debugged): 'rev': ['.`;'], 'template': "'{node}\\n'"

hidden: extract the code generating "filtered rev" error for wrapping The goal is to help experimentation in extensions (ie: evolve) around more advance messages.

serve: add support for Mercurial subrepositories I've been using `hg serve --web-conf ...` with a simple '/=projects/**' [paths] configuration for awhile without issue. Let's ditch the need for the manual configuration in this case, and limit the repos served to the actual subrepos. This doesn't attempt to handle the case where a new subrepo appears while the server is running. That could probably be handled with a hook if somebody wants it. But it's such a rare case, it probably doesn't matter for the temporary serves. The main repo is served at '/', just like a repository without subrepos. I'm not sure why the duplicate 'adding ...' lines appear on Linux. They don't appear on Windows (see 594dd384803c), so they are optional. Subrepositories that are configured with '../path' or absolute paths are not cloneable from the server. (They aren't cloneable locally either, unless they also exist at their configured source, perhaps via the share extension.) They are still served, so that they can be browsed, or cloned individually. If we care about that cloning someday, we can probably just add the extra entries to the webconf dictionary. Even if the entries use '../' to escape the root, only the related subrepositories would end up in the dictionary.

hgwebdir: allow a repository to be hosted at "/" This can be useful in general, but will also be useful for hosting subrepos, with the main repo at /.

httppeer: eliminate decompressresponse() proxy Now that the response instance itself is wrapped with error handling, we no longer need this code. This code became dead with the previous patch because the added code catches HTTPException and re-raises as something else.

httppeer: wrap HTTPResponse.read() globally There were a handful of places in the code where HTTPResponse.read() was called with no explicit error handling or with inconsistent error handling. In order to eliminate this class of bug, we globally swap out HTTPResponse.read() with a unified error handler. I initially attempted to fix all call sites. However, after going down that rabbit hole, I figured it was best to just change read() to do what we want. This appears to be a worthwhile change, as the tests demonstrate many of our uncaught exceptions go away. To better represent this class of failure, we introduce a new error type. The main benefit over IOError is it can hold a hint. I'm receptive to tweaking its name or inheritance.

tests: add tests for poorly behaving HTTP server I've spent several hours over the past few weeks investigating networking failures involving hg.mozilla.org. As part of this, it has become clear that the Mercurial client's error handling when it encounters network failures is far from robust. To prove this is true, I've devised a battery of tests simulating various network failures, notably premature connection closes. To achieve this, I've implemented an extension that monkeypatches the built-in HTTP server and hooks in at the socket level and allows various events to occur based on config options. For example, you can refuse to accept() a client socket or you can close() the socket after N bytes have been sent or received. The latter effectively simulates an unexpected connection drop (and these occur all the time in the real world). The new test file launches servers exhibiting various "bad" behaviors and points a client at them. As the many TODO comments in the test call attention to, Mercurial often displays unhelpful errors when network-related failures occur. This makes it difficult for users to understand what's going on and difficult for server administrators to pinpoint root causes without packet tracing. Upcoming patches will attempt to fix these error handling deficiencies.

phases: emit phases to pushkey protocol in deterministic order An upcoming test will report exact bytes sent over the wire protocol. Without this change, the ordering of phases listkey data is non-deterministic.

keepalive: send HTTP request headers in a deterministic order An upcoming patch will add low-level testing of the bytes being sent over the wire. As part of developing that test, I discovered that the order of headers in HTTP requests wasn't deterministic. This patch makes the order deterministic to make things easier to test.

revset: properly parse "descend" argument of followlines() We parse "descend" symbol as a Boolean using getboolean (prior extraction by getargsdict already checked that it is a symbol). In tests, check for error cases and vary Boolean values here and there.

revsetlang: add a getboolean helper function This will be used to parse followlines's "descend" argument.

track-tags: write all tag changes to a file The tag changes information we compute is now written to disk. This gives hooks full access to that data. The format picked for that file uses a 2 characters prefix for the action: -R: tag removed +A: tag added -M: tag moved (old value) +M: tag moved (new value) This format allows hooks to easily select the line that matters to them without having to post process the file too much. Here is a couple of examples: * to select all newly tagged changeset, match "^+", * to detect tag move, match "^.M", * to detect tag deletion, match "-R". Once again we rely on the fact the tag tests run through all possible situations to test this change.

track-tags: compute the actual differences between tags pre/post transaction We now compute the proper actuall differences between tags before and after the transaction. This catch a couple of false positives in the tests. The compute the full difference since we are about to make this data available to hooks in the next changeset.

track-tags: introduce first bits of tags tracking during transaction This changeset introduces detection of tags changes during transaction. When this happens a 'tag_moved=1' argument is set for hooks, similar to what we do for bookmarks and phases. This code is disabled by default as there are still various performance concerns. Some require a smarter use of our existing tag caches and some other require rework around the transaction logic to skip execution when unneeded. These performance improvements have been delayed, I would like to be able to experiment and stabilize the feature behavior first. Later changesets will push the concept further and provide a way for hooks to know what are the actual changes introduced by the transaction. Similar work is needed for the other families of changes (bookmark, phase, obsolescence, etc). Upgrade of the transaction logic will likely be performed at the same time. The current code can report some false positive when .hgtags file changes but resulting tags are unchanged. This will be fixed in the next changeset. For testing, we simply globally enable a hook in the tag test as all the possible tag update cases should exist there. A couple of them show the false positive mentioned above. See in code documentation for more details.

tags: introduce a function to return a valid fnodes list from revs This will get used to compare tags between two set of revisions during a transaction (pre and post heads). The end goal is to be able to track tags movement in transaction hooks.

context: possibly yield initial fctx in blockdescendants() If initial 'fctx' has changes in line range with respect to its parents, we yield it first. This makes 'followlines(..., descend=True)' consistent with 'descendants()' revset which yields the starting revision. We reuse one iteration of blockancestors() which does exactly what we want. In test-annotate.t, adjust 'startrev' in one case to cover the situation where the starting revision does not touch specified line range.

context: add an assertion checking linerange consistency in blockdescendants() If this assertion fails, this indicates a flaw in the algorithm. So fail fast instead of possibly producing wrong results. Also extend the target line range in test to catch a merge changeset with all its parents.

windows: add win32com.shell to demandimport ignore list Module 'appdirs' tries to import win32com.shell (and catch ImportError as an indication of failure) to check whether some further functionality should be implemented one or another way [1]. Of course, demandimport lets it down, so if we want appdirs to work we have to add it to demandimport's ignore list. The reason we want appdirs to work is becuase it is used by setuptools [2] to determine egg cache location. Only fairly recent versions of setuptools depend on this so people don't see this often. [1] https://github.com/ActiveState/appdirs/blob/master/appdirs.py#L560 [2] https://github.com/pypa/setuptools/blob/aae0a928119d2a178882c32bded02270e30d0273/pkg_resources/__init__.py#L1369

obsolescence: add test for the "branch replacement" logic during push, case D6 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test cases. See inline documentation for details about the test case added in this changeset.

obsolescence: add test dor the "branch replacement" logic during push, case D4 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test cases. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case D2 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test cases. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case D1 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test cases. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case C4 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test cases. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case C3 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test cases. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case C2 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test cases. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case B3 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test cases. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case A8 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test cases. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case A7 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test cases. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case A6 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test cases. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case A5 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test cases. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case A4 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test cases. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case A3 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test case. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case A2 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test case. See inline documentation for details about the test case added in this changeset.

obsolescence: add test for the "branch replacement" logic during push, case A1 Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test case. See inline documentation for details about the test case added in this changeset.

obsolescence: add test utility for the "branch replacement" logic during push Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. The current code for this logic is very basic (eg: issue4354) and was poorly tested. We have a better implementation coming in the evolve extension fixing these issues and with more serious tests coverage. In the process of upstreaming this improved logic, we start with adding the test case that are already passing with the current implementation. Once they are all in, we'll upstream the better implementation and the extra test case. This changeset introduce the common setup script used by these tests.

obsolescence: add test case D-4 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case D-4: unknown changeset in between known on Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case D-3 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case D3: missing prune target (prune not in "pushed set") Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case D-2 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce D-2: missing prune target (prune in "pushed set") Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case D-1 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case D-1: Pruned changeset based on missing precursor of something not present Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case C-4 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce C.4: multiple successors, one is pruned Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case C-3 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case C-3: Pruned changeset on precursors of another pruned one Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case C-2 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce C-2: Pruned changeset on precursors Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case C-1 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce C-1: Multiple pruned changeset atop each other Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

stdio: add Linux-specific tests for error checking

stdio: raise StdioError if something goes wrong in ui.flush The prior code used to ignore all errors, which was intended to deal with a decade-old problem with writing to broken pipes on Windows. However, that code inadvertantly went a lot further, making it impossible to detect *all* I/O errors on stdio ... but only sometimes. What actually happened was that if Mercurial wrote less than a stdio buffer's worth of output (the overwhelmingly common case for most commands), any error that occurred would get swallowed here. But if the buffering strategy changed, an unhandled IOError could be raised from any number of other locations. Because we now have a top-level StdioError handler, and ui._write and ui._write_err (and now flush!) will raise that exception, we have one rational place to detect and handle these errors.

stdio: raise StdioError if something goes wrong in ui._write_err The prior code used to ignore certain classes of error, which was not the right thing to do.

stdio: raise StdioError if something goes wrong in ui._write

stdio: catch StdioError in dispatch.run and clean up appropriately We attempt to report what went wrong, and more importantly exit the program with an error code. (The exception we catch is not yet raised anywhere in the code.)

stdio: add machinery to identify failed stdout/stderr writes Mercurial currently fails to notice failures to write to stdout or stderr. A correctly functioning command line tool should detect this and exit with an error code. To achieve this, we need a little extra plumbing, which we start adding here.

atexit: switch to home-grown implementation

atexit: test failing handlers

ui: add special-purpose atexit functionality In spite of its longstanding use, Python's built-in atexit code is not suitable for Mercurial's purposes, for several reasons: * Handlers run after application code has finished. * Because of this, the code that runs handlers swallows exceptions (since there's no possible stacktrace to associate errors with). If we're lucky, we'll get something spat out to stderr (if stderr still works), which of course isn't any use in a big deployment where it's important that exceptions get logged and aggregated. * Mercurial's current atexit handlers make unfortunate assumptions about process state (specifically stdio) that, coupled with the above problems, make it impossible to deal with certain categories of error (try "hg status > /dev/full" on a Linux box). * In Python 3, the atexit implementation is completely hidden, so we can't hijack the platform's atexit code to run handlers at a time of our choosing. As a result, here's a perfectly cromulent atexit-like implementation over which we have control. This lets us decide exactly when the handlers run (after each request has completed), and control what the process state is when that occurs (and afterwards).

context: follow all branches in blockdescendants() In the initial implementation of blockdescendants (and thus followlines(..., descend=True) revset), only the first branch encountered in descending direction was followed. Update the algorithm so that all children of a revision ('x' in code) are considered. Accordingly, we need to prevent a child revision to be yielded multiple times when it gets visited through different path, so we skip 'i' when this occurs. Finally, since we now consider all parents of a possible child touching a given line range, we take care of yielding the child if it has a diff in specified line range with at least one of its parent (same logic as blockancestors()).

pager: set some environment variables if they're not set Git did this already [1] [2]. We want this behavior too [3]. This provides a better default user experience (like, supporting colors) if users have things like "PAGER=less" set, which is not uncommon. The environment variables are provided by a method so extensions can override them on demand. [1]: https://github.com/git/git/blob/6a5ff7acb5965718cc7016c0ab6c601454fd7cde/pager.c#L87 [2]: https://github.com/git/git/blob/6a5ff7acb5965718cc7016c0ab6c601454fd7cde/Makefile#L1545 [3]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/094780.html

sshpeer: fix docstring typo

util: pass sysstrs to warnings.filterwarnings Un-breaks the Python 3 build.

vfs: deprecate all old classes in scmutil Now that all vfs class moved to the vfs module, we can deprecate the old one.

util: add a way to issue deprecation warning without a UI object Our current deprecation warning mechanism relies on ui object. They are case where we cannot have access to the UI object. On a general basis we avoid using the python mechanism for deprecation warning because up to Python 2.6 it is exposing warning to unsuspecting user who cannot do anything to deal with them. So we build a "safe" strategy to hide this warnings behind a flag in an environment variable. The test runner set this flag so that tests show these warning. This will help us marker API as deprecated for extensions to update their code.

gitweb: plug followlines UI in filerevision view Mostly copy CSS rules from style-paper.css into style-gitweb.css. The only modification is addition of !important on "background-color" rule for "pre.sourcelines > span.followlines-selected" selector as the background color is otherwise overriden by "pre.sourcelines.stripes > :nth-child(4n+4)" rule.

gitweb: handle "patch" query parameter in filelog view As for paper style, in f36dc643ffdc, we display "diff" data as an additional row in the table of revision entries for the gitweb template. Also, as these additional diff rows have a white background, they may be confused with log entry rows ("age", "author", "description", "links") of even parity (parity0 also have a white background). So we disable parity colors for log entry rows when diff is displayed and fix the color to the "dark" parity (i.e. parity1 #f6f6f0) so that it's always distinguishable from

gitweb: add information about "linerange" filtering in filelog view As for paper style, in 5e6d44511317, we display a "(following lines <fromline>:<toline> <a href='...'>back to filelog</a>)" message alongside the file name when "linerange" query parameter is present.

util: fix human-readable printing of negative byte counts Apply the same human-readable printing rules to negative byte counts as to positive ones. Fixes output of debugupgraderepo.

show: make template option actually show up in help Previously, the --template/-T option didn't show up in help because it's marked as experimental. It's not really experimental for show, and its quite important for show's funcationality, so let's make sure it always shows up.

show: implement underway view This is the beginning of a wip/smartlog view. It is basically a manually constructed (read: fast) revset function to collect "relevant" changesets combined with a custom template and a graph displayer. It obviously needs a lot of work. I'd like to get *something* usable in 4.2 so `hg show` has some value to end-users. Let the bikeshedding begin.

show: fix formatting of multiple commands Because we're formatting to RST, short lines wrap and there needs to be an extra line break between paragraphs to prevent that. In addition, the indentation in the old code was a bit off. Refactor the code to a function (so we don't leak variables outside the module) and modify it so it renders more correctly.

pycompat: import correct cookie module on Python 3 http.cookielib doesn't exist. http.cookiejar does and it contains the symbols we need. This fixes test failures on Python 3.

chg: respect environment variables for pager Previously chg runs the pager command without respecting its environment variables being told to use. This patch makes it so.

hgweb: add a link to followlines in descending direction We change the content of the followlines popup to display two links inviting to follow the history of selected lines in ascending (as before) and descending directions. The popup now renders as: follow history of lines <fromline>:<toline>: <a href=...>ascending</a> / <a href=...>descending</a>

hgweb: handle a "descend" query parameter in filelog command When this "descend" query parameter is present along with "linerange" parameter, we get revisions following line range in descending order. The parameter has no effect without "linerange".

revset: add a 'descend' argument to followlines to return descendants This is useful to follow changes in a block of lines forward in the history (for instance, when one wants to find out how a function evolved from a point in history). We added a 'descend' parameter to followlines(), which defaults to False. If True, followlines() returns descendants of startrev. Because context.blockdescendants() does not follow renames, these are not followed by the revset either, so history will end when a rename occurs (as can be seen in tests).

context: add a blockdescendants function This is symmetrical with blockancestors() and yields descendants of a filectx with changes in the given line range. The noticeable difference is that the algorithm does not follow renames (probably because filelog.descendants() does not), so we are missing branches with renames.

url: support auth.cookiesfile for adding cookies to HTTP requests Mercurial can't currently send cookies as part of HTTP requests. Some authentication systems use cookies. So, it seems like adding support for sending cookies seems like a useful feature. This patch implements support for reading cookies from a file and automatically sending them as part of the request. We rely on the "cookiejar" Python module to do the heavy lifting of parsing cookies files. We currently only support the Mozilla (really Netscape-era) cookie format. There is another format supported by cookielib and we may want to consider using that, especially since the Netscape cookie parser can't parse ports. It wasn't immediately obvious to me what the format of the other parser is, so I didn't know how to test it. I /think/ it might be literal "Cookie" header values, but I'm not sure. If it is more robust than the Netscape format, we may want to just support it.

httpconnection: allow a global auth.cookiefile config entry This foreshadows support for defining a cookies file.

util: make cookielib module available In preparation for supporting sending cookies on HTTP requests.

crecord: avoid setting non-existing SIGTSTP signal on windows (issue5512) Windows do not have a SIGTSTP so we avoid setting the handler if the signal is unknown.

crecord: ensure we reinstall the SIGTSTP handler Previous, exceptions would prevent the reinstallation of the signal.

crecord: avoid setting non-existing signal SIGWINCH on windows Windows do not have a SIGWINCH so we avoid setting the handler if the signal is unknown.

crecord: ensure we reinstall the SIGWINCH handler Previous, exception in _main(...) would prevent the reinstallation of the signal.

crecord: extract most of 'main' into a sub function There are some setup and cleanup necessary around the main code, that setup/cleanup code needs multiple adjustments so we extract the core code into its own function first for clarity.

templater: add shorthand for building a dict like {"key": key} Like field init shorthand of Rust. This is convenient for building a JSON object from selected keywords. This means dict() won't support Python-like dict(iterable) syntax because it's ambiguous. Perhaps it could be implemented as 'mapdict(xs % (k, v))'.

templater: find keyword name more thoroughly on filtering error Before, it could spill an internal representation of compiled template such as [(<function runsymbol at 0x....>, 'extras'), ...]. Show less cryptic message if no symbol found. New findsymbolicname() function will be also used by dict() constructor.

templater: add dict() constructor It's troublesome to build JSON by template, so let's add programmatic way.

templatekw: add public function to wrap a dict by _hybrid object

templatekw: add public function to wrap a list by _hybrid object

templatekw: add default implementation of _hybrid.gen This is convenient for new template keyword, which doesn't need to support the legacy list hack (provided by _showlist()), but still wants to have a string representation.

parser: preserve order of keyword arguments This helps building dict(key1=value1, ...) in deterministic way.

parser: extend buildargsdict() to support arbitrary number of **kwargs Prepares for adding dict(key1=value1, ...) template function. More tests will be added later.

parser: verify excessive number of args excluding kwargs in buildargsdict() This makes the next patch slightly simpler. We don't need to check the excessive number of keyword arguments since unknown and duplicated kwargs are rejected.

obsolescence: add test case B-7 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case B-7: Prune above non-targeted common changeset Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case B-6 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case B6: Pruned changeset with precursors not in pushed set Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case B-5 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce B-5: Push of a children of changeset which successors is pruned Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case B-4 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case B4: Pruned changeset on common part of history Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case B-3 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case B3: Pruned changeset on non-pushed part of the history Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case B-2 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case B-2: Prune on targeted common changeset Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case B-1 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case B-1: Prune on non-targeted common changeset Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case A-7 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case A-7: non targeted common changeset Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case A-6 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case A6: new markers between changesets already known on both side Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case A-5 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case A-5: partial reordering Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case A-4 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case A-4: Push in the middle of the obsolescence chain Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case A-3 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case A3: new branchs created, one pushed Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case A-2 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case A-2: Two heads, only one of them pushed Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add test case A-1 for obsolescence markers exchange About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce case A-1: pushing a single head Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

obsolescence: add setup script for obsolescence markers exchange tests About 3 years ago, in August 2014, the logic to select what markers to select on push was ported from the evolve extension to Mercurial core. However, for some unclear reasons, the tests for that logic were not ported alongside. I realised it a couple of weeks ago while working on another push related issue. I've made a clean up pass on the tests and they are now ready to integrate the core test suite. This series of changesets do not change any logic. I just adds test for logic that has been around for about 10 versions of Mercurial. They are a patch for each test case. It makes it easier to review and postpone one with documentation issues without rejecting the wholes series. This patch introduce the common script that setup the basic environment for the test cases. Once this script is in. We can accept the other patches in any order. Each test case comes it in own test file. It help parallelism and does not introduce a significant overhead from having a single unified giant test file. Here are timing to support this claim. # Multiple test files version: # run-tests.py --local -j 1 test-exchange-*.t 53.40s user 6.82s system 85% cpu 1:10.76 total 52.79s user 6.97s system 85% cpu 1:09.97 total 52.94s user 6.82s system 85% cpu 1:09.69 total # Single test file version: # run-tests.py --local -j 1 test-exchange-obsmarkers.t 52.97s user 6.85s system 85% cpu 1:10.10 total 52.64s user 6.79s system 85% cpu 1:09.63 total 53.70s user 7.00s system 85% cpu 1:11.17 total

upgrade: simplify the "origin" dispatch in dry run We could compute the final set we need directly.

upgrade: use 'improvement' object for action too This simplify multiple pieces of code. For now we restrict this upgrade to the top level function to keep this patch simple.

upgrade: implement equality for 'improvement' object Through the code, we use a mix of 'improvement' object and string. Having a single type would be simpler. For this we need the object to be comparable.

upgrade: simplify some of the initial dispatch for dry run Since we already have the list of deficiencies, we can use it directly.

upgrade: simplify 'determineactions' Since we only takes 'deficiencies', we can simplify the function and clarify its arguments.

upgrade: filter optimizations outside of 'determineactions' This sounds like higher level logic to process arguments. Moving it out of 'determineactions' will allow passing only deficiencies to the function. Then, in a future changeset, we will remove dispatch on "improvement type" within the function. See next changeset for details.

upgrade: directly iterate over optimisations Since we already have the list of optimisations independent from the deficiencies, we can use it directly. (we make a dual assignement in this changeset to simplify the next one)

upgrade: simplify optimisations validation Since we fetch optimizations distinctly from the deficiencies, we can simplify some code.

upgrade: split finding deficiencies from finding optimisations Our ultimate goal is to make it easier to get a diagnostic of the repository format. A first important and step for that is to separate part related to repository format from the optimisation. We start by having two different functions returning the two categories of possible "improvement".

upgrade: update the copyright statement

upgrade: update the header comment

upgrade: import 'localrepo' globally The in-function imports mention a cycle that seems to no longer be relevant. As a result, we just import it globally.

largefiles: set the extension as enabled locally after a share requiring it This has been done for clone since e1dbe0b215ae, so it makes sense here for the same reasons.

windows: add context manager support to mixedfilemodewrapper I stumbled into this in the next patch. The difference between getting a context manager capable object or not from vfs classes was as subtle as adding a '+' to the file mode.

chg: always wait for pager Previously, when runcommand raises, chg aborts with, and does not wait for pager. The call stack is like: hgc_runcommand -> handleresponse -> readchannel -> debugmsg("failed to read channel") -> exit(255) That means, chg returns to the shell, then both the pager and the shell will read from the terminal at the same time, causing problems. This patch fixes that by using "atexit" to register the pager cleanup function so chg will always wait for pager even if runcommand raises.

bundle2: move 'seek' and 'tell' methods off the unpackermixin class These methods are unrelated to unpacking. They are used internally by the 'unbundlepart' class only. So me move them there as private methods. In the same go, we clarify their internal role in the their docstring.

shelve: rename nodestoprune to nodestoremove As per feedback from the community.

templater: port pad() to take keyword arguments This is another example where keyword arguments can be actually useful.

templater: add support for keyword arguments Unlike revset, function arguments are pre-processed in templater. That's why we need to define argspec per function. An argspec field looks somewhat redundant in @templatefunc definition as a name field contains human-readable list of arguments. I'll make function doc be built from argspec later. Ported separate() function as an example.

templater: add parsing rule for key-value pair Based on the revset implementation, 70a2082f855a. This patch also adjusts the test as '=' is now a valid token.

templater: adjust binding strengths to make room for key-value operator Changed as follows: - template ops (%, |): +10 - arithmetic ops: +1 (but "negate" should be greater than "%")

templater: sort token table by binding strength Just for readability.

templater: make _hybrid provide more list/dict-like methods So the JSON filter works.

templater: hide private variable of _hybrid

templater: remove __iter__() from _hybrid, resolve it explicitly The goal is to fix "{hybrid_obj|json}" output. A _hybrid object must act as a list or a dict as well as a generator of legacy template strings. Before, _hybrid.__iter__() was assigned for legacy template, which conflicted with list.__iter__() API. This patch drops _hybrid.__iter__() and makes stringify/flatten functions unwrap a generator instead.

templater: rewrite doc of _hybrid class as docstring

sortdict: fix .pop() to return a value My future patch will need it.

checkcode: only match pushd/popd as word otherwise it partially match common words like "pushdestination".

treemanifest: add walksubtrees api Adds a new function to treemanifest that allows walking over the directories in the tree. Currently it only accepts a matcher to prune the walk, but in the future it will also accept a list of trees and will only walk over subtrees that differ from the versions in the list. This will be useful for identifying what parts of the tree are new to this revision, which is useful when deciding the minimal set of trees to send to a client given that they have a certain tree already. Since this is intended for an extension to use, the only current consumer is a test. In the future this function may be useful for implementing other algorithms like diff and changegroup generation.

merge with stable

upgrade: drop the prefix to the '_finishdatamigration' function Now that we are in the 'upgrade' module we can simplify the name.

upgrade: drop the prefix to the '_filterstorefile' function Now that we are in the 'upgrade' module we can simplify the name.

upgrade: drop the prefix to the 'determineactions' function Now that we are in the 'upgrade' module we can simplify the name.

upgrade: drop the prefix to the 'findimprovements' function Now that we are in the 'upgrade' module we can simplify the name.

upgrade: drop the prefix to the 'supporteddestrequirements' function Now that we are in the 'upgrade' module we can simplify the name.

upgrade: drop the prefix to the 'allowednewrequirements' function Now that we are in the 'upgrade' module we can simplify the name.

upgrade: drop the prefix to the 'improvement' class Now that we are in the 'upgrade' module we can simplify the name.

upgrade: drop the prefix to the 'supportremovedrequirements' function Now that we are in the 'upgrade' module we can simplify the name.

upgrade: drop the prefix to the 'blocksourcerequirements' function Now that we are in the 'upgrade' module we can simplify the name.

upgrade: drop the prefix to the 'requiredsourcerequirements' function Now that we are in the 'upgrade' module we can simplify the name.

upgrade: extract code in its own module Given about 2/3 or 'mercurial.repair' is now about repository upgrade, I think it is fair to move it into its own module. An expected benefit is the ability to drop the 'upgrade' prefix of many functions. This will be done in coming changesets.

bundle2: move the 'close' method off the unpackermixin This method is unrelated to unpacking and only used by the unbundle20 class. We move it there for clarity.

bundle2: clarify the docstring of unpackermixin methods The unpackermixin is a utility used to implement the bundle2 protocol. It should not be used when writing part handlers. We update the docstring to clarify this.

bundle2: add documention to 'part.addparams' There are some non-obvious limitations on the parameters of this method. Add some documentation where people will likely look to understand how to use this API.

test-patchbomb: disable sendmail tests on Windows These tests were failing, and there isn't a trivial way to execute a script on Windows [1]. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096497.html

show: fix corrupt json output with no bookmarks

show: tweak plain abort language for clarity

tests: print Unix style paths in *.py tests These tests don't support (glob). I didn't audit all tests, but these ones were failing.

revlog: make "size" diverge from "rawsize" Previously, revlog.size equals to revlog.rawsize. However, the flag processor framework could make a difference - "size" could mean the length of len(revision(raw=False)), while "rawsize" means len(revision(raw=True)). This patch makes it so. This corrects "hg status" output when flag processor is involved. The call stack looks like: basectx.status -> workingctx._buildstatus -> workingctx._dirstatestatus -> workingctx._checklookup -> filectx.cmp -> filelog.cmp -> filelog.size -> revlog.size

test-flagprocessor: add a case about hg status This shows how "hg status" is wrong - nothing changed but the file is labeled as "M".

test-http-proxy: add the Windows variant of "connection refused" The full error is "No connection could be made because the target machine actively refused it".

test-fileset: eliminate a duplicate test that was conditionalized for output

test-fileset: glob away hash differences There are various files committed above that can't be used on Windows because of the name, or being a symlink.

test-bundle: glob away a URL protocol separator MSYS thinks the ':' is a Unix path separator, and replaces it with ';'.

templatekw: clarify the result of {latesttag} when no tag exists My initial expectation was that the list would be empty, and therefore detectable with {if()}. The map for {latesttag()} is populated with real values in this case (except {tag}), so it probably doesn't make any sense to change this to an empty list.

hgweb: position the "followlines" box close to latest cursor position

hgweb: add a floating tooltip to invite on followlines action In followlines.js, we create a <div id="followlines-tooltip"> element to draw attention of users on "followlines" feature. The element shows up on hover of source lines after one second and follows the cursor. After first click (start line selection), the text changes and indicates that next click will terminate selection.

zstd: vendor python-zstandard 0.8.1 This contains a fix for compilation on BSDs. #no-check-commit

fsmonitor: match watchman and filesystem encoding watchman's paths encoding can differ from filesystem encoding. For example, on Windows, it's always utf-8. Before this patch, on Windows, mismatch in path comparison between fsmonitor state and osutil.statfiles would yield a clean status for added/modified files. In addition to status reporting wrong results, this leads to files being discarded from changesets while doing history editing operations such as rebase. Benchmark: There is a little overhead at module import: python -m timeit "import hgext.fsmonitor" Windows before patch: 1000000 loops, best of 3: 0.563 usec per loop Windows after patch: 1000000 loops, best of 3: 0.583 usec per loop Linx before patch: 1000000 loops, best of 3: 0.579 usec per loop Linux after patch: 1000000 loops, best of 3: 0.588 usec per loop 10000 calls to _watchmantofsencoding: python -m timeit -s "from hgext.fsmonitor import _watchmantofsencoding, _fixencoding" "fname = '/path/to/file'" "for i in range(10000):" " if _fixencoding: fname = _watchmantofsencoding(fname)" Windows (_fixencoding is True): 100 loops, best of 3: 19.5 msec per loop Linux (_fixencoding is False): 100 loops, best of 3: 3.08 msec per loop

pull: abort pull --update if config requires destination (issue5528)

tests: move update requiredest test to own test file More tests for this flag are coming in upcoming patches.

py3: add pycompat.unicode and add it to importer On python 3, builtins.unicode does not exist.

py3: add a bytes version of urllib.parse.urlencode() to pycompat.py urllib.parse.urlencode() returns unicodes on Python 3. This commit adds a method which will take its output and encode it to bytes so that we can use bytes consistently.

py3: replace str() with bytes()

metadataonlyctx: replace "changeset()[0]" to "manifestnode()" As Yuya pointed out [1], "changeset()[0]" could be simplified to "manifestnode()". I didn't notice that method earlier. It should definitely be used - it's easier to read, and faster. [1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/095716.html

test-check-pylint: match its output "pylint --version" shows: pylint 2.0.0, astroid 1.5.0 Python 2.7.13 (default, Dec 21 2016, 07:16:46) [GCC 6.2.1 20160830] I got "Your code has been rated at 10.00/10" every time and didn't know how to turn it off. Therefore the fix.

test-flagprocessor: remove unnecessary greps The "2>&1 | egrep ..." code is used for removing uninteresting parts from tracebacks. Now the test does not dump tracebacks, they can be removed.

bundlerepo: use raw revision in revdiff() This is similar to "revlog: use raw revisions in revdiff". revdiff() generates raw text used in revlog directly. This makes test-flagprocessor.t happy.

bundlerepo: fix raw handling in revision() Similar to fixes in revlog.py, this patch uses "rawtext" to explicitly label contents expected to be raw, and makes sure content stored in _cache is raw text. Now test-flagprocessor.t points us to another issue.

bundlerepo: build revlog index with flags This fixes bundlerevlog.flags(rev) for any revisions provided by the bundle. Now test-flagprocessor.t points us to another issue.

bundlerepo: make baserevision return raw text "baserevision" returns the text that will be used to apply deltas. Since deltas are against raw texts, "baserevision" should return raw text. Now test-flagprocessor.t points us to a new error.

test-flagprocessor: add tests about bundlerepo This shows flag processor is broken with a bundle repo. The test creates non-liner history to exercise code path where the deltaparent cannot be reused.

test-flagprocessor: use changegroup3 in bundle2 This will force "hg bundle" to use changegroup3 in the test. It is important since only changegroup3 preserves revlog flags.

bundle: allow bundle command to use changegroup3 in tests Since bundle2 writes changegroup version, we can just reuse the bundle2 format for changegroup3. This won't enable the bundle command to write changegroup3 in the wild, since exchange.parsebundlespec only returns changegroup2. It unlocks tests to override exchange.parsebundlespec and get "hg bundle" write changegroup3.

tests: add per-line output conditionals for Windows

run-tests: support per-line conditional output in tests Duplicating entire tests just because the output is different is both error prone and can make the tests harder to read. This harnesses the existing '(?)' infrastructure, both to improve readability, and because it seemed like the path of least resistance. The form is: $ test_cmd output (hghave-feature !) # required if hghave.has_feature(), else optional out2 (no-hghave-feature2 !) # req if not hghave.has_feature2(), else optional I originally extended the '(?)' syntax. For example, this: 2 r4/.hg/cache/checkisexec (execbit ?) pretty naturally reads as "checkisexec, if execbit". In some ways though, this inverts the meaning of '?'. For '(?)', the line is purely optional. In the example, it is mandatory iff execbit. Otherwise, it is carried forward as optional, to preserve the test output. I tried it the other way, (listing 'no-exec' in the example), but that is too confusing to read. Kostia suggested using '!', and that seems fine.

test-run-tests: pad the failure test to preserve the run order Test size seems to dictate the order in which the tests are run, and the next patch will add to test-success.t. Similar to c0cecc153d25.

run-tests: prevent a (glob) declaration from reordering (?) lines Previously, if a series of optional output lines marked with '(?)' had a (glob) in one of the first lines, the output would be reordered such that it came last if none of the lines were output. The (re) declaration wasn't affected, which was helpful in figuring this out. There were no tests for '(re) (?)' so add that to make sure everything plays nice.

py3: use pycompat.byteskwargs() to convert opts to bytes We have converted opts to unicodes before passing them.

test-check-code: do not use xargs We have too many files, and passing them via arguments could cause strange errors on some platforms [1]. Since check-code.py can now take "-" and read file names from stdin, use it instead of xargs to avoid the argv size limit. [1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096346.html

check-code: use "-" to specify a list of files from stdin This will be used by the next patch.

perf: add historical portability for util.timer util.timer has been introduced in ae5d60bb and used in perf.py since 22fbca1d. For historical portability, forcibly define util.timer in perf.py

diff: add --binary option for git mode diffs This patch adds --binary option to `hg diff` and `hg export` to allow more control about when binary diffs are displayed in Git mode as well as some tests to verify it behaves correctly (issue5510).

patch: make diff in git mode respect --text option (issue5510) This changeset makes patch respect -a/--text option in --git mode by aligning its behaviour with git itself.

py3: have registrar process docstrings in bytes Mixing bytes and unicode creates a mess. Do things in bytes as possible. New sysbytes() helper only takes care of ASCII characters, but avoids raising nasty unicode exception. This is the same design principle as sysstr().

localrepo: fix deprecation version for 'repo._link' The patch lingered for a while and nobody noticed when it was resubmitted.

localrepo: fix deprecation version for 'repo.join' The patch lingered for a while and nobody noticed when it was resubmitted.

tests: make zstd-related output optional Caught by the buildbot with --pure, fix suggested by indygreg.

check-code: update test IP address enforcement checks Instead of mentioning 127.0.0.1, we should use $LOCALIP. Anytime $LOCALIP appears in output, we should make sure we use (glob) on that line of output so that weird environments that do remapping jiggery pokery (such as our FreeBSD buildbot that's in a jail) don't get spurious test failures.

tests: fix missing (glob) annotations in test-push-http.t

tests: fix missing (glob) annotations in test-push-http-bundle1.t

tests: fix missing (glob) annotations in test-https.t

tests: fix missing (glob) annotations in test-bundle2-exchange.t

util: fix %-formatting on docstring by moving a closing parenthesis We have to do the % formatting over the sysstr, since the things we're going to splat into it are themselves sysstrs. This is probably technically wrong-ish, since bt is probably actually a bytestr here, but this fixes the immediate issue, which was that hg was broken on Python 3.

revset: stop supporting plain list as input set (API) There was no deprecwarn(), but this is the same kind of API compatibility as the one removed by the previous patch.

revset: stop supporting predicate that returns plain list (API) It's said to be removed after 3.9.

mdiff: add a hunkinrange helper function This factors out hunk filtering logic by line range that is similar in mdiff.blocksinrange() and hgweb.webutil.diffs().

templater: provide loop counter as "index" keyword This was originally written for JSON templating where we would have to be careful to not add extra comma, but seems generally useful. Inner loop started by % operator has its own counter.

templater: rename variable "i" to "v" in runmap() I want to reuse "i" for index.

formatter: reorder code that builds template mapping This makes the future patch slightly simpler.

revlog: avoid applying delta chain on cache hit Previously, revlog.revision(raw=False) may try to apply the delta chain on _cache hit. That happens if flags are non-empty. This patch makes rawtext reused so delta chain application is avoided. "_cache" and "rev" are moved a bit to avoid unnecessary assignments.

revlog: indent block to make review easier

revlog: avoid calculating "flags" twice in revision() This is more consistent with other code in "revision()" - prefer performance to code length.

revlog: use raw revision for rawsize When writing the revlog-ng index, the third field is len(rawtext). See revlog._addrevision: textlen = len(rawtext) .... e = (offset_type(offset, flags), l, textlen, base, link, p1r, p2r, node) self.index.insert(-1, e) Therefore, revlog.index[rev][2] returned by revlog.rawsize should be len(rawtext), where "rawtext" is revlog.revision(raw=True). Unfortunately it's hard to add a test for this code path because "if l >= 0" catches most cases.

revsetlang: enable optimization of 'x + y' expression It's been disabled since 4d1e56b29a91, but it can be enabled now as the ordering requirement is resolved at analyze().

zstd: vendor python-zstandard 0.8.0 Commit 81e1f5bbf1fc54808649562d3ed829730765c540 from https://github.com/indygreg/python-zstandard is imported without modifications (other than removing unwanted files). Updates relevant to Mercurial include: * Support for multi-threaded compression (we can use this for bundle and wire protocol compression). * APIs for batch compression and decompression operations using multiple threads and optimal memory allocation mechanism. (Can be useful for revlog perf improvements.) * A ``BufferWithSegments`` type that models a single memory buffer containing N discrete items of known lengths. This type can be used for very efficient 0-copy data operations. # no-check-commit

commands: update help for "unbundle" Similar to the recent change to "bundle," this command no longer just deals with "changegroup" data.

commands: update help for "bundle" We now have a dedicated help topic to describe bundle specification strings. Let's update `hg bundle`'s documentation to reflect its existence. While I was hear, I also tweaked some wording which I felt was out of date and needed tweaking. Specifically, `hg bundle` no longer just deals with "changegroup" data: it can also generate files that have non-changegroup data.

help: document bundle specifications I softly formalized the concept of a "bundle specification" a while ago when I was working on clone bundles and stream clone bundles and wanted a more robust way to define what exactly is in a bundle file. The concept has existed for a while. Since it is part of the clone bundles feature and exposed to the user via the "-t" argument to `hg bundle`, it is something we need to support for the long haul. After the 4.1 release, I heard a few people comment that they didn't realize you could generate zstd bundles with `hg bundle`. I'm partially to blame for not documenting it in bundle's docstring. Additionally, I added a hacky, experimental feature for controlling the compression level of bundles in 76104a4899ad. As the commit message says, I went with a quick and dirty solution out of time constraints. Furthermore, I wanted to eventually store this configuration in the "bundlespec" so it could be made more flexible. Given: a) bundlespecs are here to stay b) we don't have great documentation over what they are, despite being a user-facing feature c) the list of available compression engines and their behavior isn't exposed d) we need an extensible place to modify behavior of compression engines I want to move forward with formalizing bundlespecs as a user-facing feature. This commit does that by introducing a "bundlespec" help page. Leaning on the just-added compression engine documentation and API, the topic also conveniently lists available compression engines and details about them. This makes features like zstd bundle compression more discoverable. e.g. you can now `hg help -k zstd` and it lists the "bundlespec" topic.

util: document bundle compression An upcoming patch will add support for documenting bundle specifications in more detail. As part of this, we'd like to enumerate available bundle compression formats. In order to do this, we need to provide the help mechanism a dict of names and objects with docstrings. This patch adds docstrings to compengine.bundletype and adds a function for retrieving a dict of them. The code is not yet used.

tests: store ETag when using --headeronly Previously, --headeronly would prevent --twice from working because the ETag wasn't stored when --headeronly was used. This feels like a bug. That feeling is reaffirmed by the fact that this change doesn't regress any tests.

hgweb: extract path traversal checking into standalone function A common exploit in web applications that access paths is to insert path separator strings like ".." to try to get the server to serve up files it shouldn't. We have code for detecting this in staticfile(). A subsequent commit will need to perform this test as well. Since this is security code, let's factor the check so we don't have to reinvent the wheel.

hgweb: use context manager for file I/O

tags: rename "head" to "node" where we don't care Followup to 5eb4d206202b (tags: extract fnode retrieval into its own function, 2017-03-28) in which the "for head in head" became "for head in nodes".

manifest: update comment to be about bytearray Looks like a leftover from 2a18e9e6ca43 (py3: use bytearray() instead of array('c', ...) constructions, 2017-03-12).

check-code: fix "covert" typo

hgweb: rename linerangelog.js as followlines.js So that the file name matches both the feature name and user facing vocabulary (e.g. the revset function).

hgweb: rely on a specific class to change cursor type in followlines UI The previous CSS rule would also apply in pages where followlines UI was not available (e.g. "changeset" view at /rev/<node>/). We insert a "followlines-select" class in JavaScript on actually selectable lines and restrict the CSS selector to use it.

hgweb: use a function expression for the install listener of followlines UI We define the listener of document's "DOMContentLoaded" inline in registration and use a function expression (anonymous) with everything inside. This makes it clearer that this file is not a library of JavaScript functions but rather an executable script. (Most of changes consists of reindenting the "followlinesBox" function, so mostly white space changes.)

formatter: use templatefilters.json() Now _jsonifyobj() is identical to templatefilters.json(paranoid=False).

templatefilters: use list comprehension in json() Not important, but the code slightly looks better.

templatefilters: unroll handling of None/False/True It doesn't make sense to use a dict here.

templatefilters: drop callable support from json() This backs out ae5447de4c11. A callable should be evaluated beforehand by templater.runsymbol().

ui: use bytes IO and convert EOL manually in ui.editor() Text IO sucks on Python 3 as it must be a unicode stream. We could introduce a wrapper that converts unicode back to bytes, but it wouldn't be simple to handle offsets transparently from/to underlying IOBase API. Fortunately, we don't need to process huge text files, so let's stick to bytes IO and convert EOL in memory.

util: add helper to convert between LF and native EOL See the next patch for why.

util: extract pure tolf/tocrlf() functions from eol extension This can be used for EOL conversion of text files.

pycompat: provide bytes os.linesep

pycompat: introduce identity function as a compat stub I was sometimes too lazy to use 'str' instead of 'lambda a: a'. Let's add a named function for that purpose.

test-blackbox: glob away quoting differences on Windows Windows uses double quotes in these places.

test-subrepo: update output for Windows

test-serve: disable unfixable tests on Windows These tests would run if hghave.has_serve() were enabled on Windows. Windows has no issue allowing an unpriviledged process to open port 13, so it doesn't abort. The other tests are related to how MSYS tries to be helpful and converts Unix constructs to the Windows equivalent. There isn't any way to disable this behavior, though it supposedly doesn't happen if the exe is linked against the MSYS library.