Wed, 03 Mar 2021 12:30:23 +0100 requirements: also add a generaldelta constant
Raphaël Gomès <rgomes@octobus.net> [Wed, 03 Mar 2021 12:30:23 +0100] rev 46627
requirements: also add a generaldelta constant Continue the cleanup to the remaining requirements Differential Revision: https://phab.mercurial-scm.org/D10106
Wed, 03 Mar 2021 14:00:45 +0100 requirements: add constant for revlog v1 requirement
Raphaël Gomès <rgomes@octobus.net> [Wed, 03 Mar 2021 14:00:45 +0100] rev 46626
requirements: add constant for revlog v1 requirement Since this series is adding a new requirement, we might as well clean up while we're here. Differential Revision: https://phab.mercurial-scm.org/D10105
Thu, 18 Feb 2021 15:07:45 +0100 error: add `hint` attribute to `SidedataHashError`
Raphaël Gomès <rgomes@octobus.net> [Thu, 18 Feb 2021 15:07:45 +0100] rev 46625
error: add `hint` attribute to `SidedataHashError` This prevents an exception within an exception because `hint` does not exist. Differential Revision: https://phab.mercurial-scm.org/D10024
Fri, 19 Feb 2021 11:17:16 +0100 changegroup: use the local variable instead of reaching through self
Raphaël Gomès <rgomes@octobus.net> [Fri, 19 Feb 2021 11:17:16 +0100] rev 46624
changegroup: use the local variable instead of reaching through self Gratuitous cleanup while I was here. Differential Revision: https://phab.mercurial-scm.org/D10023
Fri, 29 Jan 2021 12:17:11 +0100 config: use level to properly deal with value priority
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 29 Jan 2021 12:17:11 +0100] rev 46623
config: use level to properly deal with value priority A higher priority alias will now take precedence over lower priority ones. This was a requirements step before using alias more widely, especially to rename existing and established config option. Differential Revision: https://phab.mercurial-scm.org/D9927
Fri, 29 Jan 2021 11:21:49 +0100 config: track the "level" of a value
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 29 Jan 2021 11:21:49 +0100] rev 46622
config: track the "level" of a value Config value now remember the "level" of the config that loaded it. This will be used to ensure good priority management for alias. Differential Revision: https://phab.mercurial-scm.org/D9926
Fri, 29 Jan 2021 10:28:03 +0100 config: track "source" along side value
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 29 Jan 2021 10:28:03 +0100] rev 46621
config: track "source" along side value Currently the source is stored in a entirely different way than the data. This is impractical. Especially if we are about to add more of such metadata. So lets put them back together. Differential Revision: https://phab.mercurial-scm.org/D9925
Sat, 30 Jan 2021 00:32:42 +0100 config: use a new `alter` method in `fixconfig`
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 30 Jan 2021 00:32:42 +0100] rev 46620
config: use a new `alter` method in `fixconfig` The `set` function is doing various work related to metadata (eg: the source, later the level). However the `fixconfig` call only updating some values according to standard processing, not changing any of the related metadata. So we introduce a new method and use it there. Differential Revision: https://phab.mercurial-scm.org/D9924
Mon, 01 Mar 2021 14:44:29 -0800 copies-rust: remove an unnecessary format!() inside assert!()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 01 Mar 2021 14:44:29 -0800] rev 46619
copies-rust: remove an unnecessary format!() inside assert!() The `assert!()` macro supports formatting. Rust 2021 no longer supports an unnecessary `format!()` inside it. I noticed because I recently update my Rust toolchain and `test-check-cargo-lock.t` started failing. Differential Revision: https://phab.mercurial-scm.org/D10085
Mon, 01 Mar 2021 20:08:26 +0100 copies: tests and fix parallel computation of changed file information
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 01 Mar 2021 20:08:26 +0100] rev 46618
copies: tests and fix parallel computation of changed file information The code was mixing variable name and misbehaving in some case. This changeset fix it and also add a tests to validate it does not regress. Without the fix, the parallel-upgrade misbehavior in random ways. Differential Revision: https://phab.mercurial-scm.org/D10084
Fri, 29 Jan 2021 13:07:00 +0100 config: test priority involving alias and cli
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 29 Jan 2021 13:07:00 +0100] rev 46617
config: test priority involving alias and cli Differential Revision: https://phab.mercurial-scm.org/D9920
Fri, 29 Jan 2021 12:03:29 +0100 config: test priority involving alias and include
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 29 Jan 2021 12:03:29 +0100] rev 46616
config: test priority involving alias and include Differential Revision: https://phab.mercurial-scm.org/D9919
Fri, 29 Jan 2021 12:02:28 +0100 config: test priority involving alias
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 29 Jan 2021 12:02:28 +0100] rev 46615
config: test priority involving alias Differential Revision: https://phab.mercurial-scm.org/D9918
Thu, 25 Feb 2021 21:25:04 +0100 rhg: Check .hg/requires for absence of required features
Simon Sapin <simon.sapin@octobus.net> [Thu, 25 Feb 2021 21:25:04 +0100] rev 46614
rhg: Check .hg/requires for absence of required features Some old repository layouts are not supported. Differential Revision: https://phab.mercurial-scm.org/D10076
Thu, 25 Feb 2021 23:14:35 +0100 rhg: Bug fix: with share-safe, always read store requirements
Simon Sapin <simon.sapin@octobus.net> [Thu, 25 Feb 2021 23:14:35 +0100] rev 46613
rhg: Bug fix: with share-safe, always read store requirements That is, the `store/requires` file, regardless of whether the repository is a shared. Differential Revision: https://phab.mercurial-scm.org/D10078
Mon, 11 Jan 2021 12:17:16 +0100 copies-rust: pass closures and iterators instead of `&ChangedFiles`
Simon Sapin <simon.sapin@octobus.net> [Mon, 11 Jan 2021 12:17:16 +0100] rev 46612
copies-rust: pass closures and iterators instead of `&ChangedFiles` … to some functions that only use one method. This will makes it easier to unit-test them. Differential Revision: https://phab.mercurial-scm.org/D10070
Fri, 08 Jan 2021 11:58:16 +0100 copies-rust: pass `PathToken` around by value
Simon Sapin <simon.sapin@octobus.net> [Fri, 08 Jan 2021 11:58:16 +0100] rev 46611
copies-rust: pass `PathToken` around by value It’s just a `usize`. Differential Revision: https://phab.mercurial-scm.org/D10069
Wed, 24 Feb 2021 09:27:33 -0800 tests: correct a commit description in test-copies-chain-merge.t
Martin von Zweigbergk <martinvonz@google.com> [Wed, 24 Feb 2021 09:27:33 -0800] rev 46610
tests: correct a commit description in test-copies-chain-merge.t Differential Revision: https://phab.mercurial-scm.org/D10065
Wed, 24 Feb 2021 12:40:54 -0500 fuzz: if the caller of our makefile sets CC and CXX, trust them
Augie Fackler <augie@google.com> [Wed, 24 Feb 2021 12:40:54 -0500] rev 46609
fuzz: if the caller of our makefile sets CC and CXX, trust them This should fix the broken fuzzing build, because we've been explicitly using clang++ but are now being given a CXX=afl++, which does extra stuff. Differential Revision: https://phab.mercurial-scm.org/D10066
Fri, 26 Feb 2021 12:16:43 +0100 rhg: Use clap’s support for global CLI arguments
Simon Sapin <simon.sapin@octobus.net> [Fri, 26 Feb 2021 12:16:43 +0100] rev 46608
rhg: Use clap’s support for global CLI arguments By default, clap only accepts app-level arguments (as opposed to sub-command level) to be specified before a sub-command: `rhg -R ./foo log`. Specifying them after would be rejected: `rhg log -R ./foo`. Previously we worked around that by registering global arguments both at the app level and on each sub-command, but that required looking for their value in two places. It turns out that Clap has built-in support for what we want to do, so let’s use it. Also, Clap "settings" turn out to be either global or not too. Let’s make `AllowInvalidUtf8` apply to sub-commands too. Differential Revision: https://phab.mercurial-scm.org/D10080
Wed, 03 Feb 2021 16:33:10 -0800 revlog: add a mechanism to verify expected file position before appending
Kyle Lippincott <spectral@google.com> [Wed, 03 Feb 2021 16:33:10 -0800] rev 46607
revlog: add a mechanism to verify expected file position before appending If someone uses `hg debuglocks`, or some non-hg process writes to the .hg directory without respecting the locks, or if the repo's on a networked filesystem, it's possible for the revlog code to write out corrupted data. The form of this corruption can vary depending on what data was written and how that happened. We are in the "networked filesystem" case (though I've had users also do this to themselves with the "`hg debuglocks`" scenario), and most often see this with the changelog. What ends up happening is we produce two items (let's call them rev1 and rev2) in the .i file that have the same linkrev, baserev, and offset into the .d file, while the data in the .d file is appended properly. rev2's compressed_size is accurate for rev2, but when we go to decompress the data in the .d file, we use the offset that's recorded in the index file, which is the same as rev1, and attempt to decompress rev2.compressed_size bytes of rev1's data. This usually does not succeed. :) When using inline data, this also fails, though I haven't investigated why too closely. This shows up as a "patch decode" error. I believe what's happening there is that we're basically ignoring the offset field, getting the data properly, but since baserev != rev, it thinks this is a delta based on rev (instead of a full text) and can't actually apply it as such. For now, I'm going to make this an optional component and default it to entirely off. I may increase the default severity of this in the future, once I've enabled it for my users and we gain more experience with it. Luckily, most of my users have a versioned filesystem and can roll back to before the corruption has been written, it's just a hassle to do so and not everyone knows how (so it's a support burden). Users on other filesystems will not have that luxury, and this can cause them to have a corrupted repository that they are unlikely to know how to resolve, and they'll see this as a data-loss event. Refusing to create the corruption is a much better user experience. This mechanism is not perfect. There may be false-negatives (racy writes that are not detected). There should not be any false-positives (non-racy writes that are detected as such). This is not a mechanism that makes putting a repo on a networked filesystem "safe" or "supported", just *less* likely to cause corruption. Differential Revision: https://phab.mercurial-scm.org/D9952
Tue, 23 Feb 2021 22:58:30 -0800 narrow: remove assertion about working copy being clean
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Feb 2021 22:58:30 -0800] rev 46606
narrow: remove assertion about working copy being clean The user can always modify the working copy, including while they're running `hg tracked --remove-include <path>`. Nothing really bad happens when they do that, and we already have code for printing a nice warning, so we can safely remove the assertion we had. Differential Revision: https://phab.mercurial-scm.org/D10063
Tue, 23 Feb 2021 22:55:26 -0800 tests: demonstrate assertion error when modifying working copy while narrowing
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Feb 2021 22:55:26 -0800] rev 46605
tests: demonstrate assertion error when modifying working copy while narrowing Differential Revision: https://phab.mercurial-scm.org/D10062
Thu, 04 Feb 2021 23:23:35 +0100 ci: test real dependency installation for pip
Joerg Sonnenberger <joerg@bec.de> [Thu, 04 Feb 2021 23:23:35 +0100] rev 46604
ci: test real dependency installation for pip In the past, the pip smoke test inhibited actual dependency installation, but that fails in different environments for setuptools itself. Since it isn't what we actually want to test (which is pip install), allow this to call home, if HGTESTS_ALLOW_NETIO=1 is set in the environment. Differential Revision: https://phab.mercurial-scm.org/D9950
Wed, 17 Feb 2021 20:40:19 +0100 rust: Add some unit tests for parse_byte_size in config
Simon Sapin <simon.sapin@octobus.net> [Wed, 17 Feb 2021 20:40:19 +0100] rev 46603
rust: Add some unit tests for parse_byte_size in config Differential Revision: https://phab.mercurial-scm.org/D10022
Wed, 17 Feb 2021 20:24:04 +0100 rust: Move config value parsing functions to a new module
Simon Sapin <simon.sapin@octobus.net> [Wed, 17 Feb 2021 20:24:04 +0100] rev 46602
rust: Move config value parsing functions to a new module Differential Revision: https://phab.mercurial-scm.org/D10021
Tue, 16 Feb 2021 13:08:37 +0100 rhg: Add support for the blackbox extension
Simon Sapin <simon.sapin@octobus.net> [Tue, 16 Feb 2021 13:08:37 +0100] rev 46601
rhg: Add support for the blackbox extension Only `command` and `commandfinish` events are logged. The `dirty`, `logsource`, `track` and `ignore` configuration items are not supported yet. To indicate commands executed without Python, a `(rust) ` prefix is added in corresponding log messages. Differential Revision: https://phab.mercurial-scm.org/D10012
Wed, 17 Feb 2021 13:00:25 +0100 blackbox: Remove misleading quotes in config example
Simon Sapin <simon.sapin@octobus.net> [Wed, 17 Feb 2021 13:00:25 +0100] rev 46600
blackbox: Remove misleading quotes in config example This example previously looked like quotes were part of configuration file syntax, and the parsed `date-format` value was the part inside of them. This is not the case: config syntax only parses quotes in list values. Instead using that config would result in literal quotes being written to `.hg/blackbox.log` as part of the date format. This changes the example to what was probably intended. Differential Revision: https://phab.mercurial-scm.org/D10011
Thu, 11 Feb 2021 15:51:11 +0100 rust: Add a log file rotation utility
Simon Sapin <simon.sapin@octobus.net> [Thu, 11 Feb 2021 15:51:11 +0100] rev 46599
rust: Add a log file rotation utility This is ported to Rust from `mercurial/loggingutil.py`. The "builder" pattern is used to make it visible at call sites what the two numeric parameters mean. In Python they might simply by keyword arguments. Differential Revision: https://phab.mercurial-scm.org/D10010
Tue, 16 Feb 2021 15:22:20 +0100 rust: Add a `ConfigValueParseError` variant to common errors
Simon Sapin <simon.sapin@octobus.net> [Tue, 16 Feb 2021 15:22:20 +0100] rev 46598
rust: Add a `ConfigValueParseError` variant to common errors Configuration files are parsed into sections of key/value pairs when they are read, but at that point values are still arbitrary bytes. Only when a value is accessed by various parts of the code do we know its expected type and syntax, so values are parsed at that point. Let’s make a new error type for this latter kind of parsing error, and add a variant to the common `HgError` so that most code can propagate it without much boilerplate. Differential Revision: https://phab.mercurial-scm.org/D10009
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 tip