Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 09 Mar 2020 17:26:30 +0100] rev 44486
cext: drop the WITH_RUST block
These were used by the `direct-ffi` mode that just got dropped.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 09 Mar 2020 17:16:44 +0100] rev 44485
setup: use printf instead of print
Yuya Nishihara pointed `printf` to me, so I will respect the cargo cult.
Martin von Zweigbergk <martinvonz@google.com> [Mon, 09 Mar 2020 11:18:33 -0700] rev 44484
git: don't fail import when pygit2 is not install
`test-duplicateoptions.py` was failing on py2 for be because I didn't
have pygit2 installed. It failed because we depend on pygit2 at import
time. This patch makes it so we successfully load the git extension
even if pygit2 doesn't exist -- we just won't be able to use it in
that case.
Differential Revision: https://phab.mercurial-scm.org/D8268
Martin von Zweigbergk <martinvonz@google.com> [Mon, 09 Mar 2020 12:53:21 -0700] rev 44483
hghave: add a check for pygit2
This will make it easy to use availability of pygit2 as in conditions
such as `#if pygit2` and `(pygit2 !)`. It also makes it a little
clearer why the test case skipped (when that happens).
Differential Revision: https://phab.mercurial-scm.org/D8267
Augie Fackler <raf@durin42.com> [Sat, 07 Mar 2020 18:00:53 -0500] rev 44482
localrepo: add git extension to autoextensions list
Differential Revision: https://phab.mercurial-scm.org/D8266
Augie Fackler <raf@durin42.com> [Sat, 07 Mar 2020 17:44:55 -0500] rev 44481
gitlog: implement __iter__ on changelog
This allows `hg phase --force --draft -r .` to work, for example.
Differential Revision: https://phab.mercurial-scm.org/D8264
Augie Fackler <raf@durin42.com> [Sat, 07 Mar 2020 17:42:40 -0500] rev 44480
gitlog: fix embarassing bug that prevented log from showing correct parents
We had the correct parents in the database, but the changelog was
always returning p1 for all parents. Oops.
Differential Revision: https://phab.mercurial-scm.org/D8263
Augie Fackler <raf@durin42.com> [Sat, 07 Mar 2020 16:51:21 -0500] rev 44479
git: add readfast() method to manifest
Mysteriously, on a different system a handful of things don't work
without this, including log. This is especially odd to be because log
works in the test. In any event, it's legal for readfast() to just
return read(), so that's what we do.
Differential Revision: https://phab.mercurial-scm.org/D8262
Martin von Zweigbergk <martinvonz@google.com> [Fri, 06 Mar 2020 14:14:05 -0800] rev 44478
git: make {shortest()} return shortest *unique* prefix
It used to return the prefix of the specified length as long as the
full node was unique (i.e. always).
Differential Revision: https://phab.mercurial-scm.org/D8256
Augie Fackler <augie@google.com> [Tue, 11 Feb 2020 00:44:59 -0500] rev 44477
git: skeleton of a new extension to _directly_ operate on git repos
This is based in part of work I did years ago in hgit, but it's mostly
new code since I'm using pygit2 instead of dulwich and the hg storage
interfaces have improved. Some cleanup of old hgit code by Pulkit,
which I greatly appreciate.
test-git-interop.t does not cover a whole lot of cases, but it
passes. It includes status, diff, making a new commit, and `hg annotate`
working on the git repository.
This is _not_ (yet) production quality code: this is an
experiment. Known technical debt lurking in this implementation:
* Writing bookmarks just totally ignores transactions.
* The way progress is threaded down into the gitstore is awful.
* Ideally we'd find a way to incrementally reindex DAGs. I'm not sure
how to do that efficiently, so we might need a "known only fast-forwards"
mode on the DAG indexer for use on `hg commit` and friends.
* We don't even _try_ to do anything reasonable for `hg pull` or `hg push`.
* Mercurial need an interface for the changelog type.
Tests currently require git 2.24 as far as I'm aware: `git status` has
some changed output that I didn't try and handle in a compatible way.
This patch has produced some interesting cleanups, most recently on
the manifest type. I expect continuing down this road will produce
other meritorious cleanups throughout our code.
Differential Revision: https://phab.mercurial-scm.org/D6734
Raphaël Gomès <rgomes@octobus.net> [Fri, 06 Mar 2020 10:38:37 +0100] rev 44476
hg-core: add a compilation error if trying to compile outside of Linux
For now, we can only provide support for Linux in `hg-core`, so we have to be
explicit about it in case anyone wonders why their Dirstate is suddenly broken,
or why the crate does not compile (on Windows for example).
Differential Revision: https://phab.mercurial-scm.org/D8246
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 10 Mar 2020 18:54:44 +0100] rev 44475
gzip: use the stdlib version with python 3 (issue6284)
It turned out that the stdlib gained the feature we missed in python 3.1. We can
now use it directly.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 10 Mar 2020 18:53:19 +0100] rev 44474
gzip: indent the custom Gzip code
We need a new conditional in the next changesets (Adding 3.8 support). We do the
large code move beforehand for clarity.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 10 Mar 2020 18:57:49 +0100] rev 44473
gzip: rename the argument to `mtime` to match upstream python
Python gained the feature we missed in 3.1. The argument name is `mtime`. We
align our version for consistency.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 10 Mar 2020 16:49:38 +0100] rev 44472
heptapod-ci: run the test from outside the test directory
This will help detecting case where this is broken.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 10 Mar 2020 16:47:02 +0100] rev 44471
run-tests: fix conditional when tests are run outside of `tests`
The logic to find `hghave` was using `__file__` but… non absolute path in
`__file__` gets wrong as soon as we change directory (thanks python… you are
being helpful). The rest of the `run-tests.py` code already deal with this
fine. We simply reuse the `RUNTESTDIR` variable to fix it.
Martin von Zweigbergk <martinvonz@google.com> [Mon, 09 Mar 2020 10:18:40 -0700] rev 44470
merge with stable
Manuel Jacob <me@manueljacob.de> [Mon, 09 Mar 2020 05:19:02 +0100] rev 44469
tests: use native string type for parsed hghave log lines
Before this change, on Python 2, the parsed messages were decoded to unicode,
causing an implicit conversion from unicode to str later.
Manuel Jacob <me@manueljacob.de> [Fri, 06 Mar 2020 10:27:38 +0100] rev 44468
tests: avoid implicit bytes -> unicode -> bytes roundtrip on Python 2
Before the change, there were two implicit conversions:
* The format string was converted to unicode because the substituted values were
unicode.
* When printing the message in log(), the string was converted from unicode to
str.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 08 Mar 2020 16:40:39 +0100] rev 44467
cext: make HgRevlogIndex_GetParents private again
The rust's direct-ffi code need to access this function. Now that it
`direct-ffi` is no more. We can make this function `static` again.
This change was suggested by `Yuya Nishihara`.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 06 Mar 2020 16:49:46 +0100] rev 44466
setup-rust: remove the legacy 'direct-ffi' variant
This variant have been abandoned for a while. Keeping it around just get people
confused.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 18 Feb 2020 18:32:31 +0100] rev 44465
hghave: add a `rust` keyword to detect the use of compiled rust code
The content of some on disk cache can varies when using rust (because it is
faster to do so in the rust variant). So we need to be able to detect this case
for some test.
Differential Revision: https://phab.mercurial-scm.org/D8162
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 28 Feb 2020 14:34:37 +0100] rev 44464
nodemap: check that a simple lookup works fine
I realised the code was not exercised much.
Differential Revision: https://phab.mercurial-scm.org/D8180
Raphaël Gomès <rgomes@octobus.net> [Fri, 06 Mar 2020 12:44:51 +0100] rev 44463
debuginstall: print if Rust extensions are installed
This should make it easier to use the Rust extensions.
Another patch on will be exposing a version and more useful information, but
it can only be done on top of this very patch, since it is targeting the stable
branch and the API has already changed on the default branch.
Differential Revision: https://phab.mercurial-scm.org/D8248
Augie Fackler <augie@google.com> [Fri, 06 Mar 2020 13:54:35 -0500] rev 44462
nodemap: fix missing r-prefix on regular expression
Looking at this regular expression, it's pretty obvious from reading
it that it wanted to match literal ., but since the r was missing on
the pattern it was matching any character. I guess we're just lucky
nothing bad happened as a result. This was automatically fixed by
pyupgrade, but I split it out into its own change because it seemed
important.
Differential Revision: https://phab.mercurial-scm.org/D8254
Manuel Jacob <me@manueljacob.de> [Fri, 06 Mar 2020 23:04:58 +0100] rev 44461
tests: use pyflakes module instead of pyflakes executable
This results in that the pyflakes version specific to the configured Python
version is used.
This way, both the Python 2-specific and the Python 3-specific pyflakes are run
by the test suite (depending on the configured Python version).
For downstream projects which are using Mercurial’s test infrastructure and are
not yet ported to Python 3 (e.g. hg-git) it ensures that the correct pyflakes
version is run even when the system’s default pyflakes is the Python 3-specific
one.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 03 Mar 2020 15:56:00 +0100] rev 44460
copies-tests: add a case where with merge with an overwritten files
This is similar to the BF/FB case, but in this case, the other branch updated
the file. So an actual merge happens and the two "independant" file history has
to be merged.
Differential Revision: https://phab.mercurial-scm.org/D8242
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 03 Mar 2020 15:46:28 +0100] rev 44459
copies-tests: add a case where a file is deleted/added but with a merge
This is a case similar to DB/BD, but in this case the other branch updated the
file. So an actual merge happens and the two "independant" file history has to
be merged.
Differential Revision: https://phab.mercurial-scm.org/D8241
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 03 Mar 2020 12:35:24 +0100] rev 44458
copies-tests: add a test with a rename overwriting another file
This is a variation of the "BD" case, but this time, the file is not "new", it
is overwritten by another file being renamed.
Differential Revision: https://phab.mercurial-scm.org/D8240
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 29 Feb 2020 19:50:05 +0100] rev 44457
copies-tests: add a `h` to the root commit (for chain merge tests)
This will be useful for incoming new test cases. We need a new file to rename
around.
Differential Revision: https://phab.mercurial-scm.org/D8239
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 07 Mar 2020 00:03:41 +0100] rev 44456
copies-tests: remove the final summary
The more we add tests, the less useful it is. So after discussion with Martin,
we decided to drop it.
Differential Revision: https://phab.mercurial-scm.org/D8257
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 03 Mar 2020 13:18:31 +0100] rev 44455
copies-tests: clarify the description of the EA/AE cases
The previous description of the merge was just wrong.
(It seems the result a non-updated copy-paste)
Differential Revision: https://phab.mercurial-scm.org/D8238
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 03 Mar 2020 09:27:31 +0100] rev 44454
copies-tests: update the analysis of the BD/DB cases
After thinking more about it, the current change in output between the two
merges is not due to an ambiguity, it is introduce by a bug in merge/commit
that record a wrong file history.
Fixing the bug should fix the output. In the meantime, we have a wrong behavior.
In practice the bug is not in the merge code (who does the right things), but in
the commit code (who get confused when recording the new file revision).
Differential Revision: https://phab.mercurial-scm.org/D8237
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 06 Mar 2020 11:02:02 +0100] rev 44453
copies-tests: swap two branch description
They were swapped and now match their intended block.
Differential Revision: https://phab.mercurial-scm.org/D8247
Augie Fackler <augie@google.com> [Fri, 06 Mar 2020 13:27:41 -0500] rev 44452
cleanup: run pyupgrade on our source tree to clean up varying things
Built with:
hg files 'set:**.py - mercurial/thirdparty/** - "contrib/python-zstandard/**" - hgext/fsmonitor/pywatchman/**' | xargs pyupgrade --keep-percent-format --keep-extraneous-parens
and then blackened. pyupgrade comes from
https://github.com/asottile/pyupgrade with a patch to let me preserve
extraneous parens (which we use for marking strings that shouldn't be
translated), and lets us clean up a bunch of idioms that have cruftily
accumulated over the years.
# skip-blame no-op automated code cleanups
Differential Revision: https://phab.mercurial-scm.org/D8255
Manuel Jacob <me@manueljacob.de> [Mon, 09 Mar 2020 01:11:59 +0100] rev 44451
tests: fix isinstance test of wrong variable
3086a8627b2970cd7fbf49bc69413c08c68d5514 changed self._case to be a list, but
it was forgotten to adjust this line.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 06 Mar 2020 23:27:28 +0100] rev 44450
discovery: avoid wrong detection of multiple branch heads (issue6256)
This fix the code using obsolescence markers to remove "to be obsoleted" heads
during the detection of new head creation from push. The code turned out to not
use the branch information at all. This lead changeset from different branch to
be detected as new head on unrelated branch.
The code fix is actually quite simple. New tests have been added to covers
these cases.
Differential Revision: https://phab.mercurial-scm.org/D8259
Manuel Jacob <me@manueljacob.de> [Fri, 06 Mar 2020 10:52:44 +0100] rev 44449
tests: avoid implicit conversion of str to unicode
On Python 2, str.encode('utf-8') implicitly converts the string to unicode and
then back to str.
Using _sys2bytes() ensures that opt is only encoded on Python 3, where opt is
unicode.
Although contrived, before this change, a UnicodeDecodeError could be triggered
on Python 2 when passing non-ascii values to --extra-config-opt.
Manuel Jacob <me@manueljacob.de> [Fri, 06 Mar 2020 09:50:57 +0100] rev 44448
tests: rename _bytespath() to _sys2bytes() and _strpath() to _sys2str()
The names were not general enough because e.g. _strpath() was used for
converting IP addresses.
Manuel Jacob <me@manueljacob.de> [Thu, 05 Mar 2020 18:19:21 +0100] rev 44447
tests: avoid implicit conversion of str to unicode
On Python 2, str.encode('ascii') implicitly converts the string to unicode and
then back to str.
Since the converted value is a path, _bytespath can be used instead.
Manuel Jacob <me@manueljacob.de> [Thu, 05 Mar 2020 18:10:19 +0100] rev 44446
tests: avoid implicit conversion of str to unicode
On Python 2, str.encode('ascii') implicitly converts the string to unicode and
then back to str.
Since the point of this expression is to convert a bool to a str, the '%r'
conversion specifier can be used instead in the format string.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 18 Feb 2020 19:11:13 +0100] rev 44445
nodemap: warm the persistent nodemap on disk with debugupdatecache
When appropriate, the nodemap cache file will be created.
Differential Revision: https://phab.mercurial-scm.org/D8173
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 29 Feb 2020 19:31:33 +0100] rev 44444
copies-tests: update to null after setup for output stability
This avoid having '@' moving around in graph output when the graph evolves.
after this change, graph evolution is still noisy, but less.
Differential Revision: https://phab.mercurial-scm.org/D8236
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 03 Mar 2020 08:55:27 +0100] rev 44443
copies-tests: remove extra log call at the end of the chain-merge test file
We do not actually need theses as the graph is displayed earlier anyway. I
think they are the remain of me trying to understand that case better.
Differential Revision: https://phab.mercurial-scm.org/D8235
Martin von Zweigbergk <martinvonz@google.com> [Thu, 05 Mar 2020 08:37:08 -0800] rev 44442
commit: print debug message when clearing dirstate and wdir clean
This case is a little weird, so let's have a debug message.
Differential Revision: https://phab.mercurial-scm.org/D8231
Martin von Zweigbergk <martinvonz@google.com> [Thu, 05 Mar 2020 10:46:31 -0800] rev 44441
merge with stable
Augie Fackler <augie@google.com> [Thu, 05 Mar 2020 10:52:51 -0500] rev 44440
merge with stable
Augie Fackler <augie@google.com> [Wed, 04 Mar 2020 14:21:23 -0500] rev 44439
commands: switch one call of check_at_most_one_arg to strings
This opts hasn't been through the byteskwargs mulcher, so we can just use
strings here instead of bytes. Fixes the test changes from D8204 on Python 3,
which was the only place this was a problem.
Differential Revision: https://phab.mercurial-scm.org/D8222
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Feb 2020 11:32:27 -0800] rev 44438
cleanup: remove redundant clearing of mergestate in rebase and shelve
`repo.commit()` now clears the merge state even if it ends up not
creating a commit because there were no changes to commit.
Differential Revision: https://phab.mercurial-scm.org/D8197
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Feb 2020 11:32:02 -0800] rev 44437
commit: clear resolved mergestate even if working copy is clean
If the mergestate has resolved conflicts and a commit is successfully
created (either because there are changes in the working copy or
because ui.allowemptycommit=yes), we will also clear the merge
state. However, if the working copy is clean (and
ui.allowemptycommit=no), we leave the mergestate there. The user may
notice it in `hg resolve -l` output (but not in `hg status -v`
output). It's not clear how the user should clear it, but probably via
`hg co -C .`. It's also quite likely that they won't even notice it
and it will get cleared by a later `hg commit` (of unrelated
changes).
This patch makes it so that `hg commit` also clears resolved merge
conflicts even if the command doesn't end up writing a commit because
the working copy was empty. That's probably a little weird (commands
that abort should generally avoid changing the repo), but it still
seems mostly harmless, and it reduces the risk of more bugs like
https://bz.mercurial-scm.org/show_bug.cgi?id=5494. I just ran into a
version of that bug in the Evolve extension and that's what triggered
this series.
Differential Revision: https://phab.mercurial-scm.org/D8196
Matt Harbison <matt_harbison@yahoo.com> [Wed, 04 Mar 2020 00:45:54 -0500] rev 44436
phabricator: avoid a stacktrace when command arguments are missing
Previously, the TypeError wasn't properly converted to a SignatureError when
improper arguments were supplied to the inner function, because the stack depth
is 2 inside the vcrcommand decorator. The `__name__` and `__doc__` attributes
need to be reassigned to the new wrapper so that the help summary is available.
Differential Revision: https://phab.mercurial-scm.org/D8209
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 15:51:19 -0800] rev 44435
mq: don't tell user to commit merge that we already committed
Differential Revision: https://phab.mercurial-scm.org/D8000
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 15:28:37 -0800] rev 44434
merge: make hg.merge() take a context instead of a node
Many callers already have a repo, so we might as well pass
that. `merge.update()` will look up the context object later. This
patch is part of making it so we pass around the context object all
the way down instead.
I also removed the `repo` argument since it can be retrieved from the
context.
Differential Revision: https://phab.mercurial-scm.org/D7999
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 17 Jan 2020 21:22:23 +0300] rev 44433
debugbackupbundle: introduce command to interact with strip backups
This vendors backups extension from hg-experimental.
Listing backups and having some utility to apply them is nice. I know we have
obsmarkers now, but this will help a lot of end users who still uses strip until
we get evolve out of experimental.
Differential Revision: https://phab.mercurial-scm.org/D7932
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 06 Mar 2020 00:28:09 +0100] rev 44432
test: cleanly skip test-remotefilelog-datapack.py on policy that breaks it
That tests requires the pure module to be available.
Differential Revision: https://phab.mercurial-scm.org/D8245
Raphaël Gomès <rgomes@octobus.net> [Thu, 05 Mar 2020 09:26:45 +0100] rev 44431
rust-format: cleanup ancestors.rs to make rustfmt happy
Differential Revision: https://phab.mercurial-scm.org/D8224
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 05 Mar 2020 15:47:22 +0100] rev 44430
heptapod-ci: use strict module policy
Without this, test can silently fallback to other compatible policy in some
cases.
Differential Revision: https://phab.mercurial-scm.org/D8234
Martin von Zweigbergk <martinvonz@google.com> [Thu, 05 Mar 2020 08:30:11 -0800] rev 44429
histedit: fix formatting after D8150
Differential Revision: https://phab.mercurial-scm.org/D8230
Raphaël Gomès <rgomes@octobus.net> [Thu, 05 Mar 2020 17:17:02 +0100] rev 44428
rust-format: make rustfmt happy
Differential Revision: https://phab.mercurial-scm.org/D8228
Matt Harbison <matt_harbison@yahoo.com> [Thu, 20 Feb 2020 10:56:40 -0500] rev 44427
phabricator: also check parent fctx for binary where it is checked for UTF-8
I don't know that this is necessary, but it seems obvious from the code checking
both the current and parent file for UTF-8 content that this was the intent.
Differential Revision: https://phab.mercurial-scm.org/D8221
Matt Harbison <matt_harbison@yahoo.com> [Thu, 20 Feb 2020 10:46:43 -0500] rev 44426
phabricator: don't infer the old `fctx` in `notutf8()`
This is used along with `fctx.isbinary()` to gate `addoldbinary()`, so it seems
like a good idea to provide the caller similar control over the current and
parent filecontext. Unlike `addoldbinary()`, it doesn't need both previous and
current contexts at the same time, so make the caller responsible for testing
both cases, as appropriate. I haven't worked out all of the problems around
marking files as binary for move/remove/copy, but this will definitely help with
`--no-stack` too.
It also turns out to have been doing too much- in the remove case, it tested not
just the removed file in the parent context (which is what gets passed in that
case), but also in the parent of the parent context (which should be
irrelevant). The previous code also required the `fctx.parents()` check to work
in the add (but without rename) case. Now the add and remove cases test only
what they need to. But now that it is written this way, the fact that only the
current `fctx` is checked to be binary in the case of modification or being
renamed seems wrong.
Differential Revision: https://phab.mercurial-scm.org/D8220
Matt Harbison <matt_harbison@yahoo.com> [Thu, 20 Feb 2020 12:42:07 -0500] rev 44425
phabricator: rename a variable to clarify that it is the parent filecontext
Differential Revision: https://phab.mercurial-scm.org/D8219
Matt Harbison <matt_harbison@yahoo.com> [Wed, 19 Feb 2020 13:33:58 -0500] rev 44424
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 44423
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 44422
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 44421
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 44420
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 44419
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 44418
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 44417
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 44416
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
Augie Fackler <raf@durin42.com> [Wed, 04 Mar 2020 11:51:13 -0500] rev 44415
Added signature for changeset 6d121acbb82e
Augie Fackler <raf@durin42.com> [Wed, 04 Mar 2020 11:51:12 -0500] rev 44414
Added tag 5.3.1 for changeset 6d121acbb82e
Joerg Sonnenberger <joerg@bec.de> [Sat, 07 Sep 2019 14:50:39 +0200] rev 44413
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 44412
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 44411
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 44410
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 44409
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 44408
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 44407
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 44406
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 44405
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
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 19 Feb 2020 13:39:00 +0530] rev 44404
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 28 Feb 2020 11:22:47 +0100] rev 44403
remotefilelog-test: glob some flaky output line
This is similar to ee0959e7d435. The affected line is flaky underload, yet the
final result is correct. The command involves background pre-check of output,
these are not stable probably because they run in parallel in multiple process.
If it become useful to start testing precise internal details of the, they will
have to be tested in a more appropriate framework than `.t` tests.
Differential Revision: https://phab.mercurial-scm.org/D8179
Steve Fink <sfink@mozilla.com> [Tue, 25 Feb 2020 13:23:37 -0800] rev 44402
histedit: py3 fixes for curses mode
Differential Revision: https://phab.mercurial-scm.org/D8150
Manuel Jacob <me@manueljacob.de> [Sun, 01 Mar 2020 19:39:23 +0100] rev 44401
branch: make --force work even when specifying revs
The `hg branch` command accepts a `--force` parameter that allows to
"set branch name even if it shadows an existing branch". However, before this
patch, that didn’t work when specifying revs with `-r`.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 26 Feb 2020 10:48:56 -0800] rev 44400
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 44399
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 44398
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 44397
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 44396
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 44395
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 44394
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 44393
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 44392
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 44391
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 44390
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 44389
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 44388
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 44387
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 44386
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 44385
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 44384
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 44383
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 44382
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 44381
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 44380
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 44379
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 00:20:47 -0500] rev 44378
setup: exclude the __index__ module from itself when generating
This module is generated on Windows to hold all of the extension names and the
help summaries, so that they are discoverable inside the py2exe zipfile. The
problem is this file is generated by dumping the disabled list, and that list
comes from walking the filesystem. So once an install from source into a
virtualenv created this module, then next build from source from that virtualenv
would also see __index__.py in the filesystem, and include it. Clearly that's
wrong because this isn't a real extension, so just filter it from the list when
generating it.
The Mercurial installer was unaffected by this, but the TortoiseHg package was.
In the final package, `hg help -v extensions` and the panel of extensions both
showed it.
Differential Revision: https://phab.mercurial-scm.org/D8142
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Feb 2020 16:33:10 -0500] rev 44377
tests: stabilize test-amend.t on Windows
If $TESTTMP isn't quoted in this context, it ends up like
`C:Temphgtests.pikkoxchild1test-amend.t-obsstore-off`.
Differential Revision: https://phab.mercurial-scm.org/D8144
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Feb 2020 17:43:34 -0500] rev 44376
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 44375
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 44374
merge with stable
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Feb 2020 13:28:49 +0900] rev 44373
py3: fix EOL detection in commandserver.channeledinput
This breaks TortoiseHg's email preview which sends b'\n' while readline
request is issued and the loop never ends. Spotted by Matt Harbison.
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Thu, 13 Feb 2020 22:51:17 -0500] rev 44372
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 44371
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 44370
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 44369
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 44368
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 44367
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 44366
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 44365
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 44364
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 44363
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 44362
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 44361
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 44360
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
Martin von Zweigbergk <martinvonz@google.com> [Thu, 13 Feb 2020 10:12:12 -0800] rev 44359
merge with stable
Yuya Nishihara <yuya@tcha.org> [Sat, 01 Feb 2020 12:57:32 +0900] rev 44358
pathutil: resurrect comment about path auditing order
It was removed at 51c86c6167c1, but expensive symlink traversal isn't the
only reason we should walk path components from the root.
Raphaël Gomès <rgomes@octobus.net> [Wed, 16 Oct 2019 14:12:48 +0200] rev 44357
rust-dirstatemap: remove additional lookup in dirstate.matches
We use the same trick as the Python implementation
Differential Revision: https://phab.mercurial-scm.org/D7119
Georges Racinet <georges.racinet@octobus.net> [Tue, 31 Dec 2019 12:43:57 +0100] rev 44356
rust-nodemap: insert method
In this implementation, we are in direct competition
with the C version: this Rust version will have a clear
startup advantage because it will read the data from disk,
but the insertion happens all in memory for both.
Differential Revision: https://phab.mercurial-scm.org/D7795
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Wed, 22 Jan 2020 14:21:34 -0500] rev 44355
recover: don't verify by default
The reason is:
- it's not that hard to trigger interrupted transactions: just run out
of disk space
- it takes forever to verify on large repos. Before --no-verify, I
told people to C-c hg recover when the progress bar showed up. Now I
tell them to pass --no-verify.
- I don't remember a single case where the verification step was
useful
This is technically a change of behavior. Perhaps this would be better
suited for tweakdefaults?
Differential Revision: https://phab.mercurial-scm.org/D7972
Augie Fackler <augie@google.com> [Tue, 11 Feb 2020 00:08:28 -0500] rev 44354
context: use manifest.find() instead of two separate calls
I noticed this while debugging an extension that's implementing the manifest
interface. Always nice to save a function call.
Differential Revision: https://phab.mercurial-scm.org/D8109
Raphaël Gomès <rgomes@octobus.net> [Thu, 16 Jan 2020 23:06:01 +0100] rev 44353
rust-matchers: implement `visit_children_set` for `FileMatcher`
As per the removed inline comment, this will become useful in a future patch
in this series as the `IncludeMatcher` is introduced.
Differential Revision: https://phab.mercurial-scm.org/D7914
Augie Fackler <augie@google.com> [Wed, 05 Feb 2020 17:13:51 -0500] rev 44352
manifest: move matches method to be outside the interface
In order to adequately smoke out any legacy consumers of the method, we rename
it to _matches so it's clear that it's class-private. To my amazement, all
consumers of this method really only wanted matching filenames, not a full
filtered manifest.
Differential Revision: https://phab.mercurial-scm.org/D8085
Augie Fackler <augie@google.com> [Mon, 10 Feb 2020 21:02:22 -0500] rev 44351
tags: use modern // operator for division
Fixes a test on Python 3.
# skip-blame only correcting a division operator, not a substantive change
Differential Revision: https://phab.mercurial-scm.org/D8108
Augie Fackler <augie@google.com> [Mon, 10 Feb 2020 20:47:19 -0500] rev 44350
tags: fix some type confusion exposed in python 3
# skip-blame just b-prefix and %-format cleanup, no meaningful change
Differential Revision: https://phab.mercurial-scm.org/D8107
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 17:20:12 -0800] rev 44349
rebase: remove some now-unused parent arguments
Differential Revision: https://phab.mercurial-scm.org/D7829
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 21:40:01 -0800] rev 44348
rebase: remove some redundant setting of dirstate parents
Since we're now setting the dirstate parents to its correct values
from the beginning (right after `merge.update()`), we usually don't
need to set them again before committing. The only case we need to
care about is when committing collapsed commits. So we can remove the
`setparents()` calls just before committing and add one only for the
collapse case.
Differential Revision: https://phab.mercurial-scm.org/D7828
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 14:22:20 -0800] rev 44347
rebase: don't use rebased node as dirstate p2 (BC)
When rebasing a node, we currently use the rebased node as p2 in the
dirstate until just before we commit it (we then change to the desired
parents). This p2 is visible to the user when the rebase gets
interrupted because of merge conflicts. That can be useful to the user
as a reminder of which commit is currently being rebased, but I
believe it's incorrect for a few reasons:
* I think the dirstate parents should be the ones that will be set
when the commit is created.
* I think having two parents means that you're merging those two
commits, but when rebasing, you're generally grafting, not merging.
* When rebasing a merge commit, we should use the two desired parents
as dirstate parents (and we clearly can't have the rebased node as
a third dirstate parent).
* `hg graft` (and `hg update --merge`) sets only one parent and `hg
rebase` should be consistent with that.
I realize that this is a somewhat large user-visible change, but I
think it's worth it because it will simplify things quite a bit.
Differential Revision: https://phab.mercurial-scm.org/D7827
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 14:17:56 -0800] rev 44346
rebase: stop relying on having two parents to resume rebase
I'm about to make it so we don't have two parents when a rebase is
interrupted (unless we're just rebasing on a merge commit). The code
for detecting if we're resuming a rebase relied on having two parents,
so this patch rewrites that to instead set a boolean when we resume.
Note that `self.resume` in the new condition implies `not
self.inmemory` (rebase cannot be resumed in memory), so that's why
that part can be omitted.
Differential Revision: https://phab.mercurial-scm.org/D7826
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Jan 2020 21:49:50 -0800] rev 44345
graphlog: use '%' for other context in merge conflict
This lets the user more easily find the commit that is involved in the
conflict, such as the source of `hg update -m` or the commit being
grafted by `hg graft`.
Differential Revision: https://phab.mercurial-scm.org/D8043
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 14:42:54 -0800] rev 44344
tests: add `hg log -G` output when there are merge conflicts
The next commit will change the behavior for these. I've used slightly
different commands in the different tests to match the surrounding
style.
Differential Revision: https://phab.mercurial-scm.org/D8042
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 11:30:35 -0800] rev 44343
revset: add a revset for parents in merge state
This may be particularly useful soon, when I'm going to change how `hg
rebase` sets its parents during conflict resolution.
Differential Revision: https://phab.mercurial-scm.org/D8041
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 17:46:10 -0800] rev 44342
tests: add test of rebase with conflict in merge commit
It doesn't seem like we had any tests of this. I think it's pretty
weird that the two parents we're merging are not the working copy
parents during the conflict resolution.
Differential Revision: https://phab.mercurial-scm.org/D7824
Martin von Zweigbergk <martinvonz@google.com> [Thu, 16 Jan 2020 00:03:19 -0800] rev 44341
rebase: always be graft-like, not merge-like, also for merges
Rebase works by updating to a commit and then grafting changes on
top. However, before this patch, it would actually merge in changes
instead of grafting them in in some cases. That is, it would use the
common ancestor as base instead of using one of the parents. That
seems wrong to me, so I'm changing it so `defineparents()` always
returns a value for `base`.
This fixes the bad behavior in test-rebase-newancestor.t, which was
introduced in 65f215ea3e8e (tests: add test for rebasing merges with
ancestors of the rebase destination, 2014-11-30).
The difference in test-rebase-dest.t is because the files in the tip
revision were A, D, E, F before this patch and A, D, F, G after it. I
think both files should ideally be there.
Differential Revision: https://phab.mercurial-scm.org/D7907
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:51:01 +0100] rev 44340
nodemap: update the index with the newly written data (when appropriate)
If we are to use mmap to read the nodemap data, and if the python code is
responsible for the IO, we need to refresh the mmap after each write and provide
it back to the index.
We start this dance without the mmap first.
Differential Revision: https://phab.mercurial-scm.org/D7893
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:50:52 +0100] rev 44339
nodemap: never read more than the expected data amount
Since we are tracking this number we can use it to detect corrupted rawdata file
and to only read the correct amount of data when possible.
Differential Revision: https://phab.mercurial-scm.org/D7892
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:50:43 +0100] rev 44338
nodemap: write new data from the expected current data length
If the amount of data in the file exceed the expect amount, we will overwrite
the extra data. This is a simple way to be safer.
Differential Revision: https://phab.mercurial-scm.org/D7891
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:50:33 +0100] rev 44337
nodemap: double check the source docket when doing incremental update
In theory, the index will have the information we expect it to have. However by
security, it seems safer to double check that the incremental data are generated
from the data currently on disk.
Differential Revision: https://phab.mercurial-scm.org/D7890
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:50:24 +0100] rev 44336
nodemap: track the total and unused amount of data in the rawdata file
We need to keep that information around:
* total data will allow transaction to start appending new information without
confusing other reader.
* unused data will allow to detect when we should regenerate new rawdata file.
Differential Revision: https://phab.mercurial-scm.org/D7889
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:50:14 +0100] rev 44335
nodemap: track the maximum revision tracked in the nodemap
We need a simple way to detect when the on disk data contains less revision
than the index we read from disk. The docket file is meant for this, we just had
to start tracking that data.
We should also try to detect strip operation, but we will deal with this in
later changesets. Right now we are focusing on defining the API for index
supporting persistent nodemap.
Differential Revision: https://phab.mercurial-scm.org/D7888
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:50:04 +0100] rev 44334
nodemap: add a flag to dump the details of the docket
We are about to add more information to the docket. We first introduce a way to
debug its content.
Differential Revision: https://phab.mercurial-scm.org/D7887
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:49:54 +0100] rev 44333
nodemap: introduce append-only incremental update of the persistent data
Rewriting the full nodemap for each transaction has a cost we would like to
avoid. We introduce a new way to write persistent nodemap data by adding new
information at the end for file. Any new and updated block as added at the end
of the file. The last block is the new root node.
With this method, some of the block already on disk get "dereferenced" and
become dead data. In later changesets, We'll start tracking the amount of dead
data to eventually re-generate a full nodemap.
Differential Revision: https://phab.mercurial-scm.org/D7886
Kyle Lippincott <spectral@google.com> [Thu, 20 Feb 2020 16:21:00 -0800] rev 44332
shelve: fix ordering of merge labels
Differential Revision: https://phab.mercurial-scm.org/D8140
Kyle Lippincott <spectral@google.com> [Thu, 20 Feb 2020 17:06:01 -0800] rev 44331
shelve: add test clearly demonstrating that the conflict labels are backwards
Differential Revision: https://phab.mercurial-scm.org/D8139
Matt Harbison <matt_harbison@yahoo.com> [Sun, 16 Feb 2020 17:05:18 -0500] rev 44330
import: don't ignore `--secret` when `--bypass` is specified
Differential Revision: https://phab.mercurial-scm.org/D8126
Matt Harbison <matt_harbison@yahoo.com> [Tue, 18 Feb 2020 13:46:10 -0500] rev 44329
phabricator: fix a phabsend crash when processing a renamed binary
This was a trivial fix, and some more tests are added to cover binary files.
Since the old filecontext is passed in, the old name is still available. But I
noticed some weirdness around what it marked as binary and not, and what is
viewable in Phabricator. Those things have been flagged, and will probably take
some digging.
Differential Revision: https://phab.mercurial-scm.org/D8133
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 13 Dec 2019 10:37:45 +0100] rev 44328
test: pin the number of CPU for issue4074 tests
On machine with an hundreds of CPUs, the "user" CPU time reported can be
inflated by the status steps. Since the test especially focus on the diff
computation, we restrict the number of CPU to avoid potential issues.
Differential Revision: https://phab.mercurial-scm.org/D8112
Raphaël Gomès <rgomes@octobus.net> [Wed, 12 Feb 2020 23:23:59 +0100] rev 44327
rust-dirstatemap: add `NonNormalEntries` class
This fix introduces the same encapsulation as the `copymap`. There is no easy
way of doing this any better for now.
`hg up -r null && time HGRCPATH= HGMODULEPOLICY=rust+c hg up tip` on Mozilla
Central, (not super recent, but it doesn't matter):
Before: 7:44,08 total
After: 1:03,23 total
Pretty brutal regression!
This is a graft on stable of cf1f8660e568
Differential Revision: https://phab.mercurial-scm.org/D8111
Raphaël Gomès <rgomes@octobus.net> [Thu, 30 Jan 2020 14:57:02 +0100] rev 44326
rust-dirstatemap: cache non normal and other parent set
Performance of `hg update` was significantly worse since the introduction of
the Rust `dirstatemap`. This regression was noticed by Valentin Gatien-Baron
when working on a large repository, as it goes unnoticed for smaller
repositories like Mercurial itself.
This fix introduces the same getter/setter mechanism at `hg-core` level as
for `set/get_dirs`.
While this technique is, as previously discussed, quite suboptimal, it fixes an
important enough problem. Refactoring `hg-core` to use the typestate
pattern could be a good approach to improving code quality in a future patch.
This is a graft of stable of 83b2b829c94e
Differential Revision: https://phab.mercurial-scm.org/D8110
Yuya Nishihara <yuya@tcha.org> [Tue, 11 Feb 2020 19:53:56 +0900] rev 44325
chgserver: spawn new process if schemes change
The schemes extension updates hg.schemes table. It's technically possible
for hg.repository() to look for e.g. ui.schemes instead of depending on
module-local table, but I don't think the change would make much sense
since [schemes] is usually specified in ~/.hgrc and thus it can be considered
static data.
Martin von Zweigbergk <martinvonz@google.com> [Mon, 10 Feb 2020 15:52:52 -0800] rev 44324
tests: accept new bzr message about switching branches
The new version apparently prints "Switched to branch at " instead of
"Switched to branch: ".
Differential Revision: https://phab.mercurial-scm.org/D8106
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:49:45 +0100] rev 44323
nodemap: keep track of the docket for loaded data
To perform incremental update of the on disk data, we need to keep tracks of
some aspect of that data.
Differential Revision: https://phab.mercurial-scm.org/D7885
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:49:35 +0100] rev 44322
nodemap: introduce an explicit class/object for the docket
We are about to add more information to this docket, having a clear location to
stock them in memory will help.
Differential Revision: https://phab.mercurial-scm.org/D7884
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:49:26 +0100] rev 44321
nodemap: keep track of the ondisk id of nodemap blocks
If we are to incrementally update the files, we need to keep some details about
the data we read.
Differential Revision: https://phab.mercurial-scm.org/D7883
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:49:16 +0100] rev 44320
nodemap: provide the on disk data to indexes who support it
Time to start defining the API and prepare the rust index support. We provide
a method to do so. We use a distinct method instead of passing them in the
constructor because we will need this method anyway later (to refresh the mmap
once we update the data on disk).
Differential Revision: https://phab.mercurial-scm.org/D7847
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:49:06 +0100] rev 44319
nodemap: all check that revision and nodes match in the nodemap
More check is always useful.
Differential Revision: https://phab.mercurial-scm.org/D7846
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:48:57 +0100] rev 44318
nodemap: add basic checking of the on disk nodemap content
The simplest check it so verify we have all the revision we needs, and nothing
more.
Differential Revision: https://phab.mercurial-scm.org/D7845
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:48:47 +0100] rev 44317
nodemap: code to parse the persistent binary nodemap data
We now have code to read back what we persisted. This will be put to use in
later changesets.
Differential Revision: https://phab.mercurial-scm.org/D7844
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:48:38 +0100] rev 44316
nodemap: move the iteratio inside the Block object
Having the iteration inside the serialization function does not help
readability. Now that we have a `Block` object, let us move that code there.
Differential Revision: https://phab.mercurial-scm.org/D7843
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:48:28 +0100] rev 44315
nodemap: use an explicit "Block" object in the reference implementation
This will help us to introduce some test around the data currently written on
disk.
Differential Revision: https://phab.mercurial-scm.org/D7842
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:48:19 +0100] rev 44314
nodemap: add a optional `nodemap_add_full` method on indexes
This method can be used to obtains persistent data for a full nodemap. The end
goal is for some index implementation to managed the nodemap serialization them
selves (eg: the rust implementation)
Differential Revision: https://phab.mercurial-scm.org/D7841
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:48:09 +0100] rev 44313
nodemap: add a (python) index class for persistent nodemap testing
Using the persistent nodemap require a compeling performance boost and an
existing implementation. The benefit of the persistent nodemap for pure python
code is unclear and we don't have a C implementation for it. Yet we would like
to actually start testing it in more details and define an API for using that
persistent nodemap.
We introduce a new `devel` config option to use an index class dedicated to
Nodemap Testing. This feature is "pure" only because having using a pure-python
index with the `cext` policy proved more difficult than I would like.
There is nothing going on in that class for now, but the coming changeset will
change that.
Differential Revision: https://phab.mercurial-scm.org/D7840
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:47:59 +0100] rev 44312
nodemap: delete older raw data file when creating a new ones
When we write new full files, it replace an older one with a different name. We
add the associated cleanup for the older file to be removed after the
transaction.
We delete all file matching the expected pattern to give use extra chance to
delete orphan files we might have failed to delete earlier.
Note: eventually we won't rewrite all data for each transaction. This is coming
in later changesets.
Differential Revision: https://phab.mercurial-scm.org/D7839
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:47:50 +0100] rev 44311
nodemap: use an intermediate "docket" file to carry small metadata
This intermediate file will make mmapping, transaction and content validation
easier. (Most of this usefulness will arrive gradually in later changeset). In
particular it will become very useful to append new data are the end of raw file
instead of rewriting on the file on each transaction.
See in code comments for details.
Differential Revision: https://phab.mercurial-scm.org/D7838
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:47:40 +0100] rev 44310
nodemap: only use persistent nodemap for non-inlined revlog
Revlog are inlined while they are small (to avoid having too many file to deal
with). The persistent nodemap will only provides a significant boost for large
enough revlog index. So it does not make sens to add an extra file to store
nodemap for small revlog.
We could consider inclining the nodemap data inside the revlog itself, but the
benefit is unclear so let it be an adventure for another time.
Differential Revision: https://phab.mercurial-scm.org/D7837
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:47:31 +0100] rev 44309
nodemap: add a function to read the data from disk
This changeset is small and mostly an excuse to introduce an API function
reading the data from disk.
Differential Revision: https://phab.mercurial-scm.org/D7836
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:47:21 +0100] rev 44308
nodemap: write nodemap data on disk
Let us start writing data on disk (so that we can read it from there later).
This series of changeset is going to focus first on having data on disk and
updating it.
Right now the data is written right next to the revlog data, in the store. We
might move it to cache (with proper cache validation mechanism) later, but for
now revlog have a storevfs instance and it is simpler to us it. The right
location for this data is not the focus of this series.
Differential Revision: https://phab.mercurial-scm.org/D7835
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:47:12 +0100] rev 44307
nodemap: have some python code writing a nodemap in persistent binary form
This python code aims to be as "simple" as possible. It is a reference
implementation of the data we are going to write on disk (and possibly,
later a way for pure python install to make sure the on disk data are up to
date).
It is not optimized for performance and rebuild the full data structure from
the index every time.
This is a stepping stone toward a persistent nodemap on disk.
Differential Revision: https://phab.mercurial-scm.org/D7834
Augie Fackler <augie@google.com> [Mon, 10 Feb 2020 17:31:05 -0500] rev 44306
cleanup: re-run black on the codebase
Looks like a few patches have landed without having been blackened. I
strongly suspect I should write a patch for baymax that blackens
things on the way in...
# skip-blame automatic formatting
Differential Revision: https://phab.mercurial-scm.org/D8104
Raphaël Gomès <rgomes@octobus.net> [Thu, 16 Jan 2020 13:34:04 +0100] rev 44305
rust-re2: add wrapper for calling Re2 from Rust
This assumes that Re2 is installed following Google's guide. I am not sure
how we want to integrate it in the project, but I think a follow-up patch would
be more appropriate for such work.
As it stands, *not* having Re2 installed results in a compilation error, which
is a problem as it breaks install compatibility. Hence, this is gated behind
a non-default `with-re2` compilation feature.
Differential Revision: https://phab.mercurial-scm.org/D7910
Raphaël Gomès <rgomes@octobus.net> [Thu, 16 Jan 2020 11:27:12 +0100] rev 44304
rust-filepatterns: add support for `include` and `subinclude` patterns
This prepares a future patch for `IncludeMatcher` on the road to bare
`hg status` support.
Differential Revision: https://phab.mercurial-scm.org/D7909
Raphaël Gomès <rgomes@octobus.net> [Thu, 16 Jan 2020 10:28:40 +0100] rev 44303
rust-filepatterns: improve API and robustness for pattern files parsing
Within the next few patches we will be using this new API.
Differential Revision: https://phab.mercurial-scm.org/D7908
Martin von Zweigbergk <martinvonz@google.com> [Mon, 10 Feb 2020 15:50:26 -0800] rev 44302
tests: add workaround for bzr bug
This started failing for me today. I guess my bzr was upgraded.
Differential Revision: https://phab.mercurial-scm.org/D8105
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 17:10:20 +0100] rev 44301
rust-utils: add util for canonical path
Differential Revision: https://phab.mercurial-scm.org/D7871
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 01 Feb 2020 09:14:36 +0100] rev 44300
test: simplify test-amend.t to avoid race condition
Insted on relying on sleep, we could simply have the editor do the file change.
This remove the reliance on "sleep" and avoid test failing on heavy load
machine.
To test this, I reverted the code change in 5558e3437872 and the test started
failing again.
This is a graft on stable of 141ceec06b55 which should have targeted for stable.
Differential Revision: https://phab.mercurial-scm.org/D8103
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 09 Feb 2020 01:34:37 +0100] rev 44299
remotefilelog-test: glob some flaky output line (issue6083)
The two following lines are flaky underload, yet the final result is correct.
The command involves background pre-check of output, these are not stable
probably because they run in parallel in multiple process.
I spent a couple of hours trying to understand the pattern and gave up. The
documented intend of these tests is safely guaranteed by checking the cache
content after the command.
If it become useful to start testing precise internal details of the, they will
have to be tested in a more appropriate framework than `.t` tests.
Differential Revision: https://phab.mercurial-scm.org/D8102
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 10:24:32 -0500] rev 44298
httpconnection: allow `httpsendfile` subclasses to suppress the progressbar
This will be neccessary for LFS, which manages the progressbar outside of the
file.
Differential Revision: https://phab.mercurial-scm.org/D7960
Raphaël Gomès <rgomes@octobus.net> [Mon, 10 Feb 2020 21:54:12 +0100] rev 44297
rust-dirstatemap: add `NonNormalEntries` class
This fix introduces the same encapsulation as the `copymap`. There is no easy
way of doing this any better for now.
`hg up -r null && time HGRCPATH= HGMODULEPOLICY=rust+c hg up tip` on Mozilla
Central, (not super recent, but it doesn't matter):
Before: 7:44,08 total
After: 1:03,23 total
Pretty brutal regression!
Differential Revision: https://phab.mercurial-scm.org/D8049
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 09 Feb 2020 16:18:26 -0500] rev 44296
help: when possible, indicate flags implied by tweakdefaults
Differential Revision: https://phab.mercurial-scm.org/D8101
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 09 Feb 2020 15:50:36 -0500] rev 44295
help: add a mechanism to change flags' help depending on config
It seems reasonable to have a similar mechanism for the rest of the
help, but no such thing is implemented.
The goal is to make the help of commands clearer in the presence of
significant default changes, like tweakdefaults or with company-wide
hgrcs. In these cases, a user looking at the help of a command doesn't
exactly know what his hgrc is doing.
Apply to this to the --git option of commands that display diffs, as
this option in particular causes confusion for some reason.
Differential Revision: https://phab.mercurial-scm.org/D8100
Matt Harbison <matt_harbison@yahoo.com> [Sat, 08 Feb 2020 23:39:55 -0500] rev 44294
lfs: use str for the open() mode when opening a blob for py3
The other fix for this was to leave the mode as bytes, and import
`pycompat.open()` like a bunch of other modules do. But I think it's confusing
to still use bytes at the python boundary, and obviously error prone. Grepping
for ` open\(.+, ['"][a-z]+['"]\)` and ` open\(.+, b['"][a-z]+['"]\)` outside of
`tests`, there are 51 and 87 uses respectively, so it's not like this is a rare
direct usage.
Differential Revision: https://phab.mercurial-scm.org/D8099
Raphaël Gomès <rgomes@octobus.net> [Thu, 30 Jan 2020 14:57:02 +0100] rev 44293
rust-dirstatemap: cache non normal and other parent set
Performance of `hg update` was significantly worse since the introduction of
the Rust `dirstatemap`. This regression was noticed by Valentin Gatien-Baron
when working on a large repository, as it goes unnoticed for smaller
repositories like Mercurial itself.
This fix introduces the same getter/setter mechanism at `hg-core` level as
for `set/get_dirs`.
While this technique is, as previously discussed, quite suboptimal, it fixes an
important enough problem. Refactoring `hg-core` to use the typestate
pattern could be a good approach to improving code quality in a future patch.
Differential Revision: https://phab.mercurial-scm.org/D8048
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Fri, 07 Feb 2020 16:01:32 -0500] rev 44292
tags: behave better if a tags cache entry is partially written
This is done by discarding any partial cache entry, instead of
filling the partial cache entry with 0xff before.
Differential Revision: https://phab.mercurial-scm.org/D8095
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Fri, 07 Feb 2020 15:55:26 -0500] rev 44291
tags: show how hg behaves if a tags cache entry is truncated
I'm seeing an error of this form in production on the order of once a
month. I'm not sure how it happens, but I suspect interrupting a pull
might result in half written cache entries.
Differential Revision: https://phab.mercurial-scm.org/D8094
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Fri, 07 Feb 2020 13:54:09 -0500] rev 44290
tags: add a debug command to display .hg/cache/hgtagsfnodes1
Differential Revision: https://phab.mercurial-scm.org/D8093
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sat, 08 Feb 2020 10:22:47 -0500] rev 44289
purge: add -i flag to delete ignored files instead of untracked files
It's convenient for deleting build artifacts. Using --all instead
would delete other things too.
Differential Revision: https://phab.mercurial-scm.org/D8096
Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Jan 2020 19:50:43 -0500] rev 44288
pyoxidizer: use `legacy_windows_stdio` on Windows
The C executable sets this too, otherwise no output shows up (when paging?).
There is also `legacy_windows_fs_encoding`, but I'm not setting that for now
because the C executable doesn't either.
Differential Revision: https://phab.mercurial-scm.org/D8053
Augie Fackler <augie@google.com> [Wed, 05 Feb 2020 17:12:39 -0500] rev 44287
merge: use manifestdict.walk() instead of manifestdict.matches()
As with other patches in this series, this avoids making a
potentially-expensive copy of a manifest.
Differential Revision: https://phab.mercurial-scm.org/D8084
Augie Fackler <augie@google.com> [Wed, 05 Feb 2020 16:58:50 -0500] rev 44286
manifest: rewrite filesnotin to not make superfluous manifest copies
This also skips using diff() when all we care about is the filenames. I'm
expecting the built in set logic to be plenty fast. For really large manifests
with a matcher in play this should copy substantially less data around.
Differential Revision: https://phab.mercurial-scm.org/D8082
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 08 Feb 2020 03:13:45 +0530] rev 44285
merge with stable
Augie Fackler <augie@google.com> [Thu, 06 Feb 2020 16:55:39 -0500] rev 44284
archival: use walk() instead of matches() on manifest
All we care about is the filepaths, so this avoids a pointless copy of the
manifest that we only used to extract matching filenames.
Differential Revision: https://phab.mercurial-scm.org/D8090
Raphaël Gomès <rgomes@octobus.net> [Fri, 24 Jan 2020 11:10:07 +0100] rev 44283
rust-dirs-multiset: improve temporary error message
While we wait on a future patch that could verify that the paths passed to
`DirsMultiset` have been audited, we still need to handle this error.
This patch makes it easier to bubble up and makes the error clearer.
Also, this patch introduces the `subslice_index` function that could be useful
for other - albeit niche - purposes.
Differential Revision: https://phab.mercurial-scm.org/D7921
Matt Harbison <matt_harbison@yahoo.com> [Wed, 22 Jan 2020 12:11:35 -0500] rev 44282
exchange: check the `ui.clonebundleprefers` form while processing (issue6257)
Otherwise the clone command will emit a long stacktrace if there is no `=`
character.
Differential Revision: https://phab.mercurial-scm.org/D7969
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 13 Dec 2019 16:49:05 +0100] rev 44281
copies: add a new test dedicated to testing chain of changeset with merge
The copies test we currently have usually focus on simple case that do not dive
too much into longer chains involving merges. This new test file focus on
extensive testing of these case to validate their behavior and make sure the
various copies algorithm have the same behavior.
And… actually these test are currently broken for the changeset centric
algorithm since 99ebde4fec99, but it went undetected because these case were not
tested.
Differential Revision: https://phab.mercurial-scm.org/D8078
Joerg Sonnenberger <joerg@bec.de> [Wed, 18 Sep 2019 06:07:09 +0200] rev 44280
hgext: initial version of fastexport extension
Differential Revision: https://phab.mercurial-scm.org/D7733
Julien Cristau <jcristau@mozilla.com> [Fri, 07 Feb 2020 15:55:21 +0100] rev 44279
hghave: cache the result of gethgversion
hghave --test-features calls it 90 times, each one calling hg --version
which takes a tenth of a second on my workstation, adding up to about
10s win on test-hghave.t.
Fixes https://bugs.debian.org/939756
Differential Revision: https://phab.mercurial-scm.org/D8092
Augie Fackler <augie@google.com> [Mon, 03 Feb 2020 11:56:02 -0500] rev 44278
resourceutil: blacken
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 14:11:43 -0800] rev 44277
clean: delete obsolete unlinking of .hg/graftstate
The responsibility for clearing it is now in
`cmdutil.clearunfinished()`, so we shouldn't have to unlink it in
`hg.clean()`.
Differential Revision: https://phab.mercurial-scm.org/D7992
Martin von Zweigbergk <martinvonz@google.com> [Tue, 04 Feb 2020 10:16:30 -0800] rev 44276
copies: avoid filtering by short-circuit dirstate-only copies earlier
The call to `y.ancestor(x)` triggered repo filtering, which we'd like
to avoid in the simple `hg status --copies` case.
Differential Revision: https://phab.mercurial-scm.org/D8071
Martin von Zweigbergk <martinvonz@google.com> [Tue, 04 Feb 2020 10:14:44 -0800] rev 44275
tests: add test showing that repo filter is calculated for `hg st --copies`
Differential Revision: https://phab.mercurial-scm.org/D8070
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 11:40:15 -0500] rev 44274
lfs: enable workers by default
With the stall issue seemingly fixed, there's no reason not to use workers. The
setting is left for now to keep the test output deterministic, and in case other
issues come up. If none do, this can be converted to a developer setting for
usage with the tests.
Differential Revision: https://phab.mercurial-scm.org/D7963
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 11:32:33 -0500] rev 44273
lfs: fix the stall and corruption issue when concurrently uploading blobs
We've avoided the issue up to this point by gating worker usage with an
experimental config. See 10e62d5efa73, and the thread linked there for some of
the initial diagnosis, but essentially some data was being read from the blob
before an error occurred and `keepalive` retried, but didn't rewind the file
pointer. So the leading data was lost from the blob on the server, and the
connection stalled, trying to send more data than available.
In trying to recreate this, I was unable to do so uploading from Windows to
CentOS 7. But it reproduced every time going from CentOS 7 to another CentOS 7
over https.
I found recent fixes in the FaceBook repo to address this[1][2]. The commit
message for the first is:
The KeepAlive HTTP implementation is bugged in it's retry logic, it supports
reading from a file pointer, but doesn't support rewinding of the seek cursor
when it performs a retry. So it can happen that an upload fails for whatever
reason and will then 'hang' on the retry event.
The sequence of events that get triggered are:
- Upload file A, goes OK. Keep-Alive caches connection.
- Upload file B, fails due to (for example) failing Keep-Alive, but LFS file
pointer has been consumed for the upload and fd has been closed.
- Retry for file B starts, sets the Content-Length properly to the expected
file size, but since file pointer has been consumed no data will be uploaded,
causing the server to wait for the uploaded data until either client or
server reaches a timeout, making it seem as our mercurial process hangs.
This is just a stop-gap measure to prevent this behavior from blocking Mercurial
(LFS has retry logic). A proper solutions need to be build on top of this
stop-gap measure: for upload from file pointers, we should support fseek() on
the interface. Since we expect to consume the whole file always anyways, this
should be safe. This way we can seek back to the beginning on a retry.
I ported those two patches, and it works. But I see that `url._sendfile()` does
a rewind on `httpsendfile` objects[3], so maybe it's better to keep this all in
one place and avoid a second seek. We may still want the first FaceBook patch
as extra protection for this problem in general. The other two uses of
`httpsendfile` are in the wire protocol to upload bundles, and to upload
largefiles. Neither of these appear to use a worker, and I'm not sure why
workers seem to trigger this, or if this could have happened without a worker.
Since `httpsendfile` already has a `close()` method, that is dropped. That
class also explicitly says there's no `__len__` attribute, so that is removed
too. The override for `read()` is necessary to avoid the progressbar usage per
file.
[1] https://github.com/facebookexperimental/eden/commit/c350d6536d90c044c837abdd3675185644481469
[2] https://github.com/facebookexperimental/eden/commit/77f0d3fd0415e81b63e317e457af9c55c46103ee
[3] https://www.mercurial-scm.org/repo/hg/file/5.2.2/mercurial/url.py#l176
Differential Revision: https://phab.mercurial-scm.org/D7962
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 10:34:15 -0500] rev 44272
lfs: add a method to the local blobstore to convert OIDs to file paths
This is less ugly than passing an open callback to the `httpsendfile`
constuctor.
Differential Revision: https://phab.mercurial-scm.org/D7961
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 14:47:38 -0800] rev 44271
merge: introduce a revert_to() for that use-case
In the same vein as the previous patch.
Differential Revision: https://phab.mercurial-scm.org/D7901
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 15:30:25 -0800] rev 44270
merge: introduce a clean_update() for that use-case
I find it hard to understand what value to pass for all the arguments
to `merge.update()`. I would like to introduce functions that are more
specific to each use-case. We already have `graft()`. This patch
introduces a `clean_update()` and uses it in some places to show that
it works.
Differential Revision: https://phab.mercurial-scm.org/D7902
Augie Fackler <augie@google.com> [Wed, 05 Feb 2020 16:16:15 -0500] rev 44269
manifest: fix _very_ subtle bug with exact matchers passed to walk()
Prior to this fix, manifestdict.walk() with an exact matcher would blindly
list the files in the matcher, even if they weren't in the manifest. This was
exposed by my next patch where I rewrite filesnotin() to use walk() instead of
matches().
Differential Revision: https://phab.mercurial-scm.org/D8081
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 17:08:45 +0100] rev 44268
rust-utils: add `Escaped` trait
This will be used as a general interface for displaying things to the user.
The upcoming `IncludeMatcher` will use it to store its patterns in a
user-displayable string.
Differential Revision: https://phab.mercurial-scm.org/D7870
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 17:04:32 +0100] rev 44267
rust-dirs-multiset: add `DirsChildrenMultiset`
In a future patch, this structure will be needed to store information needed by
the (also upcoming) `IgnoreMatcher`.
Differential Revision: https://phab.mercurial-scm.org/D7869
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 16:50:35 +0100] rev 44266
rust-hg-path: add useful methods to `HgPath`
This changeset introduces the use of the `pretty_assertions` crate for easier
to read test output.
Differential Revision: https://phab.mercurial-scm.org/D7867
Raphaël Gomès <rgomes@octobus.net> [Wed, 05 Feb 2020 17:05:37 +0100] rev 44265
rust-pathauditor: add Rust implementation of the `pathauditor`
It does not offer the same flexibility as the Python implementation, but
should check incoming paths just as well.
Differential Revision: https://phab.mercurial-scm.org/D7866
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 22 Jan 2020 03:17:06 +0530] rev 44264
py3: catch AttributeError too with ImportError
Looks like py3 raises AttributeError instead of ImportError. This is caught on
windows.
Differential Revision: https://phab.mercurial-scm.org/D7965
Augie Fackler <augie@google.com> [Wed, 05 Feb 2020 15:15:18 -0500] rev 44263
context: use manifest.walk() instead of manifest.match() to get file list
The former doesn't create a whole extra manifest in order to produce the
matching file list, which is all we actually cared about here. Sigh.
Differential Revision: https://phab.mercurial-scm.org/D8080
Augie Fackler <augie@google.com> [Wed, 05 Feb 2020 15:01:22 -0500] rev 44262
manifest: remove `.new()` from the interface
Nothing used it.
Differential Revision: https://phab.mercurial-scm.org/D8079
Kyle Lippincott <spectral@google.com> [Wed, 29 Jan 2020 13:39:50 -0800] rev 44261
chg: force-set LC_CTYPE on server start to actual value from the environment
Python 3.7+ will "coerce" the LC_CTYPE variable in many instances, and this can
cause issues with chg being able to start up. D7550 attempted to fix this, but a
combination of a misreading of the way that python3.7 does the coercion and an
untested state (LC_CTYPE being set to an invalid value) meant that this was
still not quite working.
This change will cause differences between chg and hg: hg will have the LC_CTYPE
environment variable coerced, while chg will not. This is unlikely to cause any
detectable behavior differences in what Mercurial itself outputs, but it does
have two known effects:
- When using hg, the coerced LC_CTYPE will be passed to subprocesses, even
non-python ones. Using chg will remove the coercion, and this will not
happen. This is arguably more correct behavior on chg's part.
- On macOS, if you set your region to Brazil but your language to English,
this isn't representable in locale strings, so macOS sets LC_CTYPE=UTF-8. If
this value is passed along when ssh'ing to a non-macOS machine, some
functions (such as locale.setlocale()) may raise an exception due to an
unsupported locale setting. This is most easily encountered when doing an
interactive commit/split/etc. when using ui.interface=curses.
Differential Revision: https://phab.mercurial-scm.org/D8039
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 03 Feb 2020 09:00:05 +0100] rev 44260
perf: fix list formatting in perfindex documentation
Differential Revision: https://phab.mercurial-scm.org/D8067
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 01 Feb 2020 09:14:36 +0100] rev 44259
test: simplify test-amend.t to avoid race condition
Insted on relying on sleep, we could simply have the editor do the file change.
This remove the reliance on "sleep" and avoid test failing on heavy load
machine.
To test this, I reverted the code change in 5558e3437872 and the test started
failing again.
Differential Revision: https://phab.mercurial-scm.org/D8065
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 13 Dec 2019 11:32:36 +0100] rev 44258
test: document test-copy-move-merge.t
Differential Revision: https://phab.mercurial-scm.org/D8077
Augie Fackler <augie@google.com> [Mon, 03 Feb 2020 22:16:36 -0500] rev 44257
manifest: remove optional default= argument on flags(path)
It had only one caller inside manifest.py, and treemanifest was
actually incorrectly implemented. treemanifest is still missing the
fastdelta() method from the interface (and so doesn't yet conform),
but this is at least progress.
Differential Revision: https://phab.mercurial-scm.org/D8069
Kyle Lippincott <spectral@google.com> [Thu, 06 Feb 2020 15:46:55 -0800] rev 44256
py3: fully fix bundlepart.__repr__ to return str not bytes
My previous fix did not fully fix the issue: it would attempt to use
%-formatting to combine two strs into a bytes, which won't work. Let's just
switch the entire function to operating in strs. This can cause a small output
difference that will likely not be noticed since no one noticed that the method
wasn't working at all before: if `id` or `type` are not-None, they'll be shown
as `b'val'` instead of `val`. Since this is a debugging aid and these strings
shouldn't be shown to the user, slightly rough output is most likely fine and
it's likely not worthwhile to add the necessary conditionals to marginally
improve it.
Differential Revision: https://phab.mercurial-scm.org/D8091
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 17 Nov 2019 01:18:14 +0100] rev 44255
heptapod-ci: add a job to test the rust version of Mercurial
The rust version of Mercurial is not currently tested by anything else. So it
get quite important that developer runs it.
Differential Revision: https://phab.mercurial-scm.org/D8017
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 Nov 2019 12:26:54 +0100] rev 44254
heptapod-ci: run the --pure test too
These are usually rarely run by individual developper because they are slow.
However it is important that they stay happy.
Differential Revision: https://phab.mercurial-scm.org/D8016
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 25 Jan 2020 14:56:36 +0100] rev 44253
heptapod-ci: run the normal test suite
The usual tests should be run too. We skip the "tests-check*.t" one because
their are already covered by another Ci step.
Differential Revision: https://phab.mercurial-scm.org/D8015
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Nov 2019 09:38:40 +0100] rev 44252
heptapod-ci: also run the dedicated rust test for the rust code
The Rust code has various standard rust test that are fast to run. So let's run them.
Differential Revision: https://phab.mercurial-scm.org/D8014
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 Nov 2019 12:25:53 +0100] rev 44251
heptapod-ci: run test with python3 too
Python3 is the future^W present, it is important to run tests with it too.
Differential Revision: https://phab.mercurial-scm.org/D8013
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 24 Jan 2020 23:22:29 +0100] rev 44250
heptapod-ci: colorize output
The run result are nicer to read with color.
Differential Revision: https://phab.mercurial-scm.org/D8012
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 25 Jan 2020 17:57:40 +0100] rev 44249
heptapod-ci: add a basic file to be able to run tests with heptapod
Having this yaml file somewhere in the main mercurial repository makes it
trivial for contributors using heptapod to run CI on their in-progress work.
There are alot of different combination (python2/python3 pure/cext/rust/pypy)
to be tested and making sure all of them are covered manually is cumbersome.
Automatic CI runnig on draft really helps in that matters. We start small bu
later changesets will add more step testing more of the variants.
The series is targetted on stable to make it available to the widest amount of contribution possible.
The definition of the docker files used for this are available here:
https://dev.heptapod.net/octobus/ci-dockerfiles
Differential Revision: https://phab.mercurial-scm.org/D8011
Jan Alexander Steffens (heftig) <jan.steffens@gmail.com> [Tue, 04 Feb 2020 22:07:36 +0100] rev 44248
worker: manually buffer reads from pickle stream
My previous fix (D8051, cb52e619c99e, which added Python's built-in buffering
to the pickle stream) has the problem that the selector will ignore the buffer.
When multiple pickled objects are read from the pipe into the buffer at once,
only one object will be loaded.
This can repeat until the buffer is full and delays the processing of completed
items until the worker exits, at which point the pipe is always considered
readable and all remaining items are processed.
This changeset reverts D8051, removing the buffer again. Instead, on Python 3
only, we use a wrapper to modify the "read" provided to the Unpickler to behave
more like a buffered read. We never read more bytes from the pipe than the
Unpickler requests, so the selector behaves as expected.
Also add a test case for "pickle data was truncated" issue.
https://phab.mercurial-scm.org/D8051#119193
Differential Revision: https://phab.mercurial-scm.org/D8076
Kyle Lippincott <spectral@google.com> [Thu, 02 Jan 2020 11:04:18 -0800] rev 44247
py3: __repr__ needs to return str, not bytes
Differential Revision: https://phab.mercurial-scm.org/D8089