Tue, 12 Jan 2016 18:12:35 -0800 merge: factor out code to get checkunknown config
Siddharth Agarwal <sid0@fb.com> [Tue, 12 Jan 2016 18:12:35 -0800] rev 27740
merge: factor out code to get checkunknown config We're going to reuse this code shortly.
Tue, 05 Jan 2016 17:37:59 -0800 hooks: add HG_NODE_LAST to txnclose and changegroup hook environments
Mateusz Kwapich <mitrandir@fb.com> [Tue, 05 Jan 2016 17:37:59 -0800] rev 27739
hooks: add HG_NODE_LAST to txnclose and changegroup hook environments Sometimes a txnclose or changegroup hook wants to iterate through all the changesets in transaction: in that situation usually the revset `$HG_NODE:` is used to select the revisions. Unfortunately this revset sometimes may contain too many changesets because we don't have the write lock while the hook runs newer changes may be added to repository in the meantime. That's why there is a need for extra variable carrying the information about the last change in the transaction.
Fri, 08 Jan 2016 10:58:04 -0800 exchange: make clone bundles non-experimental and enabled by default
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 08 Jan 2016 10:58:04 -0800] rev 27738
exchange: make clone bundles non-experimental and enabled by default The clone bundles feature was introduced in Mercurial 3.6 behind an experimental and disabled by default flag. The feature has been enabled on hg.mozilla.org for a few months and has served many terabytes of clones. Users have been encouraged to use the feature and reception has been very positive (mainly due to faster clones as a result of connecting to a CDN). I have heard no feedback about changing the feature other than inquiries about when it will be enabled by default. So, I think the feature is ready to be enabled by default. This patch renames experimental.clonebundles to ui.clonebundles, documents the option, and enables it by default. References to the experimental state of clone bundles have been removed. The remaining config option docs in clonebundles.py have been removed because they are redudant with `hg help config`. There are some oddities with behavior of clone bundles. Because clones with clone bundles are effectively 2 `hg pull` operations, there may be 2 transactions. This could result in hooks running twice. If the subsequent pull is aborted, it could result in partial rollback and an incomplete clone. This behavior is a bit wonky and should probably be documented. If this patch is accepted, I'll send a follow-up to document it. I don't think this behavior should prevent the feature being enabled by default. Reworking the clone mechanism to support interrupted or multi-part clones feels like a major new feature and something that when implemented can change the hook and rollback semantics of clone bundles. Besides, partial clone is better than full rollback and hooks running on initial clone are likely rare, so I think the impact is minimal.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 tip