Sun, 18 Jun 2017 11:39:03 +0900 revsetlang: factor out helper to match ancestors() in parsed tree
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Jun 2017 11:39:03 +0900] rev 32912
revsetlang: factor out helper to match ancestors() in parsed tree More checks will be added.
Sat, 17 Jun 2017 13:34:18 +0900 templatekw: use common "rev:node" format as the default of predecessors
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Jun 2017 13:34:18 +0900] rev 32911
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.
Sat, 17 Jun 2017 13:23:55 +0900 templatekw: populate all keywords depending on predecessor in map operation
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Jun 2017 13:23:55 +0900] rev 32910
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().
Sat, 17 Jun 2017 13:18:03 +0900 templatekw: reference predecessor node id as {node} in map operation
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Jun 2017 13:18:03 +0900] rev 32909
templatekw: reference predecessor node id as {node} in map operation More predecessor-depending values will be populated by the next patch.
Sun, 18 Jun 2017 23:05:54 -0400 highlight: put pygments import inside demandimport.deactivated
Augie Fackler <raf@durin42.com> [Sun, 18 Jun 2017 23:05:54 -0400] rev 32908
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.
Sun, 18 Jun 2017 22:19:54 -0400 run-tests: explicitly flush test runner output for Windows stability
Matt Harbison <matt_harbison@yahoo.com> [Sun, 18 Jun 2017 22:19:54 -0400] rev 32907
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
Sun, 18 Jun 2017 21:31:53 -0400 tinyproxy: explicitly flush logged messages
Matt Harbison <matt_harbison@yahoo.com> [Sun, 18 Jun 2017 21:31:53 -0400] rev 32906
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
Sun, 18 Jun 2017 22:46:56 +0900 help: clarify ancestors() and descendants() include given set (issue5594)
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Jun 2017 22:46:56 +0900] rev 32905
help: clarify ancestors() and descendants() include given set (issue5594) Also unified "a changeset" to "changesets".
Sun, 19 Feb 2017 19:37:14 +0900 dagop: move blockancestors() and blockdescendants() from context
Yuya Nishihara <yuya@tcha.org> [Sun, 19 Feb 2017 19:37:14 +0900] rev 32904
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
Sun, 16 Oct 2016 18:03:24 +0900 dagop: split module hosting DAG-related algorithms from revset
Yuya Nishihara <yuya@tcha.org> [Sun, 16 Oct 2016 18:03:24 +0900] rev 32903
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
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip