Martin von Zweigbergk <martinvonz@google.com> [Tue, 12 Jan 2016 21:23:45 -0800] rev 27752
changegroup3: introduce experimental.changegroup3 boolean config
In order to give us the freedom to change the changegroup3 format,
let's hide it behind an experimental config. Since it is required by
treemanifests, that will override the cg3 config.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 12 Jan 2016 21:01:06 -0800] rev 27751
changegroup: hide packermap behind methods
This is to prepare for hiding changegroup3 behind a config option.
Matt Mackall <mpm@selenic.com> [Wed, 13 Jan 2016 15:47:37 -0600] rev 27750
merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 12 Jan 2016 13:10:31 -0800] rev 27749
context: check for differing flags a little earlier
This makes it clearer that a unchanged file whose flags have changed
will be reported as a modification. Also test this.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 12 Jan 2016 13:09:54 -0800] rev 27748
context: clarify why we don't compare file contents when nodeid differs
See previous commit for timing information.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 12 Jan 2016 12:43:36 -0800] rev 27747
status: back out changeset 89f49813526c
This backs out 89f49813526c (status: change + back out == clean (API),
2016-01-04). Although correct, it turned out that it was just too
slow. For example, 'hg status --rev .~1000 --rev .' on the Mozilla
repo went from <1s to >30s on cold disk. So we go back to reporting
reverted changes as modified instead of clean. These are rare anyway,
as suggested by the fact that it had been broken since before
Mercurial 2.0.
Laurent Charignon <lcharignon@fb.com> [Tue, 12 Jan 2016 13:43:41 -0800] rev 27746
rebase: prevent creating divergence
Before this patch rebase would create divergence when you were rebasing obsolete
changesets on a destination not containing one of its successors.
This patch introduces rebase.allowdivergence to explicitly allow
divergence creation with rebase.
Laurent Charignon <lcharignon@fb.com> [Wed, 06 Jan 2016 12:55:56 -0800] rev 27745
rebase: create a new variable to make the next patch more legible
Laurent Charignon <lcharignon@fb.com> [Wed, 06 Jan 2016 12:55:56 -0800] rev 27744
rebase: minor refactoring of _computeobsoletenotrebased
This patch is a refactoring of the code skipping obsolete changesets already
present in destination. It makes the following patches more legible.
Instead of passing all the revs to be rebased to _computeobsoletenotrebased,
we only pass the obsolete revisions of the rebaseset.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 13 Jan 2016 00:09:26 -0500] rev 27743
test-status: stabilize for no-execbit platforms
The preceding #if conditional was the only modification to the file, so the
"reverting file" line in the subsequent revert command was getting dropped.
Siddharth Agarwal <sid0@fb.com> [Tue, 12 Jan 2016 18:38:49 -0800] rev 27742
merge: split up checks for unknown and ignored files that differ
In some real-world cases it is preferable to allow overwriting ignored files
while continuing to abort on unknown files. This primarily happens when we're
replacing build artifacts (which are ignored) with checked in files, but
continuing to abort on differing files that aren't ignored.
We're redefining merge.checkunknown to only control the behavior for files
that aren't ignored. That's fine because this config was only very recently
introduced and has not made its way into any Mercurial releases yet.
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.