Patchwork D1866: transaction: register summary callbacks only at start of transaction (BC)

martinvonz created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  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.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D1866

AFFECTED FILES
  mercurial/localrepo.py
  tests/test-transplant.t

CHANGE DETAILS




To: martinvonz, #hg-reviewers
Cc: mercurial-devel