Matt Harbison <matt_harbison@yahoo.com> [Wed, 19 Feb 2020 13:33:58 -0500] rev 44449
phabricator: pass old `fctx` to `addoldbinary()` instead of inferring it
Currently, removed binaries aren't marked as binaries on the left side, which
sends the raw file view to a bad URL in the web interface. (See D8009) In order
to handle marking the file as binary in the removed case, both contexts need to
be provided by the caller, since there is no current fctx in the removed case.
Having an explicit old fctx will also be useful to support a `--no-stack` option
that rolls up the commit stack into a single review.
The bug isn't fixed with this change- there's a missing call to it in
`addremoved()` as well. But instead of spamming the list with a bunch of test
diffs, all of the missing binary issues will be fixed at once later.
Differential Revision: https://phab.mercurial-scm.org/D8218
Matt Harbison <matt_harbison@yahoo.com> [Wed, 04 Mar 2020 10:25:07 -0500] rev 44448
phabricator: make `hg phabread` work outside of a repository
This is similar to 16312ea45a8b and 2513f0f70a26- we don't need a repo, but will
load .hg/hgrc if inside one.
Differential Revision: https://phab.mercurial-scm.org/D8214
Matt Harbison <matt_harbison@yahoo.com> [Sun, 16 Feb 2020 15:06:20 -0500] rev 44447
phabricator: refactor `phabread` to write all patches at once
This will be necessary to create a first class `phabimport` command. That
command requires a transaction, and will import all named patches within a
single transaction. But if Phabricator queries also happen within the
transaction, that leaves open the chance that an exception is raised, the
transaction is abandoned, and the next command that is run will complain about
needing to run `hg recover`.
Differential Revision: https://phab.mercurial-scm.org/D8135
Matt Harbison <matt_harbison@yahoo.com> [Mon, 17 Feb 2020 13:14:44 -0500] rev 44446
phabricator: make `hg phabupdate` work outside of a repository
This is similar to 16312ea45a8b- we don't need a repo, but will load .hg/hgrc if
inside one.
Differential Revision: https://phab.mercurial-scm.org/D8208
Matt Harbison <matt_harbison@yahoo.com> [Mon, 17 Feb 2020 13:28:40 -0500] rev 44445
phabricator: pass ui instead of repo to `userphids()`
Also not a repository operation.
Differential Revision: https://phab.mercurial-scm.org/D8207
Matt Harbison <matt_harbison@yahoo.com> [Mon, 17 Feb 2020 13:08:01 -0500] rev 44444
phabricator: pass ui instead of repo to `querydrev()`
Also not a repository operation.
Differential Revision: https://phab.mercurial-scm.org/D8206
Matt Harbison <matt_harbison@yahoo.com> [Mon, 17 Feb 2020 13:01:16 -0500] rev 44443
phabricator: pass ui instead of repo to `readpatch()`
This makes it a little clearer that it isn't a repository operation.
Differential Revision: https://phab.mercurial-scm.org/D8205
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 02 Mar 2020 14:36:20 -0500] rev 44442
logtoprocess: avoid traceback when running long commands
$ hg log -r "present($(yes | tr -d '\n' | head -c 130000))" "$(yes | tr -d '\n' | head -c 5000)" --config extensions.logtoprocess= --config logtoprocess.commandfinish=whatever
Traceback (most recent call last):
File "/usr/bin/hg", line 67, in <module>
dispatch.run()
File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 111, in run
status = dispatch(req)
File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 290, in dispatch
canonical_command=req.canonical_command,
File "/usr/lib64/python2.7/site-packages/mercurial/ui.py", line 1991, in log
logger.log(self, event, msg, opts)
File "/usr/lib64/python2.7/site-packages/hgext/logtoprocess.py", line 72, in log
procutil.runbgcommand(script, fullenv, shell=True)
File "/usr/lib64/python2.7/site-packages/mercurial/utils/procutil.py", line 597, in runbgcommand
b'error running %r: %s' % (cmd, os.strerror(returncode)),
OSError: [Errno 7] error running 'whatever': Argument list too long
This can happen if you pass a bunch of filenames to hg commit, for instance.
This is due to a size limit on individual env vars (on linux, but I
imagine there are similar limits in other OSes):
$ FOO=$(yes | head -c 131000) /usr/bin/true
$ FOO=$(yes | head -c 132000) /usr/bin/true
-bash: /usr/bin/true: Argument list too long
I propose to avoid this by truncating the message. I didn't make the
limit configurable as it doesn't seem particularly convenient to
customize this. I'm not sure if various OSes would want radically
different limits here?
Differential Revision: https://phab.mercurial-scm.org/D8203
Raphaël Gomès <rgomes@octobus.net> [Mon, 24 Feb 2020 17:57:57 +0100] rev 44441
rust-cpython: make `NonNormalEntires` iterable to fix `fsmonitor` (issue6276)
This fixes a bug when using `fsmonitor` that tries to iterate on the non normal
set, by adding a shared iterator interface.
Differential Revision: https://phab.mercurial-scm.org/D8143
Joerg Sonnenberger <joerg@bec.de> [Sat, 07 Sep 2019 14:50:39 +0200] rev 44440
hgext: start building a library for simple hooks
Many workflows depend on hooks to enforce certain policies, e.g. to
prevent forced pushes. The Mercurial Guide includes some cases and
Google can help finding others, but it can save users a lot of time
if hg itself has a couple of examples for further customization.
Differential Revision: https://phab.mercurial-scm.org/D6825
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Tue, 25 Feb 2020 20:27:39 -0500] rev 44439
exchange: turn on option that makes concurrent pushes work better
The motivation is simply to make hg work better out of the box.
This is a slight backwards compatibility break, because client
extensions could have assumed that the list of heads the client sees
during discovery will be the list of heads during the entirety of the
push. It seems unlikely to matter, and not worth mentioning.
There's a fair amount of diff in tests, but this is just due to
sending a few more bytes on the wire, except for test-acl.t.
The extra "invalid branch cache" lines in test-acl.t don't seem to
indicate a problem: the branchcache now get computed during the bundle
application (because of the check:updated-heads bundle part), but
doesn't get rolled back when transactions rollback, thus causing a
message in the next operation computing the branch cache. Before this
change, I assume the branchcache was only computed on transaction
commit, so not computed at all when the transactions roll back, thus
no messages.
Differential Revision: https://phab.mercurial-scm.org/D8202
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 02 Mar 2020 15:34:51 -0500] rev 44438
update: simplify slightly
Differential Revision: https://phab.mercurial-scm.org/D8204
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 01 Mar 2020 21:16:45 -0500] rev 44437
help: clarify behavior of server.concurrent-push-mode
So it doesn't seemingly say that old clients cannot talk to server
configured with concurrent-push-mode=check-related. They can, they
just don't get the benefit.
Differential Revision: https://phab.mercurial-scm.org/D8201
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Feb 2020 10:30:18 -0800] rev 44436
commit: error out on unresolved files even if commit would be empty
Differential Revision: https://phab.mercurial-scm.org/D8195
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Feb 2020 10:49:13 -0800] rev 44435
tests: add test of committing with conflicts but no changes in wdir
I'm about to change the behavior slightly here, so let's have a test
that shows that.
Differential Revision: https://phab.mercurial-scm.org/D8194
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 28 Feb 2020 00:17:26 +0100] rev 44434
transaction: clarify the logic around pre-finalize/post-finalize
I am taking a bit more verbose route, but I find it easier to follow for people
who (re)discover the code.
(This is a gratuitous cleanup I did while looking at something else.)
Differential Revision: https://phab.mercurial-scm.org/D8176
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 28 Feb 2020 00:02:03 +0100] rev 44433
transaction: move constant to upper case
These constant are internal to the module and can be safely renamed. Having them
upper case help to clarify their "constant" status.
(This is a gratuitous cleanup I did while looking at something else.)
Differential Revision: https://phab.mercurial-scm.org/D8175
Joerg Sonnenberger <joerg@bec.de> [Wed, 26 Feb 2020 22:26:28 +0100] rev 44432
tests: handle In-Reply-To headers for line wrapping
Python 3 tends to insert a newline for both Message-ID and In-Reply-To
headers, so unwrap both. Just check the wrapped line format explicitly
without regular expression.
Differential Revision: https://phab.mercurial-scm.org/D8171
Martin von Zweigbergk <martinvonz@google.com> [Wed, 26 Feb 2020 10:48:56 -0800] rev 44431
tests: use new, use-case-specific methods from merge module
Differential Revision: https://phab.mercurial-scm.org/D8169
Martin von Zweigbergk <martinvonz@google.com> [Wed, 26 Feb 2020 10:40:31 -0800] rev 44430
merge: introduce a merge() for that use-case
In the same vein as some earlier patches like f546d2170b0f (merge:
introduce a clean_update() for that use-case, 2020-01-15).
Differential Revision: https://phab.mercurial-scm.org/D8168
Martin von Zweigbergk <martinvonz@google.com> [Wed, 26 Feb 2020 11:00:50 -0800] rev 44429
merge: drop redundant mergeforce argument from hg.merge()
The only caller that passed a value for either `force` or `mergeforce`
passed the same value for both, so let's simplify the interface by
accepting only `force`.
Differential Revision: https://phab.mercurial-scm.org/D8167
Martin von Zweigbergk <martinvonz@google.com> [Wed, 26 Feb 2020 10:54:17 -0800] rev 44428
merge: change default of hg.merge()'s "force" argument from None to False
The argument is only passed to `mergemode.update()`, and that function
treats `None` just like `False`, so `False` seems clearer.
Differential Revision: https://phab.mercurial-scm.org/D8166
Martin von Zweigbergk <martinvonz@google.com> [Thu, 13 Feb 2020 21:14:20 -0800] rev 44427
debugmergestate: make templated
Our IntelliJ team wants to be able to read the merge state in order to
help the user resolve merge conflicts. They had so far been reading
file contents from p1() and p2() and their merge base. That is not
ideal for several reasons (merge base is not necessarily the "graft
base", renames are not handled, commands like `hg update -m` is not
handled). It will get especially bad as of my D7827. This patch makes
the output s a templated. I haven't bothered to make it complete
(e.g. merge driver states are not handled), but it's probably good
enough as a start.
I've done a web search for "debugmergestate" and I can't find any
indication that any tools currently rely on its output. If it turns
out that we get bug reports for it once this is released, I won't
object to backing this patch out on the stable branch (and then
perhaps replace it by a separate command, or put it behind a new
flag).
The changes in test-backout.t are interesting, in particular this:
```
- other path: foo (node not stored in v1 format)
+ other path: (node foo)
```
I wonder if that means that we actually read v1 format
incorrectly. That seems to be an old format that was switched away
from in 2014, so it doesn't matter now anyway.
Differential Revision: https://phab.mercurial-scm.org/D8120
Martin von Zweigbergk <martinvonz@google.com> [Thu, 13 Feb 2020 21:55:38 -0800] rev 44426
tests: add tests of debugmergestate with unresolved/resolved path conflicts
I'm about to change `hg debugmergestate` and it broke on these "pu"
and "pr" records on my first attempt (D8113), so let's add test
coverage.
Differential Revision: https://phab.mercurial-scm.org/D8119
Martin von Zweigbergk <martinvonz@google.com> [Thu, 13 Feb 2020 17:15:08 -0800] rev 44425
mergestate: determine if active without looking for state files on disk
I couldn't think of a reason that we need to check state files on disk
to determine if a merge is active. I could imagine them being for
there for detecting broken state files that would then be cleaned up
by some later command, but we always delete the entire `.hg/merge/`
tree, so that doesn't seem to be it.
The checks were added in 4e932dc5c113 (resolve: abort when not
applicable (BC), 2014-04-18). Perhaps there were needed for that and
then made obsolete by 6062593d8b06 (resolve: don't abort resolve -l
even when no merge is in progress, 2014-05-23).
The reason I want to delete the checks is that I think `ms =
mergestate.read(repo); ms.active() and ms.local` should be a valid
pattern, but it crashes when the merge state file is an empty file if
we consider mere presence of the file as "active".
Differential Revision: https://phab.mercurial-scm.org/D8118
Matt Harbison <matt_harbison@yahoo.com> [Wed, 26 Feb 2020 14:43:02 -0500] rev 44424
phabricator: update the protocol documentation
The `branch` property wasn't added to the `hg:meta` example when it was added to
the metadata in d49ab47be8a6. Additionally, `properties` in the Differential
Revision dict is a dinctionary, not a list. While here, also alphabetize the
responses from Phabricator because that's how it is being printed with
`hg debugcallconduit`, and this makes it easier to compare.
Differential Revision: https://phab.mercurial-scm.org/D8170
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Wed, 26 Feb 2020 10:56:27 -0500] rev 44423
relnotes: move entry to the right spot
It appears a conflict resolution went wrong.
Differential Revision: https://phab.mercurial-scm.org/D8151
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 26 Feb 2020 17:16:25 +0100] rev 44422
revlog-compression: release note entry for update the config to be a list
I updated the changeset, but forgot to phabsend apparently.
Differential Revision: https://phab.mercurial-scm.org/D8165
Georges Racinet <georges.racinet@octobus.net> [Tue, 18 Feb 2020 19:11:18 +0100] rev 44421
rust-nodemap: a method for full invalidation
This will be used for exceptional operations,
such as a `__delitem__` on the `MixedIndex` with
Rust nodemap.
In principle, `NodeTree` should also be able to forget
an entry in an efficient way, by accepting to insert
`Element::None` instead of only `Element::Rev(r)`,
but that seems really overkill at this point. We need
to support exceptional operations such as `__delitem__`,
only for completeness of the revlog index as seen from
Python. The Python callers don't seem to even really
need it, deciding to drop the nodemap unconditionally at
at higher level when calling `hg strip`. Also, `hg strip`
is very costly for reasons that are unrelated to nodemap
aspects.
Differential Revision: https://phab.mercurial-scm.org/D8098
Georges Racinet <georges.racinet@octobus.net> [Tue, 18 Feb 2020 19:11:17 +0100] rev 44420
rust-nodemap: accounting for dead blocks
By the very append-only nature of the `NodeTree`, inserting
new blocks has the effect of making some of the older ones
useless as they become unreachable.
Therefore some automatic housekeeping will need to be provided.
This is standard procedure in the word of databases, under names
such as "repack" or "vacuum".
The new `masked_readonly_blocks()` will provide callers with
useful information to decide if the nodetree is ripe for
repacking, but all the `NodeTree` can provide is how many
blocks have been masked in the currently mutable part. Analysing
the readonly part would be way too long to do it for each
transaction and defeat the whole purpose of nodemap persistence.
Serializing callers (from the Python layer) will get this figure
before each extraction and maintain an aggregate counter of
unreachable blocks separately.
Note: at this point, the most efficient repacking is just to restart
afresh with a full rescan.
Differential Revision: https://phab.mercurial-scm.org/D8097
Georges Racinet <georges.racinet@octobus.net> [Tue, 18 Feb 2020 19:11:17 +0100] rev 44419
rust-nodemap: core implementation for shortest
In this implementation, we just make `lookup()` return also the number
of steps that have been needed to come to a conclusion from the
nodetree data, and `validate_candidate()` takes care of the special
cases related to `NULL_NODE`.
This way of doing minimizes code duplication, but it means that
the comparatively slower finding of first non zero nybble will run
for all calls to `find()` where it is not needed.
Still running on the file generated for the mozilla-central repository,
it seems indeed that we now get more ofter 320 ns than 310. The odds that
this could have a significant impact on real life Mercurial performance
are still looking low. Let's wait for actual benchmark runs to see if
an optimization is needed here.
Differential Revision: https://phab.mercurial-scm.org/D7819
Georges Racinet <georges.racinet@octobus.net> [Tue, 18 Feb 2020 19:11:16 +0100] rev 44418
rust-nodemap: special case for prefixes of NULL_NODE
We have to behave as though NULL_NODE was stored in the node tree,
although we don't store it.
Differential Revision: https://phab.mercurial-scm.org/D7798
Georges Racinet <georges.racinet@octobus.net> [Tue, 18 Feb 2020 19:11:15 +0100] rev 44417
rust-nodemap: pure Rust example
To run, use `cargo run --release --example nodemap`
This demonstrates that simple scenarios entirely written
in Rust can content themselves with `NodeTree<T>`.
The example mmaps both the nodemap file and the changelog index.
We had of course to include an implementation of `RevlogIndex`
directly, which isn't much at this stage. It felt a bit
prematurate to include it in the lib.
Here are some first performance measurements, obtained with
this example, on a clone of mozilla-central with 440000
changesets:
(create) Nodemap constructed in RAM in 153.638305ms
(query CAE63161B68962) found in 22.362us: Ok(Some(269489))
(bench) Did 3 queries in 36.418µs (mean 12.139µs)
(bench) Did 50 queries in 184.318µs (mean 3.686µs)
(bench) Did 100000 queries in 31.053461ms (mean 310ns)
To be fair, even between bench runs, results tend to depend whether
the file is still in kernel caches, and it's not so easy to
get back to a real cold start. The worst we've seen was in the
50us ballpark.
In any busy server setting, the pages would always be in RAM.
We hope it's good enough not to be significantly slower on any
concrete Mercurial operation than the C nodetree when fully in RAM,
and of course this implementation has the serious headstart advantage
of persistence.
Differential Revision: https://phab.mercurial-scm.org/D7797
Georges Racinet <georges.racinet@octobus.net> [Tue, 18 Feb 2020 19:11:15 +0100] rev 44416
rust-nodemap: input/output primitives
These allow to initiate a `NodeTree` from an immutable opaque
sequence of bytes, which could be passed over from Python
(extracted from a `PyBuffer`) or directly mmapped from a file.
Conversely, we can consume
a `NodeTree`, extracting the bytes that express what
has been added to the immutable part, together with the
original immutable part.
This gives callers the choice to start a new Nodetree.
After writing to disk, some would prefer to reread for
best guarantees (very cheap if mmapping), some others will
find it more convenient to grow the memory that was considered
immutable in the `NodeTree` and continue from there.
This is enough to build examples running on real data and
start gathering performance hints.
Differential Revision: https://phab.mercurial-scm.org/D7796
Martin von Zweigbergk <martinvonz@google.com> [Thu, 13 Feb 2020 15:33:36 -0800] rev 44415
pyoxidizer: allow extensions to be loaded from the file system
It seems that setting this config is all that's needed to be able to
load extensions from the file system (which we clearly want). Thanks
for making this work, Gregory Szorc!.
Differential Revision: https://phab.mercurial-scm.org/D8122
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 17 Feb 2020 20:30:03 -0500] rev 44414
graft: always allow hg graft --base . (issue6248)
`hg graft --base . -r abc` is rejected before this change with a
"nothing to merge" error, if `abc` does not descend from `.`.
This looks like an artifact of the implementation rather than intended
behavior. It makes perfect sense to apply the diff between `.` and
`abc` to the working copy (i.e. degenerate into `hg revert`),
regardless of what `abc` is.
Differential Revision: https://phab.mercurial-scm.org/D8127
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 19 Feb 2020 17:30:04 +0100] rev 44413
revlog-compression: update the config to be a list
format.revlog-compression is now a list of engine, the first supported one is to
be used. Doing this have several benefits:
1) this is fully backward compatible, config using a single entry will be read
as a single item list, not changing any behavior.
2) This open the way to use zstd by default without impacting platform were it
is not available. This will be done in a later changesets.
Using zstd provide a significant performance boost explained in : bb271ec2fbfb.
However zstd is not available in some cases, A notable example is the `--pure`
version of Mercurial which doesn't come with zstd support.
Differential Revision: https://phab.mercurial-scm.org/D8148
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 19 Feb 2020 13:39:00 +0530] rev 44412
remotefilelog: add 'changelog' arg to shallowcg1packer.generate (issue6269)
This cause traceback on widening using narrow extension when remotefilelog
is enabled.
Differential Revision: https://phab.mercurial-scm.org/D8134
Martin von Zweigbergk <martinvonz@google.com> [Tue, 25 Feb 2020 12:41:35 -0800] rev 44411
drawdag: abide by new createmarkers() API
The `obsolete.createmarkers()` API was changed in 6335c0de80fa
(obsolete: allow multiple predecessors in createmarkers, 2018-09-22)
to prefer its precursors input to be a tuple instead of a single
precursor. Let's fix `drawdag.py` to comply.
Differential Revision: https://phab.mercurial-scm.org/D8149
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Feb 2020 14:52:46 -0500] rev 44410
lfutil: provide a hint if the largefiles/lfs cache path cannot be determined
A coworker hit this error using an LFS repo in a stripped down environment, and
didn't know how to resolve it.
The final conditional is a bit fast and loose, but there is currently no 'posix'
test in hghave, and it doesn't seem like it's worth adding for this since I
think Windows is the only non-POSIX platform we run tests on.
Differential Revision: https://phab.mercurial-scm.org/D8145
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Feb 2020 17:43:34 -0500] rev 44409
tests: replace truncate(1) with inline python
MSYS doesn't have truncate(1) installed by default, and FreeBSD looked unhappy
with the arguments provided.
Differential Revision: https://phab.mercurial-scm.org/D8147
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Feb 2020 16:59:35 -0500] rev 44408
tests: stabilize test-rename-merge2.t on Windows
I have no idea why, but this shifted in b4057d001760.
Differential Revision: https://phab.mercurial-scm.org/D8146
Augie Fackler <augie@google.com> [Mon, 24 Feb 2020 13:50:55 -0500] rev 44407
merge with stable
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Thu, 13 Feb 2020 22:51:17 -0500] rev 44406
bookmarks: prevent pushes of divergent bookmarks (foo@remote)
Before this change, such bookmarks are write-only: a client can push
them but not pull/read them. And because these bookmark can't be read,
even pushes are limited (for instance trying to delete such a bookmark
fails with a vanilla client because the client thinks the bookmark is
neither on the local nor the remote).
This change makes the server refuses such bookmarks, and for earlier
errors, makes the client refuse to send them.
I think the change of behavior is acceptable because I think this is a
bug in push/pull, and I don't think we change the behavior of `hg
unbundle`, because it doesn't seem that `hg bundle` ever store
bookmarks (and even if it did, it would seem weird anyway to try to
send divergent bookmarks).
Differential Revision: https://phab.mercurial-scm.org/D8117
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Thu, 13 Feb 2020 22:06:57 -0500] rev 44405
bookmarks: refactor in preparation for next commit
Differential Revision: https://phab.mercurial-scm.org/D8116
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sat, 15 Feb 2020 14:51:33 -0500] rev 44404
bookmarks: avoid traceback when two pushes race to delete the same bookmark
`hg push -f -B remote-only-bookmark` can raise server-side in
`bookmarks._del` (specifically in `self._refmap.pop(mark)`), if the
remote-only bookmark got deleted concurrently.
Fix this by simply not deleting the non-existent bookmark in that
case.
For avoidance of doubt, refusing to delete a bookmark that doesn't
exist when the push starts is taking care of elsewhere; no change of
behavior there.
Differential Revision: https://phab.mercurial-scm.org/D8124
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sat, 15 Feb 2020 15:06:41 -0500] rev 44403
relnotes: add entry about previous `hg recover` change
Differential Revision: https://phab.mercurial-scm.org/D8123
Kyle Lippincott <spectral@google.com> [Thu, 20 Feb 2020 15:15:23 -0800] rev 44402
darwin: add another preemptive gui() call when using chg
Changeset a89381e04c58 added this gui() call before background forks, and
Google's extensions do background forks on essentially every invocation for
logging purposes. The crash is reliably (though not 100%) reproducible without
this change when running `HGPLAIN=1 chg status` in one of our repos. With this
fix, I haven't been able to trigger the crash anymore.
Differential Revision: https://phab.mercurial-scm.org/D8141
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Dec 2019 13:24:46 -0800] rev 44401
copy: add experimental support for marking committed copies
The simplest way I'm aware of to mark a file as copied/moved after
committing is this:
hg uncommit --keep <src> <dest> # <src> needed for move, but not copy
hg mv --after <src> <dest>
hg amend
This patch teaches `hg copy` a `--at-rev` argument to simplify that
into:
hg copy --after --at-rev . <src> <dest>
In addition to being simpler, it doesn't touch the working copy, so it
can easily be used even if the destination file has been modified in
the working copy.
Differential Revision: https://phab.mercurial-scm.org/D8035
Martin von Zweigbergk <martinvonz@google.com> [Thu, 26 Dec 2019 14:02:50 -0800] rev 44400
copy: move argument validation a little earlier
Argument validation is usually done early and I will want it done
before some code that I'm about to add.
Differential Revision: https://phab.mercurial-scm.org/D8033
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Jan 2020 14:07:57 -0800] rev 44399
copy: add experimetal support for unmarking committed copies
The simplest way I'm aware of to unmark a file as copied after
committing is this:
hg uncommit --keep <dest>
hg forget <dest>
hg add <dest>
hg amend
This patch teaches `hg copy --forget` a `-r` argument to simplify that into:
hg copy --forget --at-rev . <dest>
In addition to being simpler, it doesn't touch the working copy, so it
can easily be used even if the destination file has been modified in
the working copy.
I'll teach `hg copy` without `--forget` to work with `--at-rev` next.
Differential Revision: https://phab.mercurial-scm.org/D8030
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Dec 2019 15:50:13 -0800] rev 44398
copy: add option to unmark file as copied
To unmark a file as copied, the user currently has to do this:
hg forget <dest>
hg add <dest>
The new command simplifies that to:
hg copy --forget <dest>
That's not a very big improvement, but I'm planning to also teach `hg
copy [--forget]` a `--at-rev` argument for marking/unmarking copies
after commit (usually with `--at-rev .`).
Differential Revision: https://phab.mercurial-scm.org/D8029
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 11 Feb 2020 11:18:52 +0100] rev 44397
nodemap: introduce an option to use mmap to read the nodemap mapping
The performance and memory benefit is much greater if we don't have to copy all
the data in memory for each information. So we introduce an option (on by
default) to read the data using mmap.
This changeset is the last one definition the API for index support nodemap
data. (they have to be able to use the mmaping).
Below are some benchmark comparing the best we currently have in 5.3 with the
final step of this series (using the persistent nodemap implementation in
Rust). The benchmark run `hg perfindex` with various revset and the following
variants:
Before:
* do not use the persistent nodemap
* use the CPython implementation of the index for nodemap
* use mmapping of the changelog index
After:
* use the MixedIndex Rust code, with the NodeTree object for nodemap access
(still in review)
* use the persistent nodemap data from disk
* access the persistent nodemap data through mmap
* use mmapping of the changelog index
The persistent nodemap greatly speed up most operation on very large
repositories. Some of the previously very fast lookup end up a bit slower because
the persistent nodemap has to be setup. However the absolute slowdown is very
small and won't matters in the big picture.
Here are some numbers (in seconds) for the reference copy of mozilla-try:
Revset Before After abs-change speedup
-10000: 0.004622 0.005532 0.000910 × 0.83
-10: 0.000050 0.000132 0.000082 × 0.37
tip 0.000052 0.000085 0.000033 × 0.61
0 + (-10000:) 0.028222 0.005337 -0.022885 × 5.29
0 0.023521 0.000084 -0.023437 × 280.01
(-10000:) + 0 0.235539 0.005308 -0.230231 × 44.37
(-10:) + :9 0.232883 0.000180 -0.232703 ×1293.79
(-10000:) + (:99) 0.238735 0.005358 -0.233377 × 44.55
:99 + (-10000:) 0.317942 0.005593 -0.312349 × 56.84
:9 + (-10:) 0.313372 0.000179 -0.313193 ×1750.68
:9 0.316450 0.000143 -0.316307 ×2212.93
On smaller repositories, the cost of nodemap related operation is not as big, so
the win is much more modest. Yet it helps shaving a handful of millisecond here
and there.
Here are some numbers (in seconds) for the reference copy of mercurial:
Revset Before After abs-change speedup
-10: 0.000065 0.000097 0.000032 × 0.67
tip 0.000063 0.000078 0.000015 × 0.80
0 0.000561 0.000079 -0.000482 × 7.10
-10000: 0.004609 0.003648 -0.000961 × 1.26
0 + (-10000:) 0.005023 0.003715 -0.001307 × 1.35
(-10:) + :9 0.002187 0.000108 -0.002079 ×20.25
(-10000:) + 0 0.006252 0.003716 -0.002536 × 1.68
(-10000:) + (:99) 0.006367 0.003707 -0.002660 × 1.71
:9 + (-10:) 0.003846 0.000110 -0.003736 ×34.96
:9 0.003854 0.000099 -0.003755 ×38.92
:99 + (-10000:) 0.007644 0.003778 -0.003866 × 2.02
Differential Revision: https://phab.mercurial-scm.org/D7894
Raphaël Gomès <rgomes@octobus.net> [Fri, 14 Feb 2020 15:03:26 +0100] rev 44396
rust-dirstatemap: directly return `non_normal` and `other_entries`
This cleans up the interface which I previously thought needed to be uglier
than in reality. No performance difference, simple refactoring.
Differential Revision: https://phab.mercurial-scm.org/D8121
Martin von Zweigbergk <martinvonz@google.com> [Thu, 26 Dec 2019 14:12:45 -0800] rev 44395
copy: rename `wctx` to `ctx` since it will not necessarily be working copy
Differential Revision: https://phab.mercurial-scm.org/D8032
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Dec 2019 14:03:12 -0800] rev 44394
copy: rewrite walkpat() to depend less on dirstate
I want to add a `hg cp/mv -r <rev>` option to mark files as
copied/moved in an existing commit (amending that commit). The code
needs to not depend on the dirstate for that.
Differential Revision: https://phab.mercurial-scm.org/D8031