Siddharth Agarwal <sid0@fb.com> [Tue, 12 Jan 2016 18:17:07 -0800] rev 27741
merge: determine what untracked conflicts cause warns and aborts separately
This is written in a somewhat weird style, but it's designed for code reuse in
an upcoming patch.
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.
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.
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.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 08 Jan 2016 10:57:01 -0800] rev 27737
exchange: make clonebundleprefers non-experimental
In preparation for making the feature enabled by default.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 08 Jan 2016 10:53:07 -0800] rev 27736
clonebundles: remove advertisement of feature
I screwed up.
When clone bundles is enabled on the server and a compatible client
without the feature enabled clones, the server sends down an
advertisement saying to enable the feature. The server creates the
message which is printed verbatim on the client as an "output" part.
There are 2 problems:
1) The message doesn't respect the client's localization
2) The message contains a reference to the "experimental.clonebundles"
option.
Since clone bundles is about to be marked as non-experimental and the
goal of the advertisement was to encourage clients to test the
experimental feature, let's just remove the broken advertisement since
it no longer serves a purpose.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 08 Jan 2016 21:14:08 -0800] rev 27735
changegroup: remove now-unused 'wasempty' variable and parameter
Martin von Zweigbergk <martinvonz@google.com> [Fri, 08 Jan 2016 21:13:06 -0800] rev 27734
treemanifests: set bundle2 part parameter indicating treemanifest
By adding a mandatory 'treemanifest' parameter in the bundle2 part, we
make it possible for the recipient to set repo requirements before the
manifest revlog is accessed.