Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Jun 2017 15:03:13 -0700] rev 33041
unbundle: move BundleUnknownFeatureError exception handling out
This just moves the BundleUnknownFeatureError exception handling one
level up so we collect the bundle2.applybundle{,1}() calls
together. applybundle1() will never throw the exception, so it should
have no functional consequence.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 21 Jun 2017 21:08:48 -0700] rev 33040
bundle: make applybundle1() return a bundleoperation
See previous commit for motivation. It already lets us share a little
bit more code in commands.py.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jun 2017 10:25:11 -0700] rev 33039
bundle: add a applybundle1() method
This is one step towards removing a bunch of "if isinstance(gen,
unbundle20)" by treating bundle1 and bundle2 more similarly.
The name may sounds ironic for a method in the bundle2 module, but I
didn't think it was worth it yet to create a new 'bundle' module that
depends on the 'bundle2' module. Besides, we'll inline the method
again later.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Jun 2017 15:59:07 -0700] rev 33038
bundle: extract _processchangegroup() method
The new method applies the changegroup and fills in op.records,
sharing a little bit of code between the two callers. We'll add
another caller soon.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Jun 2017 14:04:13 -0700] rev 33037
bundle: make combinechangegroupresults() take a bundleoperation
Both callers have a bundleoperation. Passing it in lets us share a bit
more code.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Jun 2017 13:58:20 -0700] rev 33036
bundle: move combineresults() from changegroup to bundle2
The results only need to be combined if they come from a bundle2. More
importantly, we'll change its argument to a bundleoperation soon, and
then it definitely will no longer belong in changegroup.py.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 21 Jun 2017 14:42:04 -0700] rev 33035
bundle: remove 'op' argument from applybundle()
No callers pass in an operation.
Jun Wu <quark@fb.com> [Sat, 24 Jun 2017 10:31:41 -0700] rev 33034
test-rebase-conflicts: add a test case about turning obsstore on and off
Turning obsstore and allowunstable on, rebase will skip the
"can't remove original changesets with unrebased descendants" check. Then
rebase could be interrupted (merge conflict), and the user has a chance to
turn off obsstore. If rebase continues, the current code may strip
irrelevant commits (in the test case added, "C" got stripped unexpectedly).
The test case reproduces
issue5606. It will be fixed by the "multidest"
rebase refactoring being reviewed. The test case itself is relatively
separate from the rebase refactoring, therefore sent separately hoping to
reduce the number of patches of the main rebase series.
Augie Fackler <augie@google.com> [Sat, 24 Jun 2017 15:50:13 -0400] rev 33033
merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Jun 2017 00:15:52 -0700] rev 33032
strip: include phases in bundle (BC)
Before this patch, unbundling a stripped changeset would make it a
draft (unless the parent was secret). This meant that one would lose
phase information when stripping and unbundling secret changesets. The
same thing was true for public changesets. While stripping public
changesets is generally rare, it's done frequently by e.g. the
narrowhg extension.
We also include the phases in the temporary bundle, just in case
stripping were to fail after that point, so the user can still restore
the repo including phase information. Before this patch, the phases
were left untouched during the bundling and unbundling of the
temporary bundle. Only at the end of the transaction would
phasecache.filterunknown() be called to remove phase roots that were
no longer valid. We now need to call that also after the first
stripping, i.e. before applying the temporary bundle. Otherwise
unbundling the temporary bundle will cause a read of the phase cache
which has stripped changesets in the cache and that fails.
Like with obsmarkers, we unconditionally include the phases in the
bundle when stripping (when using bundle2, such as when generaldelta
is enabled). The reason for doing that for strip but not for bundle is
that strip bundles are not meant to be shared outside the repo, so we
don't care as much about compatibility.