tests: avoid nested quoting on command line for portability Before this patch, test-revset.t fails on Solaris using ksh as default "sh", because nested quoting below isn't acceptable for it. +-----------------------------+ inner quoting "`python -c "print '|'.join(['0:1'] * 500)"`" +-------------------------------------------+ outer quoting This patch does below for portability. - omit outer quoting This should be safe, because generated string contains no white space character. - use '+' instead of '|' (for safety) '|' has special meaning for many shell, but '+' isn't (at least, for ordinary ones).

version: verbose list internal and external extension source (issue4731)

check-code: allow "grep pattern filename-containing-dash-a" We're trying to forbid "grep -a" and unintentionally complained even if the "-a" was part of the filename. Requiring a space before "-a" to match is probably good enough.

rebase: update working directory when aborting (issue5084)

revset: flatten chained 'list' operations (aka function args) (issue5072) Internal _matchfiles() function can take bunch of arguments, which would lead to a maximum recursion depth error. This patch avoids the excessive stack use by flattening 'list' nodes beforehand. Since getlist() no longer takes a nested 'list' nodes, _parsealiasdecl() also needs to flatten argument list, "aliasname($1, $2, ...)".

help: fix typo in backgroundclose documentation

revert: makes interactive mode ask to forget added files (issue4936) Before this patch revert interactive mode unconditionally forgets added files. This patch fixes this by asking user if he wants to forget added file. If user doesn't want to forget given file, it is added to matcher_opts exclude list, to not reviewing it later with other modified files.

obsolete: fix n^2 marker computation behavior Previously, if you ran obsolete.createmarkers with a bunch of markers that did not have successors (like when you do a prune), it encountered a n^2 computation behavior because the loop would read the changelog (to get ctx.parents()), then add a marker, in a loop. Adding a marker invalidated the computehidden cache, and reading the changelog recomputed it. This resulted in pruning 150 commits taking 150+ seconds in a large repo. The fix is to break the reading part of the loop to be separate from the writing part.

memctx: fix memctx manifest file hashes When memctx is asked for a manifest, it constructs one by merging the p1 manifest, and the changes that are on top. For the changes on top, it was previously using p1.node() as the file entries parent, which actually returns the commit node that the p1 linkrev points at! Which is entirely incorrect. The fix is to use p1.filenode() instead, which returns the parent file node as desired. I don't know how to execute this or make it have a visible effect, so I'm not sure how to test it. It was noticed because asking for the linkrev is an expensive operation when using the remotefilelog extension and this was causing performance regressions with commit.

schemes: add debugexpandscheme command, resolving a scheme to canonical form

schemes: extract scheme expansion as its own method on ShortRepository

merge with stable

Added signature for changeset b698abf971e7

Added tag 3.7.1 for changeset b698abf971e7

rebase: don't preserve most extra fields This backs out changeset 88fde8db5307. See the previous patches for why.

rebase: backout changeset d755a9531fce This is a dependency for a future backout of 88fde8db5307. See the previous patches for why.

rebase: backout changeset 986d04b9fedd This is a dependency for a future backout of 88fde8db5307. See the previous patches for why.

graft: don't preserve most extra fields This backs out changeset 804abe8999f3. See the previous patch for why we're doing this.

amend: don't preserve most extra fields This backs out changeset 39163708825cd. There are some extra fields that absolutely should not be preserved, like the convert_revision field introduced by the convert and hgsubversion extensions. The problem with extensions blacklisting certain extra fields is that they might not be enabled at the time the amend is performed. In the long run we probably want separately marked transferable and non-transferable extra fields, but for now restore the old Mercurial 3.6 behavior.

histedit: fix typo in documentation

osutil: do not abort loading pure module just because libc has no recvmsg() On Solaris, recvmsg() is provided by libsocket.so. We could try hard to look for the library which provides 'recvmsg' symbol, but it would make little sense now since recvfds() won't work anyway on Solaris. So this patch just disables _recvmsg() on such platforms. Thanks to FUJIWARA Katsunori for spotting this problem.

osutil: disable compilation of recvfds() on unsupported platforms It appears that Solaris doesn't provide CMSG_LEN(), msg_control, etc. As recvfds() is only necessary for chg, this patch just drops it if CMSG_LEN isn't defined, which is the same workaround as Python 3.x. https://hg.python.org/cpython/rev/c64216addd7f#l7.33

