Thu, 15 Jun 2017 22:18:21 -0700 unbundle: create transaction for bundle1 unbundling earlier
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.
Thu, 15 Jun 2017 16:10:53 -0700 exchange: create transaction for bundle1 unbundling earlier
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().
Mon, 19 Jun 2017 00:06:23 -0700 changegroup: inline 'publishing' variable in apply()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 00:06:23 -0700] rev 32926
changegroup: inline 'publishing' variable in apply()
Mon, 19 Jun 2017 11:24:49 -0700 repair: remove unnecessary locking for bookmarks
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.
Mon, 19 Jun 2017 13:18:00 -0700 repair: move check for existing transaction earlier
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.
Mon, 19 Jun 2017 13:13:28 -0700 strip: remove unncessary "del" and inline variable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 13:13:28 -0700] rev 32923
strip: remove unncessary "del" and inline variable
Mon, 19 Jun 2017 11:24:21 -0700 repair: clarify in comment that caller must take lock, but not transaction
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()).
Mon, 19 Jun 2017 11:21:37 -0700 amend: use context manager for locking
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 11:21:37 -0700] rev 32921
amend: use context manager for locking
Mon, 19 Jun 2017 11:20:29 -0700 strip: use context manager for locking and transaction in stripcmd()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 11:20:29 -0700] rev 32920
strip: use context manager for locking and transaction in stripcmd()
Mon, 19 Jun 2017 11:17:31 -0700 strip: use context manager for locking in strip()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 11:17:31 -0700] rev 32919
strip: use context manager for locking in strip()
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip