Matt Harbison <matt_harbison@yahoo.com> [Thu, 17 Dec 2020 00:48:36 -0500] rev 46124
mergetools: alphabetize the config settings
This will make it easier to identify differences with the TortoiseHg config
file. It was simply piped through `sort`, and then the spacing and comments
restored into the proper place. The `UltraCompare` config was positioned such
that the sort is case insensitive- it's the only camelcase config in here.
Differential Revision: https://phab.mercurial-scm.org/D9620
Joerg Sonnenberger <joerg@bec.de> [Mon, 14 Dec 2020 19:48:35 +0100] rev 46123
share: properly copy cache files when cloning from a share
If a is shared to b and b cloned to c, the old code would look directly
under b/.hg for the cache directory and not use the cachevfs layer to
pick the members from a/.hg/cache. Adjust variable names and comments to
reflect that the function is used for more than just the branchmap
cache.
Differential Revision: https://phab.mercurial-scm.org/D9598
Joerg Sonnenberger <joerg@bec.de> [Mon, 14 Dec 2020 18:19:58 +0100] rev 46122
tests: workaround for a flaky test
Differential Revision: https://phab.mercurial-scm.org/D9597
Joerg Sonnenberger <joerg@bec.de> [Sun, 13 Dec 2020 00:19:03 +0100] rev 46121
revlog: support none compression
revlog files had uncompressed revlog entries support since forever, but
it wasn't selectable or exposed explicitly. It is occassionally useful
for performance testing as it avoids the latency of zlib or zstd. It
also has the nice side effect of providing a non-default compression
engine out-of-the-box.
Differential Revision: https://phab.mercurial-scm.org/D9572
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Nov 2020 10:41:03 -0800] rev 46120
errors: raise InputError on recursive template definition
Differential Revision: https://phab.mercurial-scm.org/D9602
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 16:39:53 -0800] rev 46119
errors: raise StateError when push fails because it creates new heads
I decided to raise `StateError` here because the local and remote
repos are in an incompatible state. I think remote errors (exit code
100) should be when something goes wrong on the remote and there's
nothing the user can do.
Differential Revision: https://phab.mercurial-scm.org/D9391
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 10:38:05 -0800] rev 46118
errors: raise InputError on early parse error in dispatch
I didn't think this would have any effect on the tests, but it does
because the catching in `scmutil.callcatch()` still happens. That's
because `dispatch` passes in the function that includes the parsing as
an argument to that function.
I initially used `ConfigError` here but Matt Harbison convinced me to
use `InputError`. I think that makes sense since error is not in a
config file.
Differential Revision: https://phab.mercurial-scm.org/D9387
Martin von Zweigbergk <martinvonz@google.com> [Wed, 18 Nov 2020 23:37:09 -0800] rev 46117
errors: raise more specifc errors from narrowcommands
Differential Revision: https://phab.mercurial-scm.org/D9386
Martin von Zweigbergk <martinvonz@google.com> [Wed, 09 Dec 2020 19:40:30 -0800] rev 46116
errors: use detailed exit code 50 for StorageError
This is done as part of
https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan.
Differential Revision: https://phab.mercurial-scm.org/D9601
Martin von Zweigbergk <martinvonz@google.com> [Wed, 09 Dec 2020 20:22:25 -0800] rev 46115
errors: raise InputError if an ambiguous revision id prefix is used
It's long bothered me that we include the "00changelog.i" part in a
message to the user. This fixes that along with the exit code.
Differential Revision: https://phab.mercurial-scm.org/D9600
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Dec 2020 01:18:15 -0800] rev 46114
localrepo: delete obsolete comment about `prefix in repo` raising exception
We dropped support for `prefix in repo`, where `prefix` is a hex
prefix, in
8b86acc7aa64 (context: drop support for looking up context
by ambiguous changeid (API), 2018-04-28), after having deprecated it a
while before that. These days you get a `ProgrammingError` instead if
you pass in a short nodeid.
Differential Revision: https://phab.mercurial-scm.org/D9599
Joerg Sonnenberger <joerg@bec.de> [Tue, 01 Dec 2020 21:54:46 +0100] rev 46113
node: import symbols explicitly
There is no point in lazy importing mercurial.node, it is used all over
the place anyway. So consistently import the used symbols directly.
Fix one file using symbols indirectly via mercurial.revlog.
Differential Revision: https://phab.mercurial-scm.org/D9480
Martin von Zweigbergk <martinvonz@google.com> [Sun, 13 Dec 2020 18:29:22 -0800] rev 46112
branching: merge with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 11 Dec 2020 15:25:11 +0100] rev 46111
debugdiscovery: fix swapped heads and roots
Patch provided without comment…
Differential Revision: https://phab.mercurial-scm.org/D9566
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 11 Dec 2020 12:51:09 +0100] rev 46110
debugdiscovery: display the number of roundtrip used
This is a good metric of the complexity of a discovery process.
Differential Revision: https://phab.mercurial-scm.org/D9565
Kyle Lippincott <spectral@google.com> [Fri, 11 Dec 2020 13:39:56 -0800] rev 46109
copies: make calculating lazy for dir move detection's "addedfiles"
The information calculated here was only needed if (a) --debug was specified, or
(b) a directory move was plausibly detected. With tree manifests (especially in
my pathological repo and with our custom setup), pre-calculating the `u1` and
`u2` can be quite slow, and it's not even necessary in many cases. Let's delay
calculating it until we know it's actually necessary. This should have no
observable differences in output.
### Performance
I ran a rebase command in my pathological repo, rebasing two nodes across
several public phase commits, but where no directory copies exist in any of the
paths I'm tracking.
#### Before
```
Time (mean ± σ): 3.711 s ± 0.061 s [User: 0.3 ms, System: 1.5 ms]
Range (min … max): 3.640 s … 3.827 s 10 runs
```
#### After
```
Time (mean ± σ): 868.3 ms ± 10.1 ms [User: 0.5 ms, System: 1.2 ms]
Range (min … max): 856.6 ms … 883.6 ms 10 runs
```
Differential Revision: https://phab.mercurial-scm.org/D9567
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Dec 2020 16:45:13 -0800] rev 46108
mergetools: add new conflict marker format with diffs in
I use 3-way conflict markers. Often when I resolve them, I manually
compare one the base with one side and apply the differences to the
other side. That can be hard when the conflict marker is large. This
patch introduces a new type of conflict marker, which I'm hoping will
make it easier to resolve conflicts.
The new format uses `<<<<<<<` and `>>>>>>>` to open and close the
markers, just like our existing 2-way and 3-way conflict
markers. Instead of having 2 or 3 snapshots (left+right or
left+base+right), it has a sequence of diffs. A diff looks like this:
```
------- base
+++++++ left
a
-b
+c
d
```
A diff that adds one side ("diff from nothing") has a `=======` header
instead and does not have have `+` prefixed on its lines. A regular
3-way merge can be viewed as adding one side plus a diff between the
base and the other side. It thus has two ways of being represented,
depending on which side is being diffed:
```
<<<<<<<
======= left
contents
on
left
------- base
+++++++ right
contents
on
-left
+right
>>>>>>>
```
or
```
<<<<<<<
------- base
+++++++ left
contents
on
-right
+left
======= right
contents
on
right
>>>>>>>
```
I've made it so the new merge tool tries to pick a version that has
the most common lines (no difference in the example above).
I've called the new tool "mergediff" to stick to the convention of
starting with "merge" if the tool tries a regular 3-way merge.
The idea came from my pet VCS (placeholder name `jj`), which has
support for octopus merges and other ways of ending up with merges of
more than 3 versions. I wanted to be able to represent such conflicts
in the working copy and therefore thought of this format (although I
have not yet implemented it in my VCS). I then attended a meeting with
Larry McVoy, who said BitKeeper has an option (`bk smerge -g`) for
showing a similar format, which reminded me to actually attempt this
in Mercurial.
Differential Revision: https://phab.mercurial-scm.org/D9551
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Dec 2020 14:39:22 -0800] rev 46107
diff: deprecate -r option
The new `--from`/`--to` options should be enough to support all the
uses cases and are easier to understand, so there is no reason that
I'm aware of to use `-r` anymore.
Differential Revision: https://phab.mercurial-scm.org/D9564
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Dec 2020 12:06:55 -0800] rev 46106
diff: update synopsis to use --from/--to instead of -r
Differential Revision: https://phab.mercurial-scm.org/D9563
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Dec 2020 12:00:45 -0800] rev 46105
diff: describe behavior by using --from/--to instead of varying revision count
I very recently updated the documentation to prefer `--from`/`--to`
over `-r`, but I missed the plain-text description of how the command
behaves when given different numbers of revisions (I guess I just
scanned the text for "-r"). This patch fixes that.
Differential Revision: https://phab.mercurial-scm.org/D9562
Augie Fackler <augie@google.com> [Thu, 10 Dec 2020 13:15:15 -0500] rev 46104
histedit: adjust comment describing `edit` action for clarity
Differential Revision: https://phab.mercurial-scm.org/D9561
Augie Fackler <augie@google.com> [Thu, 10 Dec 2020 11:42:49 -0500] rev 46103
histedit: tweak `edit` message to try and guide users to our workflow
histedit predates evolve, so it drops you on an _uncommitted_ version
of the commit you're amending/splitting, which is in contrast to git
which expects you to use `git commit --amend` (I think - I'm basing
this on internal bug reports). My hope is that this output will guide
users a little more towards the expected workflow.
Differential Revision: https://phab.mercurial-scm.org/D9560
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 10 Dec 2020 14:03:46 +0530] rev 46102
procutil: don't assign stdin to None, use os.devnull instead
It will be painful to take care of procutil.stdin being None everywhere.
Thanks to Yuya who recommended it.
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 10 Dec 2020 13:51:56 +0530] rev 46101
dispatch: move IOError handling and flushing of streams to `dispatch()`
Instead of patching both dispatch code and commandserver code, we directly
handle this in `dispatch.dispatch()`.
Thanks to Yuya who recommended this.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 09 Dec 2020 00:00:19 -0800] rev 46100
simplemerge: write output only once it's complete
`simplemerge()` can write either to `ui.fout` or to the file context
(for in-memory merge). This patch simplifies the code a bit by making
it build the output the same way regardless of where it's written, and
then writes the whole output at once. I don't think it will be a
problem that we don't output anything until the whole file is merged
even if the file is large.
Differential Revision: https://phab.mercurial-scm.org/D9550
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Dec 2020 23:05:53 -0800] rev 46099
simplemerge: avoid quadratic concatenation when building output text
I haven't checked if the difference is measurable, but the new version
is no less readable or idiomatic, so I don't think performance numbers
are needed.
Differential Revision: https://phab.mercurial-scm.org/D9549
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Dec 2020 22:59:17 -0800] rev 46098
simplemerge: work with opts as native strings instead of bytes
There was little reason to use `pycompat.byteskwargs()` in
`simplemerge()` as far as I could tell.
Differential Revision: https://phab.mercurial-scm.org/D9548
Matt Harbison <matt_harbison@yahoo.com> [Tue, 08 Dec 2020 12:43:18 -0500] rev 46097
hghave: update the check for virtualenv
This started as `hghave --test-features` failing on Windows in `test-hghave.t`.
IDK how this worked, as neither my Linux nor Windows machines have the old
attribute with virtualenv 20.2.2, even on py2. I think this was noticed
recently because
357d8415aa27 mentioned an AttributeError, and mitigated by
making this py2 only. But as mentioned, this is also a problem on py2 (where
the failure was observed).
When I got this working by removing the attribute reference, the command in the
test failed because the `--no-site-package` argument was removed some time ago.
Therefore, this backs out
357d8415aa27 and references a known good attribute
(which was done to suppress the warning about an unused import) that also
ensures the command does not need the argument. Since there appears to be
(minor) broken stuff on py3, manually apply the `no-py3` guard that was backed
out of the check itself.
Differential Revision: https://phab.mercurial-scm.org/D9547
Joerg Sonnenberger <joerg@bec.de> [Sat, 05 Dec 2020 23:35:55 +0100] rev 46096
singlehead: introduce option to restrict to public changes
The new experimental.single-head-per-branch:public-changes-only option
restricts the single-head-per-branch filter to public changesets. This
is useful when serving one repository with different views as publishing
and non-publishing repository.
Differential Revision: https://phab.mercurial-scm.org/D9525
Kyle Lippincott <spectral@google.com> [Thu, 03 Dec 2020 14:39:39 -0800] rev 46095
treemanifest: stop storing full path for each item in manifest._lazydirs
This information is obtainable, if needed, based on the lazydirs key (which is
the entry name) and the manifest's `dir()` method.
### Performance
This is actually both a memory and a performance improvement, but it's likely to
be a very small one in most situations. In the pathological repo I've been using
for testing other performance work I've done recently, this reduced the time for
a rebase operation (rebasing two commits across a public-phase change that
touches a sibling of one of my tracked directories where the common parent is
massive (>>10k entries)):
#### Before
```
Time (mean ± σ): 4.059 s ± 0.121 s [User: 0.9 ms, System: 0.6 ms]
Range (min … max): 3.941 s … 4.352 s 10 runs
```
#### After
```
Time (mean ± σ): 3.707 s ± 0.060 s [User: 0.8 ms, System: 0.8 ms]
Range (min … max): 3.648 s … 3.818 s 10 runs
```
Differential Revision: https://phab.mercurial-scm.org/D9553