Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Jun 2017 22:46:38 -0700] rev 32948
changegroup: let callers pass in transaction to apply() (API)
I think passing in the transaction makes it a little clearer and more
consistent with bundle2.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Jun 2017 23:09:14 -0700] rev 32947
repair: create transaction for bundle1 unbundling earlier
See earlier patch for motivation.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Jun 2017 22:18:21 -0700] rev 32946
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 32945
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 32944
changegroup: inline 'publishing' variable in apply()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 11:24:49 -0700] rev 32943
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 32942
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 32941
strip: remove unncessary "del" and inline variable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 11:24:21 -0700] rev 32940
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()).
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 11:21:37 -0700] rev 32939
amend: use context manager for locking
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 11:20:29 -0700] rev 32938
strip: use context manager for locking and transaction in stripcmd()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 11:17:31 -0700] rev 32937
strip: use context manager for locking in strip()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 11:18:12 -0700] rev 32936
rebase: use context manager for locking in pullrebase()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 11:18:05 -0700] rev 32935
rebase: use context manager for locking in rebase()
Matt Harbison <matt_harbison@yahoo.com> [Mon, 19 Jun 2017 21:53:54 -0400] rev 32934
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.