Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Jun 2017 22:18:21 -0700] rev 32928
unbundle: create transaction for bundle1 unbundling earlier
See earlier patch for motivation.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Jun 2017 16:10:53 -0700] rev 32927
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().
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 00:06:23 -0700] rev 32926
changegroup: inline 'publishing' variable in apply()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 11:24:49 -0700] rev 32925
repair: remove unnecessary locking for bookmarks
The caller has already locked the repo.
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 13:18:00 -0700] rev 32924
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.
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 13:13:28 -0700] rev 32923
strip: remove unncessary "del" and inline variable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 11:24:21 -0700] rev 32922
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()).