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.
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.
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.
Since its introduction in c7ec460797a9, the parameter has always been name
"error". Yet the eol extension have been using 'haserror' as the argument name,
breaking extensions with subclass passing 'error' as a keyword argument.
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.
This adds an experimental.bundle-phases config option to include phase
information in bundles. As with the recently added support for
bundling obsmarkers, the support for bundling phases is hidden behind
the config option until we decide to make a bundlespec v3 that
includes phases (and obsmarkers and ...).
We could perhaps use the listkeys format for this, but that's
considered obsolete according to Pierre-Yves. Instead, we introduce a
new "phase-heads" bundle part. The new part contains the phase heads
among the set of bundled revisions. It does not include those in
secret phase; any head in the bundle that is not mentioned in the
phase-heads part is assumed to be secret. As a special case, an empty
phase-heads part thus means that any changesets should be added in
secret phase. (If we ever add a fourth phase, we'll include secret in
the part and we'll add a version number.)
For now, phases are only included by "hg bundle", and not by
e.g. strip and rebase.
When adding support for bundling and unbundling phases, it will be
useful to have the list of added changesets. To do that, we return the
list from changegroup.apply().
Earlier I used pycompat.bytestr() to convert integers to bytes, but we can do
b"%d" % val to convert that int to bytes. b'' is already added by the
transformer.
Thanks to Yuya for suggesting this.
If an extension was loaded but disabled due to a minimumhgversion check it
will be present in the _extensions map, but set to None. The rest of the
extensions code treats the extension as if it were not present in this case,
but the afterloaded() function called the callback with loaded=True.
Before this patch, -e/--edit and -e/--ssh of fetch command collide
against each other. This causes that -e is treated as shorthand of
--edit but doesn't work as same as --edit. Therefore, -e works as
neither --edit nor --ssh, in practice.
This issue was introduced at f54ee4b17f46 (or 1.0), which renamed
-f/--force-editor to -e/--edit. At that point, -e was already used as
shorthand of --ssh.
After this patch, -e is treated as shorthand of --ssh.
This patch is marked as "(BC)", because -e as shorthand of --edit in
existing scripts causes failure (or unexpected result) after this
patch. This impact should be less enough, because --edit mainly
focuses on interactive use.
BTW, test-duplicateoptions.py (since 1f980ef518d2 or 1.9) can't detect
this kind of issues as expected, because direct invocation of
extensions.loadall() doesn't involve registration of commands defined
in extensions (this issue is fixed in subsequent patch).
Earlier, on parsing the bullet points from existing release notes the bullet
points after the first one weren't written correctly to the notes file. This
patch makes changes to parsereleasenotesfromfile() function that introduces a new
bullet_points data structure that tracks the bullets and associated subparagraph.
It also makes necessary changes to the tests related to merging of bullets.
This allows even further customization via extensions for printing
bookmarks. For example, in hg-git this would allow printing remote refs
by just modifying the 'bmarks' parameter instead of reimplementing the
old commands.bookmarks method.
Furthermore, there is another benefit: now multiple extensions can
chain their custom data to bookmark printing. Previously, an extension
could have conflicting bookmark output due to which loaded first and
overrode commands.bookmarks. Now they can all play nicely together.
Note that this means that we're unnecessarily creating a transaction
in the pure "--inactive" (i.e. when deactivating the current
bookmark), but that should be harmless.
This path is also used for extdiff, which is how I crossed paths with it.
Without this, an AttributeError occurs looking for 'lfstatus' on
localrepository. See also ca0085e432d6.
The other archive method is for the archival.py override, so it doesn't need to
be special cased like this. (It looks like it is only called for the top level
repo.) Likewise, the transplant override is also for commands.py. The other
overrides set lfstatus before examining it.
This is necessary to implement the set{gen} (set subscript) operator. For
example, set{-n} will be translated to ancestors(set, depth=n, startdepth=n).
https://www.mercurial-scm.org/wiki/RevsetOperatorPlan#ideas_from_mpm
The UI is undecided and I doubt if the startdepth option would be actually
useful, so the option is hidden for now. 'depth' could be extended to take
min:max range, in which case, integer depth should select a single generation.
ancestors(set, depth=:y) # scan up to y-th generation
ancestors(set, depth=x:) # skip until (x-1)-th generation
ancestors(set, depth=x) # select only x-th generation
Any ideas are welcomed.
# reverse(ancestors(tip)) using hg repo
3) 0.075951
4) 0.076175
Surprisingly, this makes revset benchmark slightly faster. I don't know why,
but it appears that wrapping -inputrev by tuple is the key. So I decided to
just enable depth computation by default.
# reverse(ancestors(tip)) using hg repo
1) 0.081051
2) 0.075408
Since we're using a max heap, the current rev should be a duplicate only
if it equals to the previous one. We don't have to maintain the whole seen
set.
# reverse(ancestors(tip)) using hg repo
0) 0.086420
1) 0.081051
- h -> pendingheap: "h" seems too short for variable of long lifetime
- current -> currev: future patches will add current "depth" variable
- parent -> prev or pctx: short lifetime, follows common naming rules
Add the followlines.js script and corresponding parameters as data attribute
on <tbody class="sourcelines"> element.
Extend CSS rules so that they also match the DOM structure of annotate view.
As previously, only address paper and gitweb styles (other styles do not have
followlines at all).
While plugging followlines.js into "annotate" view, we'll need to walk a
different DOM structure from that of "filerevision" view. In particular, the
selectable source line element is a <tr> in annotate view (in contrast with a
<span> in filerevision view). So make this tag name a parameter of
followlines.js script by passing its value as a "selectabletag" data attribute
of <pre class="sourcelines"> element.
As <pre class="sourcelines"> tags are getting quite long in templates, rewrite
them on several lines.
We will use this element to hook data attribute for the followlines.js script
to be plugged in annotate view. Also this gets symmetrical with paper style
which already has a <tbody> element.
On some systems, e.g. Docker container, the actual error may be:
error fetching bundle: [Errno 99] Cannot assign requested address
Update the regex to handle this case.
