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

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

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

changegroup: inline 'publishing' variable in apply()

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

repair: move check for existing transaction earlier Several benefits: * Gets close the comment describing it * Splits off unrelated comment about "backup" argument * Error checking is customarily done early * If we added an early return to the method, it would still consistently fail if there was an existing transaction (so we would find and fix that case quickly) One test needs updating with for this change, because we no longer create the backup bundle before we fail. I don't see much reason to create that backup bundle. If some command was adding content and then trying to strip it as well within the transaction, we would have a backup for the user, but the risk of that not being discovered in development seems very small.

strip: remove unncessary "del" and inline variable

repair: clarify in comment that caller must take lock, but not transaction I have checked that all callers have already taken the lock (and if they hadn't, we should have seen tests fail thanks to the 'transaction requires locking' devel warning in localrepo.transaction()).

amend: use context manager for locking

strip: use context manager for locking and transaction in stripcmd()

strip: use context manager for locking in strip()

rebase: use context manager for locking in pullrebase()

rebase: use context manager for locking in rebase()

test-http-proxy: redirect proxy stdout to /dev/null This output hasn't been getting flushed, but would alter the log if it ever grew large enough. See 23b07333a8b2.

test-logtoprocess: don't run on Windows Several bits of output were missing[1], unless the DETACHED_PROCESS flag is _not_ passed to subprocess.Popen(). The problem with that is it briefly opens and closes several cmd.exe windows on screen. Foozy also mentioned some other issues in that thread. With this, the last of the long standing Windows failures fixed, the test suite now runs cleanly (536 ran, 67 skipped) on Windows 7 x64, with python 2.7.13. \o/ [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096987.html

revset: add support of keyword arguments to ancestors() and descendants() Prepares for adding depth parameter.

revsetlang: check arguments passed to ancestors() before optimizing to only() Future patches will add depth parameter to ancestors(), which isn't compatible with only().

revsetlang: factor out helper to match ancestors() in parsed tree More checks will be added.

templatekw: use common "rev:node" format as the default of predecessors I'm not sure if this is better. If we're planning to add a template keyword that returns obsoleted nodes unavailable in the repo (i.e. they have no valid revision numbers), we might want to use the current "node"-only format everywhere.

templatekw: populate all keywords depending on predecessor in map operation This is what showparents() does. repo[precnode] should never fail since its validity is tested by closestpredecessors().

templatekw: reference predecessor node id as {node} in map operation More predecessor-depending values will be populated by the next patch.

highlight: put pygments import inside demandimport.deactivated I tripped on some weirdness relating to _thread vs threading way down in a dep of highlight recently. I'm not really sure why I'm only just seeing this defect now, but experimentally this fixes the problem, and shouldn't cause any load-time slowness for people until pygments is actually about to be used since highlight.highlight is still lazily loaded in the highlight/__init__.py file.

run-tests: explicitly flush test runner output for Windows stability When hghave testing goes awry, the output order was changing on Windows. diff --git a/tests/test-run-tests.t b/tests/test-run-tests.t --- a/tests/test-run-tests.t +++ b/tests/test-run-tests.t @@ -920,10 +920,10 @@ > EOF > done $ rt -j 2 - .... + ....skipped: unknown feature: notarealhghavefeature\r (esc) + + # Ran 5 tests, 0 skipped, 0 warned, 0 failed. - skipped: unknown feature: notarealhghavefeature - $ cd .. $ rm -rf broken Since 'skipped: unknown feature: notarealhghavefeature\n\n' is printed to stdout and the rest to stderr, it seems like maybe stdio isn't line buffered on Windows. When a program exits, stdout is flushed before stderr[1]. [1] https://blogs.msdn.microsoft.com/oldnewthing/20060519-09/?p=31133

tinyproxy: explicitly flush logged messages On Windows, output streams are buffered when redirected to a file, and TerminateProcess() apparently doesn't trigger a flush. This left test-http-proxy.t missing part of the last line when it cat'd proxy.log[1]. Flushing stderr is all that is needed (on py27 anyway). I originally flushed stdout too, but that added additional output to the log: $ cat proxy.log + Accept: $LOCALIP (localhost)\r (esc) + Serving HTTP on 0.0.0.0 port 20810 ...\r (esc) + connect to localhost:$HGPORT\r (esc) * - - [*] "GET http://localhost:$HGPORT/?cmd=capabilities HTTP/1.1" - - (glob) + bye\r (esc) + connect to localhost:$HGPORT\r (esc) * - - [*] "GET http://localhost:$HGPORT/?cmd=branchmap HTTP/1.1" - - x-hgproto-1:0.1 0.2 comp=*zlib,none,bzip2 (glob) + bye\r (esc) + connect to localhost:$HGPORT\r (esc) * - - [*] "GET http://localhost:$HGPORT/?cmd=stream_out HTTP/1.1" - - x-hgproto-1:0.1 0.2 comp=*zlib,none,bzip2 (glob) + bye\r (esc) + connect to localhost:$HGPORT\r (esc) ... [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096987.html

help: clarify ancestors() and descendants() include given set (issue5594) Also unified "a changeset" to "changesets".

dagop: move blockancestors() and blockdescendants() from context context.py seems not a good place to host these functions. % wc -l mercurial/context.py mercurial/dagop.py 2306 mercurial/context.py 424 mercurial/dagop.py 2730 total

dagop: split module hosting DAG-related algorithms from revset This module hosts the following functions. They are somewhat similar (e.g. scanning revisions using heap queue or stack) and seem non-trivial in algorithmic point of view. - _revancestors() - _revdescendants() - reachableroots() - _toposort() I was thinking of adding revset._fileancestors() generator for better follow() implementation, but it would be called from context.py as well. So I decided to create new module. Naming is hard. I couldn't come up with any better module name, so it's called "dag operation" now. I rejected the following candidates: - ancestor.py - existing, revlog-level DAG algorithm - ancestorset.py - doesn't always return a set - dagalgorithm.py - hard to type - dagutil.py - existing - revancestor.py - I want to add fileancestors() % wc -l mercurial/dagop.py mercurial/revset.py 339 mercurial/dagop.py 2020 mercurial/revset.py 2359 total

tests: protect tests involving git ext::sh with git-ext-sh

hghave: add has_git_range for testing if git understands ext::sh Even on CentOS 7, git is at version 1.8. It seems git 1.9 is when ext::sh was introduced so we a check for that. The way these functions are written follows the same style and format for the way we check svn and bzr versions.

rebase: rewrite "x in y.children()" as "y in x.parents()" children() is slow