i18n-pt_BR: synchronized with 0ec12435b78b

merge with stable

Added signature for changeset 2408645de650

Added tag 3.7 for changeset 2408645de650

merge with i18n

verify: recover lost freeing of memory In df8973e1fb45 (verify: move file cross checking to its own function, 2016-01-05), "mflinkrevs = None" was moved into function, so the reference was cleared there, but the calling function now held on to the variable. The point of clearing it was presumably to free up memory, so let's move the clearing to the calling function where it makes a difference. Also change "mflinkrevs = None" to "del mflinkrevs", since the comment about scope now surely is obsolete.

rebase: better way to detect non-detaching revisions (issue5044) Rather than look for the lowest revision, see if the rebase state is tracking the parents of this revision. Otherwise we can't handle multiple revisions in one rebase that includes a merge revision. Fixes issue5044.

i18n-ja: synchronized with 88609cfa3745

i18n-pt_BR: synchronized with f0d3c5794380

doc: itemize text blocks to increase readability in HTML format Before this patch, text blocks changed in this patch are shown as just continuous text blocks like below in HTML format. Global configuration like the username setting is typically put into: %USERPROFILE%\mercurial.ini $HOME/.hgrc This patch itemizes these text blocks to increase readability in HTML format. Global configuration like the username setting is typically put into: - %USERPROFILE%\mercurial.ini (on Windows) - $HOME/.hgrc (on Unix, Plan9) Like as other platform sensitive container-ed text blocks, this patch also adds explicit "on PLATFORM" information to each items for readability in HTML format, even though output of "hg help config" on command line seems a little redundant. For example, on Unix: Global configuration like the username setting is typically put into: - "$HOME/.hgrc" (on Unix, Plan9)

doc: use correct indentation for enumeration This creates hg.1.html as expected.

doc: use correct cross reference in help documentation This patch fixes problems below: - ":hg:" role should be followed by not '"' but '`' - there is a help topic not "default-push" but "config.default-push"

doc: prevent literal text block from being treated as non-literal one This creates hg.1.html as expected.

doc: prevent non-literal text block from being treated as literal one This creates hg.1.html as expected.

histedit: show correct hash ID at verification error node.short() on 'ha' in verifyactions() causes broken hash ID, because it is initialized with node.hex()-ed node value.

backout: disable --merge with --no-commit (issue4874) Because "backout --merge" have to make a commit before merging, it doesn't work with --no-commit. We could change "backout --merge" to make a merge commit automatically, and --no-commit to bypass a merge commit, but that change would be undesirable because: a) it's hard to fix bad merges in general b) two commits would be created with the same --message So, this patch simply disables "--merge --no-commit".

changegroup: fix pulling to treemanifest repo from flat repo (issue5066) In c0f11347b107 (changegroup: don't support versions 01 and 02 with treemanifests, 2016-01-19), I stopped supporting use of cg1 and cg2 with treemanifest repos. What I had not considered was that it's perfectly safe to pull *to* a treemanifest repo using any changegroup version. As reported in issue5066, I therefore broke pull from old repos into a treemanifest repo. It was not covered by the test case, because that pulled from a local repo while enabling treemanifests, which enabled treemanifests on the source repo as well. After switching to pulling via HTTP, it breaks. Fix by splitting up changegroup.supportedversions() into supportedincomingversions() and supportedoutgoingversions().

tests: minor cleanup to treemanifest test

merge: don't try to merge subrepos twice (issue4988) In my patch series ending with rev 25e4b2f000c5 I switched most change/delete conflicts to be handled at the resolve layer. .hgsubstate was the one file that we weren't able to handle, so we kept the old code path around for it. The old code path added .hgsubstate to one of the other lists as the user specifies, including possibly the 'g' list. Now since we did this check after converting the actions from being keyed by file to being keyed by action type, there was nothing that actually removed .hgsubstate from the 'cd' or 'dc' lists. This meant that the file would eventually make its way into the 'mergeactions' list, now freshly augmented with 'cd' and 'dc' actions. We call subrepo.submerge for both 'g' actions and merge actions. This means that if the resolution to an .hgsubstate change/delete conflict was to add it to the 'g' list, subrepo.submerge would be called twice. It turns out that this doesn't cause any adverse effects on Linux due to caching, but apparently breaks on other operating systems including Windows. The fix here moves this to before we convert the actions over. This ensures that it .hgsubstate doesn't make its way into multiple lists. The real fix here is going to be: (1) move .hgsubstate conflict resolution into the resolve layer, and (2) use a real data structure for the actions rather than shuffling data around between lists and dictionaries: we need a hash (or prefix-based) index by file and a list index by action type. There's a very tiny behavior change here: collision detection on case-insensitive systems will happen after this is resolved, not before. I think this is the right change -- .hgsubstate could theoretically collide with other files -- but in any case it makes no practical difference. Thanks to Yuya Nishihara for investigating this.

bookmarks: improve documentation for --rev option

merge: undocument checkunknown and checkignored configs for 3.7 We've discovered an issue with this flag during certain kinds of rebases. When: (1) we're rebasing while currently on the destination commit, and (2) an untracked or ignored file F is currently in the working copy, and (3) the same file F is in a source commit, and (4) F has different contents in the source commit, then we'll try to merge the file rather than overwrite it. An earlier patch I sent honored the options for these situations as well. Unfortunately, rebases go through the same flow as the old, deprecated 'hg merge --force'. We'd rather not make any changes to 'hg merge --force' behavior, and there's no way from this point in the code to figure out whether we're in 'hg rebase' or 'hg merge --force'. Pierre-Yves David and I came up with the idea to split the 'force' flag up into 'force' for rebases, and 'forcemerge' for merge. Since this is a very disruptive change and we're in freeze mode, simply undocument the options for this release so that our hands aren't tied by BC concerns. We'll redocument them in the next release.

commands: advance current active bookmark at pull --update correctly Before this patch, "hg pull --update" doesn't advance current active bookmark correctly, if pulling itself doesn't advance it, even though "hg pull" + "hg update" does so. Existing test for "pull --update works the same as pull && update" in test-bookmarks.t doesn't examine this case, because pulling itself advance current active bookmark before actual updating the working directory in that test case. To advance current active bookmark at "hg pull --update" correctly, this patch examines 'movemarkfrom' instead of 'not checkout'. Even if 'not checkout' at the invocation of postincoming(), 'checkout' is overwritten by "the revision to update to" value returned by destutil.destupdate() in such case. Therefore, 'not checkout' condition means "update destination is revision #0", and isn't suitable for examining whether active bookmark should be advanced. Even though examination around "movemarkfrom == repo['.'].node()" may seem a little redundant just for this issue, this makes it easier to compare (and unify in the future, maybe) with the same logic to update bookmark at "hg update" below. if not ret and movemarkfrom: if movemarkfrom == repo['.'].node(): pass # no-op update elif bookmarks.update(repo, [movemarkfrom], repo['.'].node()): ui.status(_("updating bookmark %s\n") % repo._activebookmark) else: # this can happen with a non-linear update ui.status(_("(leaving bookmark %s)\n") % repo._activebookmark) bookmarks.deactivate(repo)

largefiles: prevent committing a missing largefile Previously, if the largefile was deleted at the time of a commit, the standin was silently not updated and its current state (possibly garbage) was recorded. The test makes it look like this is somewhat of an edge case, but the same thing happens when an `hg revert` followed by `rm` changes the standin. Aside from the second invocation of this in lfutil.updatestandinsbymatch() (which is what triggers this test case), the three other uses are guarded by dirstate checks for added or modified, or an existence check in the filesystem. So aborting in lfutil.updatestandins() should be safe, and will avoid silent skips in the future if this is used elsewhere.

changegroup: fix treemanifest exchange code (issue5061) There were two mistakes: one was accidental reuse of the fclnode variable from the loop gathering file nodes, and the other (masked by that bug) was not correctly handling deleted directories. Both cases are now fixed and the test passes.

log: speed up single file log with hidden revs (issue4747) On repos with lots of heads, the filelog() code could spend several minutes decompressing manifests. This change instead tries to efficiently scan the changelog for candidates and decompress as few manifests as possible. This is a regression introduced in 3.3 by the linkrev adjustment code. Prior to that, filelog was nearly instant. For the repo in the bug report, this improves time of a simple log command from ~3 minutes to ~.5 seconds, a 360x speedup. For the main Mercurial repo, a log of commands.py slows down from 1.14s to 1.45s, a 27% slowdown. This is still faster than the file() revset, which takes 2.1 seconds.

largefiles: report the missing file count after a commit that does nothing This is the same warning that is printed for normal files.

commit: factor the post commit status check into a cmdutil method The largefiles extension needs to set lfstatus for this status call. Otherwise, if a missing largefile is explicitly named, a confusing message is issued that says the largefile wasn't found, followed by another that says nothing changed.

largefiles: fix an explicit largefile commit after a remove (issue4969) The change in b68797f244e4 to handle a normal -> largefile switch was too aggressive in preserving the original matcher names. If a largefile is explicitly provided by the user, but only the standin exists in dirstate, then only the standin can be committed. There's still maybe an issue when the largefile is deleted outside of Mercurial: $ rm large $ hg ci -m "oops" large large: The system cannot find the file specified nothing changed [1]

context: back out sneaky code change in documentation change In 81b391a45264 (context: clarify why we don't compare file contents when nodeid differs, 2016-01-12), I also changed "node2 != _newnode" into "self.rev() is not None". I don't remember why. They are similar, but the former also catches the case where the file is clean in the dirstate (so node2 is not _newnode), but different from the "other" context. This resulted in unnecessary file content comparison a few lines further down in the code. Let's just back out the code change. Thanks to Durham Goode for spotting this.

templater: abort if infinite recursion detected while compiling In this case, a template is parsed recursively with no thunk for lazy evaluation. This patch prevents recursion by putting a dummy of the same name into a cache that will be referenced while parsing if there's a recursion. changeset = {files % changeset}\n ~~~~~~~~~ = [(_runrecursivesymbol, 'changeset')]

templater: abort if infinite recursion detected while evaluation (issue4758) It would be nice if we could detect recursion at the parsing phase, but we can't because a template can refer to a keyword of the same name. For example, "rev = {rev}" is valid if rev is a keyword, and we don't know if rev is a keyword or a template while parsing.

exchange: set 'treemanifest' param on pushed changegroups too In 5c0fd878779c (treemanifests: set bundle2 part parameter indicating treemanifest, 2016-01-08), I didn't realize I had to set the parameter separately for getbundle and unbundle. Having the parameter there on push allows us to push to an empty repo and have the requirements updated correctly.

crecord: fix help bar display issue (issue5063) Before this patch, the help bar in crecord wouldn't be printed correctly when the terminal window didn't have enough column to display it. This patch adds logic to make sure that the help bar message is always displayed. We use an ellipsis when it is not possible to display the complete message.

crecord: fix typo in the help text In the crecord help dialog, the toggle all option was wrongfully documented. Instead of using 'a', one must use 'A' to toggle all the hunks. The crecord header that is always displayed on the screen contains the right shortcut and does not need to be changed.

subrepo: better error messages in _ensuregit This patch improves the error messages raised when an OSError occurs, since simply re-raising the exception can be both confusing and misleading. For example, if "hg identify" is run inside a repository that contains a Git subrepository and the git binary could not be found, it'll exit with the message "abort: No such file or directory". That implies "identify" has a problem reading the repository itself. There's no way for the user to know what the real problem is unless they dive into the Mercurial source, which is what I ended up doing after spending hours debugging errors while provisioning a VM with Ansible (turns out I forgot to install Git on it). Descriptive errors are especially important on Windows, since it's common for Windows users to forget to set the "Path" system variable after installing Git.

hgweb: update canvas.width before dynamically redrawing graph (issue2683) After 91ac8cb79125 graph canvas width is decided once on the initial rendering. However, after graph page gets scrolled down to load more, it might need more horizontal space to draw, so it needs to resize the canvas dynamically. The exact problem that this patch solves can be seen using: hg init testfork cd testfork echo 0 > foo hg ci -Am0 echo 1 > foo hg ci -m1 hg up 0 echo 2 > foo hg ci -m2 hg gl -T '{rev}\n' @ 2 | | o 1 |/ o 0 hg serve And then by navigating to http://127.0.0.1:8000/graph/tip?revcount=1 "revcount=1" makes sure the initial graph contains only revision 2. And because the initial canvas width takes only that one revision into count, after the (immediate) AJAX update revision 1 will be cut off from the graph. We can safely set canvas width to the new value we get from the AJAX request because every time graph is updated, it is completely redrawn using all the requested nodes (in the case above it will use /graph/2?revcount=61), so the value is guaranteed not to decrease. P.S.: Sorry for parsing HTML with regexes, but I didn't start it.

run-tests: "fix" race condition in race condition fix Laurent's commit 3203dfe341f9 still suffers from a race: by the time the "job" function tries to assign to channels[channel], that list has been truncated to empty. The result is that every job thread raises an IndexError. Earlier, I tried an approach of correctly locking channels, but that caused run-tests to hang on KeyboardInterrupt sometimes. This approach is strictly hackier, but seems to actually work reliably.

rebase: restore help for rebase w/o args (issue5059) Restoring documentation accidentally removed in a9a047878e14.

shelve: use cg3 for treemanifests Similar to previous change, this teaches shelve to pick the right changegroup version for repos that use treemanifests.

repair: use cg3 for treemanifests The newly created helper changegroup.safeversion() knows to pick version 03 if the repo uses treemanifests, so just using that means we pick the right changegroup version.

changegroup: introduce safeversion() In a few places (at least repair.py and shelve.py), we want to find the best changegroup version that we can assume users of the repo will understand. For example, we choose version 01 by default, but if it's a generaldelta repo, we expect clients to support version 02 anyway, so we choose that for new bundles (for e.g. "hg strip"). Let's create a helper for this functionality in changegroup, so we can reuse it elsewhere later.

changegroup: don't support versions 01 and 02 with treemanifests Since it would be terribly expensive to convert between flat manifests and treemanifests, we have decided to simply not support changegroup version 01 and 02 with treemanifests. Therefore, let's stop announcing that we support these versions on treemanifest repos. Note that this means that older clients that try to clone from a treemanifest repo will fail. What happens is that the server, after this patch, finds that there are no common versions and raises "ValueError: no common changegroup version". This results in "abort: HTTP Error 500: Internal Server Error" on the client. Before this patch, it was no better: The server would instead find that there were directory manifest nodes to put in the changegroup 01 or 02 and raise an AssertionError on changegroup.py#668 (assert not tmfnodes), which would also appear as a 500 to the client.

run-tests: fix crash when --json and --blacklist are both used (issue5050) This patch fixes a crash when both --json and --blacklist were given as arguments of run-tests.py. Now, instead of crashing, we add an entry for blacklisted tests in the json output to show that the tests were skipped.

run-tests: fix race condition Before this patch, it was possible for run-tests to crash on a race condition. The race condition happens in the following case: - the last test finishes and calls: done.put(None) - the context switches to the main thread that clears the channels list - the context switches to the last test mentioned above, it tries to access channels[channel] and crashes This happened to me while running run-tests. This patch fixes the issue by clearing the channel before considering that the test is done.

copyright: update to 2016

transaction: abort transaction during hook exception The new transaction context did not handle the case where an exception during close should still call release. This cause pretxnclose hooks that failed to cause the transaction to fail without aborting, thus requiring a hg recover. I've added a test.

Added signature for changeset 158bdc896572

Added tag 3.7-rc for changeset 158bdc896572

shelve: lowercase flag description The help for --unknown is the *only* command that started with a capital letter

changegroup: cg3 has two empty groups *after* manifests changegroup.getchunks() determines the end of the stream by looking for an empty chunk group (two consecutive empty chunks). It ignores empty groups in the first two groups. Changegroup 3 introduced an empty chunk between the manifests and the files, which confuses getchunks(). Since it comes after the first two, getchunks() will stop there. Fix by rewriting getchunks so it first counts two groups (empty or not) and then keeps antostarts counting empty groups. With this counting, changegroup 1 and 2 have exactly one empty group after the first two groups, while changegroup 3 has two (one for directories and one for files). It's a little hard to test this at this point, but I have verified that this patch fixes narrowhg (which was broken before this patch). Also, future patches will fix "hg strip" with treemanifests, and once that's done, getchunks() will be tested through tests of "hg strip".

mq: check for reserved patch name with qimport -r (issue5033) Fix regression from 143b52fce68e. Catching aborts might not be pretty but it works and is a small change.

mq: refactor makepatchname into class method

repoview: fix corrupted hiddencache crash Mercurial (issue5042) Before this patch if the hiddencache existed but was empty, it would crash mercurial. This patch adds exception handling when reading the hiddencache to avoid the issue. When encountering a corrupted cache file we print a devel warning. There would be no point in issuing a normal warning as the user wouldn't be able to do anything about the situation. The warning looks like: devel-warn: corrupted hidden cache, removing it at: /path/to/repoview.py

repoview: add missing newline character in debug prints

commandserver: drop tell() and seek() from channels (issue5049) These operations are obviously invalid for file-like channels because they will read or write protocol headers. This patch works around the issue that "hg archive" generates a corrupted zip file on Windows commandserver because of unusable tell() implementation. But the problem still occurs without using a commandserver. $ hg archive -R not-small-repo -t zip - | cat > invalid.zip So, this patch cannot fix the issue5049 completely.

crecord: edit during hg crecord should preserve cursor position (issue5041) This patch adds a variable to keep track of what hunk was selected before the edit. We use that variable to select the hunk or its replacement after the edit.

templates: use canvaswidth instead of fixed width for canvas (issue2683) Before this patch, template files for "graph" web page use fixed width size "480" for canvas element. This causes pruned lanes and invisible vertexes, if there are 16 or more vertical lanes at once. In such case, part of graph in right side area over 480 is invisible, even though corresponded summary text blocks are visible correctly. This limitation isn't reasonable for workflow using many branches at once (e.g. "one branch per issue" workflow). There were changes below related to width of canvas: - 7359cb753a54 (templates: widen the graph canvas (issue2683)), released as a part of Mercurial 1.8.2 According to the description, this assumed that 15 parallel branches was enough for ordinary workflow, and bumped width of canvas up from 224 to 480. - d490edc71146 (hgweb: make graph data suitable for template usage), released as a part of Mercurial 2.3 This introduced "canvaswidth" template keyword as a part of refactoring around graph rendering. But 'width="480"' of canvas element in template files wasn't replaced by 'width="{canvaswidth}"' in it (or subsequent one). This patch uses dynamic value "{canvaswidth}" instead of fixed width size "480" for canvas element. This is posted for "stable", because: - this is re-fixing issue2683 - this is simple enough for stable - using "{canvaswidth}" doesn't require any additional cost Calculation of canvaswidth is already implied as a part of "graph" web command.

backout: fix --no-commit option (issue5054)

bundle: exit early when there are no commits to bundle Previously, if you passed a revset that resolved to no nodes, it would get interpreted by the changegroup discovery logic as 'bundle all my heads', which is not what the user asked. Let's exit early when we notice this case. It could be argued that the changeset discovery logic should be smarter and only assume 'all heads' if the incoming heads parameter is None, but that's a much riskier change.

zeroconf: access repo on hgweb_mod properly (issue5036) hgweb_mod.hgweb.repo disappeared in ae33fff17c1e (hg: establish a cache for localrepository instances) and the code for accessing repo instances from hgweb was later refactored to go through a cache-aware context manager. Adapt zeroconf to access the repo instance via the new API.

merge default into stable for 3.7 code freeze

shelve: permit shelves to contain unknown files If an emergency comes in while you're in the middle of an experimental change, it can be useful to shelve not just files hg already tracks but also your unknown files while you handle the emergency. This is especially true if you have hooks intended to prevent you from forgetting to add new code before you push. Teach "hg shelve" to optionally shelve unknown files, not just tracked files. This is functionally similar to --addremove, but with two differences: 1) Deleted files are not removed. 2) Files added during shelve creation are tracked in extra so that they can be forgotten by "hg unshelve". When unshelving, we take care to only forget files if they've been created during the unshelve operation; if you add a file that's being tracked in a shelve as an unknown file, it should not become unknown again when the shelve is unshelved.

localrepo: don't reference transaction from hook closure (issue5043) Before, the hook() closure (which is called as part of locking hooks) would maintain a reference to a transaction instance (which should be finalized by the time lock hooks are called). Because we accumulate hook() instances when there are multiple transactions per lock, this would result in holding references to the transaction instances which would lead to higher memory utilization. Creating a reference to the hook arguments dict minimizes the number of objects that are kept alive until the lock release hook runs, minimizing memory "leaks."

context: don't use util.cachefunc due to cycle creation (issue5043) util.cachefunc stores all arguments as the cache key. For filectxfn functions, the arguments include the memctx instance. This creates a cycle where memctx._filectxfn references self. This causes a memory leak. We break the cycle by implementing our own memoizing function that only uses the path as the cache key. Since each memctx has its own cache instance, there is no concern about invalid cache hits.

largefiles: actions will now always have a file - drop check

largefiles: make prompt order deterministic 42ae1b1f048f introduced iteration of a set. Make it stable.

largefiles: fix commit of missing largefiles 832c98d79587 improved merging of standin files referencing missing largefiles. It did however not test or fix commits of such merges; it would abort. To fix that, change copytostore to skip and warn about missing largefiles with a message similar the one for failing get from remote filestores. (It would perhaps in both cases be better to emit a more helpful warning like "warning: standin file for large1 references 58e24f733a which can't be found in the local store".) To test this, make sure commit doesn't find the "missing" largefile in the global usercache. For further testing, verify that update and status works as expected after this. This will also effectively backout 63116d47cc3f.

diff: don't crash when merged-in addition is copied Similar to what was explained in the previous commit, the diff code expected copy source to be in "ctx1", which is not always the case during a merge. This has been broken since before hg 2.0. Also similar to the previous commit, we fix the problem by fixing up the copy dict.

diff: don't crash when merged-in addition was removed (issue4786) During a merge, if the user removes a file that came from parent 2 and did not exist in parent 1, the file's status will be "removed". This surprises the diff code, which crashes because it expects removed files exist in parent 1. This has been broken since 377124ba6b10 (trydiff: use 'not in addedset' for symmetry with 'not in removedset', 2014-12-23). Fix by fixing up the list of removed file, similar to how we currently fix up the list of modified and added files during a merge.

diff: move status fixup earlier, out of _filepairs() This prepares for future patches, and it also lets us remove the ugly "ctx1" argument to _filepairs() (ugly because of its assymmetry -- there's no "ctx2" argument).

graft: warn when -r is combined with revisions as positional arguments The behaviour in this case is undefined. Instead of silently doing something "random" and surprising, at least issue a warning. (This should perhaps be considered a "deprecation" and turned into an error in a future release.)

graft: clarify in help that `-r` is not just optional Positional parameters are also treated as revisions, but the order of revisions matters and it will often be wrong if the user understands it as `-r` taking multiple revisions as `-r REV1 REV2`. (Alternatively, `-r` could be turned into a no-op flag as the documentation suggests. That would however be less "semantic markup" and I agree with the implementation in 55e7f352b1d3 but not the documentation.)

streamclone: use backgroundfilecloser (issue4889) Closing files that have been appended to is slow on Windows/NTFS. CloseHandle() calls on this platform often take 1-10ms - and that's on my i7-6700K Skylake processor with a modern and fast SSD. Contrast with other I/O operations, such as writing data, which take <100us. This means that creating/appending thousands of files can add significant overhead. For example, cloning mozilla-central creates ~232,000 revlog files. Assuming 1ms per CloseHandle(), that yields 232s (3:52) of wall time waiting for file closes! The impact of this overhead can be measured most directly when applying stream clone bundles. Applying these files is effectively uncompressing a tar archive (read: it's very fast). Using a RAM disk (read: no I/O wait), the difference in wall time for a `hg debugapplystreamclonebundle` for a ~1731 MB mozilla-central bundle between Windows and Linux from the same machine is drastic: Linux: ~12.8s (128MB/s) Windows: ~352.0s (4.7MB/s) Windows is ~27.5x slower. Yikes! After this patch: Linux: ~12.8s (128MB/s) Windows: ~102.1s (16.1MB/s) Windows is now ~3.4x faster. Unfortunately, it is still ~8x slower than Linux. Profiling reveals a few hot code paths that could likely be improved. But those are for other patches. This patch introduces test-clone-uncompressed.t because existing tests of `clone --uncompressed` are scattered about and adding a variation for background thread closing to e.g. test-http.t doesn't feel correct.

streamclone: indent code This will make the subsequent patch easier to read.

scmutil: support background file closing Closing files that have been appended to is relatively slow on Windows/NTFS. This makes several Mercurial operations slower on Windows. The workaround to this issue is conceptually simple: use multiple threads for I/O. Unfortunately, Python doesn't scale well to multiple threads because of the GIL. And, refactoring our code to use threads everywhere would be a huge undertaking. So, we decide to tackle this problem by starting small: establishing a thread pool for closing files. This patch establishes a mechanism for closing file handles on separate threads. The coordinator object is basically a queue of file handles to operate on and a thread pool consuming from the queue. When files are opened through the VFS layer, the caller can specify that delay closing is allowed. A proxy class for file handles has been added. We must use a proxy because it isn't possible to modify __class__ on built-in types. This adds some overhead. But as future patches will show, this overhead is cancelled out by the benefit of closing file handles on background threads.

templatekw: add {namespaces} keyword This provides a general-purpose interface to all custom namespaces. The {namespaces} keyword honors the definition order of namespaces as they are kept by sortdict.

templatekw: move shownames() helper to be sorted alphabetically I'll add shownamespaces(), which is similar to this function. I want to put them nearby.

templater: make get(dict, key) return a single value This is necessary to obtain a _hybrid object from a dict. If get() yields a value, it would be stringified. I see no benefit to make get() lazy, so this patch just changes "yield" to "return".

templater: make _hybrid not callable to avoid conflicting semantics In templater, a callable symbol exists for lazy evaluation, which should have f(**mapping) signature. On the other hand, _hybrid.__call__(), which was introduced by 0b241d7a8c62, generates mapping for each element. This patch renames _hybrid.__call__() to _hybrid.itermaps() so that a _hybrid object can be a value of a mapping dict. {namespaces % "{namespace}: {names % "{name }"}\n"} ~~~~~ a _hybrid object

backout: commit changeset by default (BC) Add --no-commit flag to prevent it. This should make the hg user experience a little better. Some discussion can be found here: http://markmail.org/message/7jm7ro2ias6hxywy

help: move Windows 9x information to appropriate place

shelve: move commitfunc closer to use site Supporting shelving of unknown files needs this code motion. No functional changes.

commands: document clone bundles hooks and rollback behavior The added content is inside a verbose container. I figure it makes sense to explicitly document behavior, including with the caveat it may change later. People can't say they weren't warned!

clonebundles: improve BUNDLESPEC documentation Before the existence of `hg debugbundle --spec`, the process for defining the BUNDLESPEC value in manifests was not very clear and not trivial to automate, especially in the case of stream clone bundles. This patch adds documentation to note the existence of `hg debugbundle --spec`. We drop the reference to stream clone requirements handling because it is now redundant with `hg debugbundle --spec`. While we are here, we further reinforce the importance of defining BUNDLESPEC.

commands: teach debugbundle to print bundle specification This seems like the most logical place to put this functionality. Test coverage over existing known bundle specs has been added.

commands: use context manager for opened bundle file

exchange: implement function for inferring bundle specification We don't currently have a mechanism for inferring bundle spec strings from bundle files. This patch adds one. This will eventually be used to make the producing of clone bundles manifests easier.

streamclone: extract code for reading header fields So it can be called from another consumer in a future patch.

encoding: escape U+007F (DEL) character in JSON RFC 7159 does not state that U+007F must be escaped, but it is widely considered a control character. As '\x7f' is invisible on a terminal, and Python's json.dumps() escapes '\x7f', let's do the same.

run-tests: skip threading for a single test (issue5040) This version backs out 50e621fe0362 and implements it in a more consistent manner.

cleanup: use modern @property/@foo.setter property specification We can use this now that we're 2.6+, and this is more idiomatic modern Python.

buildrpm: use bash shebang, since we use bash features in the script As suggested by Bryan O'Sullivan.

mac: ignore resource fork when checking file sizes Some evil evil awful tool adds resource forks to files it's comparing. Our Mac-specific code to do bulk stats was accidentally using "total size" which includes those forks in the file size, causing them to be reported as modified. This changes it to only care about the normal data size and thus agree with what Mercurial's expecting.

copies: fix detection of divergent directory renames If we move all the files out of one directory, but into two different directories, we should not consider it a directory rename. The detection of this case was broken.

with: use context manager for transaction in strip

with: use context manager for transaction in pushphase

with: use context manager for transaction in strip

with: use a context manager for transaction in strip