Martin von Zweigbergk <martinvonz@google.com> [Sun, 14 Jan 2018 23:59:17 -0800] rev 35709
evolution: report new unstable changesets
This adds a transaction summary callback that reports the number of
new orphan, content-divergent and phase-divergent changesets.
The code for reporting it is based on the code from the evolve
extension, but simplified a bit. It simply counts the numbers for each
kind of instability before and after the transaction. That's obviously
not very efficient, but it's easy to reason about, so I'm doing this
as a first step that can make us quite confident about the test case
changes. We can optimize it later and make sure that the tests are not
affected. The code has been used in the evolve extension for a long
time and has apparently been sufficiently fast, so it doesn't seem
like a pressing issue.
Unlike the evolve extension's version of this report, this version
applies to all commands (or all transactions run as part of any
command, to be exact).
Differential Revision: https://phab.mercurial-scm.org/D1867
Martin von Zweigbergk <martinvonz@google.com> [Wed, 10 Jan 2018 14:00:23 -0800] rev 35708
transaction: register summary callbacks only at start of transaction (BC)
We currently register summary callbacks every time
localrepo.transaction() is called, so both when the transaction is
started and when a nested transaction is created. That seems a little
weirdly asymmetric, because the summary callbacks are thus not
necessarily registred at the beginning of the outermost transaction,
but they are only called when the outermost transaction closes (not
when a nested transaction closes).
I want to add another summary callback that records the repo state at
the beginning of the transaction and compares to that when the
transaction closes. However, because of the registration that happens
when a nested transaction is created, that would need to go through
extra trouble to not overwrite the callback and report the difference
from the start time of the innermost transaction to the close of the
outermost transaction.
Also, the callbacks are registered with a name based on the order they
are defined in the registersummarycallback(). For example, if both the
"new changesets %s" and the "obsoleted %i changesets" hooks are
registered, the first would be called 00-txnreport and the second
would be called 01-txnreport. That gets really weird if
registersummarycallback() gets called multiple times, because the last
one wins, and a depending on which of the two callbacks get
registered, we might hypothetically even overwrite on type of callback
with another. For example, if when the outer transaction was started,
we registered the "new changesets %s" callback first, and when the
inner transaction was started, we registered only the "obsoleted %i
changesets" callback, then only the latter message would get
printed. What makes it hypothetical is that what gets registered
depends on the transaction name, and the set of transaction names that
we match on for the former latter message is a subset of the set of
names we match on for the former. Still, that seems like a bug waiting
to happen.
That second issue could be solved independently, but the first issue
seems enough for me to consider it a bug (affecting developers, not
users), so this patch simply drops that extra registration.
Note that this affects "hg transplant" in a user-visible way. When "hg
transplant" is asked to transplant from a remote repo so it involves a
pull, then the outermost transaction name is "transplant" and an inner
transaction is created for "pull". That inner transaction is what led
us to sometimes report "new changesets %s" from "hg transplant". After
this patch, that no longer happens. That seems fine to me. We can make
it instead print the message for all "hg transplant" invocations if we
want (not just those involving a remote), but I'll leave that for
someone else to do if they think it's important.
Differential Revision: https://phab.mercurial-scm.org/D1866