Thu, 17 Feb 2022 06:35:42 +0100 tracked-key: update the requirement value
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 17 Feb 2022 06:35:42 +0100] rev 48791
tracked-key: update the requirement value We renamed the config option but we forgot to change the actual value… Differential Revision: https://phab.mercurial-scm.org/D12199
Thu, 17 Feb 2022 06:32:03 +0100 tracked-key: make it possible to upgrade to and downgrade from the feature
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 17 Feb 2022 06:32:03 +0100] rev 48790
tracked-key: make it possible to upgrade to and downgrade from the feature This seems rather important if we want people to start using it. Differential Revision: https://phab.mercurial-scm.org/D12198
Mon, 31 Jan 2022 18:13:00 +0300 obsolete: don't use os.stat in repo.obsstore.__nonzero__ if it's static HTTP
Anton Shestakov <av6@dwimlabs.net> [Mon, 31 Jan 2022 18:13:00 +0300] rev 48789
obsolete: don't use os.stat in repo.obsstore.__nonzero__ if it's static HTTP If a repo is accessed via static HTTP, then we obviously can't use os.stat() to just peek at the file size. Let's download the entire file to check its size. Yes, this feels wasteful, but: 1. If we're cloning or pulling a repo from a static HTTP server, we need the contents of the obsstore anyway. 2. Implementing statichttpvfs.stat() that uses HEAD will result in one more request to a static-only HTTP server, which is already slow. Also parsing a response to a HEAD request to construct os.stat_result is pretty hacky. There's also a question of the remote server properly supporting HEAD method and reporting at least file size. 3. Implementing statichttpvfs.stat() that uses GET is pretty much the same thing as we do here, except we can't even cache the response easily, unlike simply accessing obsstore._data, which is @propertycache'd. Importing statichttprepo locally to avoid circular import. See also: 4507bc001365 and commit message of f8f2ecdde4b5. Differential Revision: https://phab.mercurial-scm.org/D12195
Mon, 14 Feb 2022 22:49:03 -0800 filemerge: make `_maketempfiles()` more reusable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 14 Feb 2022 22:49:03 -0800] rev 48788
filemerge: make `_maketempfiles()` more reusable `_maketempfiles()` is very specialized for its current use. I hope to use it also when creating temporary files for input for tools that do partial conflict resolution. That'll be possible if the function is more generic. Instead of passing in two contexts (for "other" and "base") and an optional path (for "local"), let's pass a single list of files to make backups for. Even if we don't end up using for partial conflict resolution, this is still a simplification (but I do have a WIP patch for partial conflict resolution and it is able to benefit from this). Differential Revision: https://phab.mercurial-scm.org/D12193
Mon, 14 Feb 2022 22:16:29 -0800 filemerge: reduce some duplication in `_maketempfiles()`
Martin von Zweigbergk <martinvonz@google.com> [Mon, 14 Feb 2022 22:16:29 -0800] rev 48787
filemerge: reduce some duplication in `_maketempfiles()` The two callers of the local `maketempfrompath()` function used the returned file object in the same way. We can reduce duplication by moving that code into the function. Differential Revision: https://phab.mercurial-scm.org/D12192
Mon, 14 Feb 2022 22:11:50 -0800 filemerge: use leverage `util.readfile()` in `_maketempfiles()`
Martin von Zweigbergk <martinvonz@google.com> [Mon, 14 Feb 2022 22:11:50 -0800] rev 48786
filemerge: use leverage `util.readfile()` in `_maketempfiles()` Differential Revision: https://phab.mercurial-scm.org/D12191
Mon, 14 Feb 2022 22:04:50 -0800 filemerge: move removal of `.orig` extension on temp file close to context
Martin von Zweigbergk <martinvonz@google.com> [Mon, 14 Feb 2022 22:04:50 -0800] rev 48785
filemerge: move removal of `.orig` extension on temp file close to context The place where the `.orig` extension is removed in `_maketempfiles()` doesn't make it clear that it's the backup path, which is why we have a comment in the code explaining it. Let's instead move it out of the function and close to where we get it from `backup.path()`, so that becomes clear. Differential Revision: https://phab.mercurial-scm.org/D12190
Mon, 14 Feb 2022 21:52:18 -0800 filemerge: remove `uselocalpath` argument from `_maketempfiles()`
Martin von Zweigbergk <martinvonz@google.com> [Mon, 14 Feb 2022 21:52:18 -0800] rev 48784
filemerge: remove `uselocalpath` argument from `_maketempfiles()` The `localpath` argument is unused if `uselocalpath` is false, so we can use `None` as a sentinel value for the variable instead and remove extra `uselocalpath` argument. That's not much of a win, but it's a small step towards further improvements. Differential Revision: https://phab.mercurial-scm.org/D12189
Fri, 11 Feb 2022 22:39:53 -0800 filemerge: remove an unnecessary join with absolute path
Martin von Zweigbergk <martinvonz@google.com> [Fri, 11 Feb 2022 22:39:53 -0800] rev 48783
filemerge: remove an unnecessary join with absolute path The `backup` path is now always absolute, so we don't need to join it with the working copy path. Differential Revision: https://phab.mercurial-scm.org/D12188
Fri, 11 Feb 2022 21:39:55 -0800 filemerge: when using in-memory merge, always put backup files in temp dir
Martin von Zweigbergk <martinvonz@google.com> [Fri, 11 Feb 2022 21:39:55 -0800] rev 48782
filemerge: when using in-memory merge, always put backup files in temp dir Before calling a merge tool, we create a backup of the local side of the merge. That file can be put in the working copy or in a temporary directory, depending on the user's config. When we're merging in memory, we don't want to write to the actual, on-disk working copy, so we write the file to the in-memory working copy instead. However, since we don't support external merge tools with in-memory merge, it makes no difference where the file is actually stored (and if we ever do add support for external merge tools, then the file clearly can't live in the in-memory working-copy object anyway). So, since it doesn't matter where the file is stored, we can simplify by always putting them in the system's temp directory. Differential Revision: https://phab.mercurial-scm.org/D12187
Tue, 15 Feb 2022 20:18:57 -0800 filemerge: remove unused `repo` argument from `_maketempfiles()`
Martin von Zweigbergk <martinvonz@google.com> [Tue, 15 Feb 2022 20:18:57 -0800] rev 48781
filemerge: remove unused `repo` argument from `_maketempfiles()` I missed this in D12171. Differential Revision: https://phab.mercurial-scm.org/D12194
Tue, 15 Feb 2022 23:45:30 +0100 upgrade: make dirstate-v2 format variant compatible with share
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 15 Feb 2022 23:45:30 +0100] rev 48780
upgrade: make dirstate-v2 format variant compatible with share This only affects the dirstate and is safe to upgrade in the share. Differential Revision: https://phab.mercurial-scm.org/D12197
Tue, 15 Feb 2022 23:09:07 +0100 upgrade: prepare code (and output) for the idea of upgrading share
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 15 Feb 2022 23:09:07 +0100] rev 48779
upgrade: prepare code (and output) for the idea of upgrading share This would work for a subset of action only. Our first target is dirstate-v2. Differential Revision: https://phab.mercurial-scm.org/D12196
Tue, 15 Feb 2022 13:32:30 -0500 sparse: add timing block for parsing sparse configs
Augie Fackler <augie@google.com> [Tue, 15 Feb 2022 13:32:30 -0500] rev 48778
sparse: add timing block for parsing sparse configs This was showing up in an operation I was doing today, and I'd like to be able to get trace spans for it instead of just profiler samples. Differential Revision: https://phab.mercurial-scm.org/D12186
Tue, 15 Feb 2022 13:32:11 -0500 narrowspec: add timing block for validating narrowspec
Augie Fackler <augie@google.com> [Tue, 15 Feb 2022 13:32:11 -0500] rev 48777
narrowspec: add timing block for validating narrowspec This was showing up in an operation I was doing today, and I'd like to be able to get trace spans for it instead of just profiler samples. Differential Revision: https://phab.mercurial-scm.org/D12185
Tue, 15 Feb 2022 20:24:46 -0800 branching: merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 15 Feb 2022 20:24:46 -0800] rev 48776
branching: merge with stable
Fri, 11 Feb 2022 16:52:48 -0800 filemerge: put temporary files in single temp dir by default
Martin von Zweigbergk <martinvonz@google.com> [Fri, 11 Feb 2022 16:52:48 -0800] rev 48775
filemerge: put temporary files in single temp dir by default The feature introduced in D2888 seems like a pure improvement to me. It makes the names' of temporary file easier to read. Let's have it always enabled. I also removed the config option for the path prefix because it doesn't seem useful. I asked Kyle (the author of the feature) about it and he couldn't think of a reason to keep it. I suspect it was just that we to have a config to turn it on/off while it was experimental, so it might as well be a configurable prefix then. Differential Revision: https://phab.mercurial-scm.org/D12171
Tue, 15 Feb 2022 05:20:46 +0100 dirstate-tracked-key: update the config value to match latest discussion
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 15 Feb 2022 05:20:46 +0100] rev 48774
dirstate-tracked-key: update the config value to match latest discussion Special cases are not special enough, we align the option name on the other. The `version` value is undocumented for now as it can only have a single value. It is supported in the code to properly detect and abort if more value are introduced in the future value. Differential Revision: https://phab.mercurial-scm.org/D12184
Fri, 26 Nov 2021 15:38:04 +0100 rhg: signal when falling back in logs
Raphaël Gomès <rgomes@octobus.net> [Fri, 26 Nov 2021 15:38:04 +0100] rev 48773
rhg: signal when falling back in logs We use the `trace` level for the actual message because it can get really busy. Differential Revision: https://phab.mercurial-scm.org/D11814
Mon, 07 Feb 2022 13:23:58 +0100 revlog: register changelogv2 C implementation in parsers
pacien <pacien.trangirard@pacien.net> [Mon, 07 Feb 2022 13:23:58 +0100] rev 48772
revlog: register changelogv2 C implementation in parsers This allows Python code to make use of the C implementation of the changelogv2 base operations when the C extensions are enabled. The `format_version` values are now shared between the C and Python sides, avoiding an additional translation for the selection of the format version to use. Differential Revision: https://phab.mercurial-scm.org/D12179
Mon, 14 Feb 2022 12:34:02 +0100 revlog: implement changelogv2 packing and unpacking in C
pacien <pacien.trangirard@pacien.net> [Mon, 14 Feb 2022 12:34:02 +0100] rev 48771
revlog: implement changelogv2 packing and unpacking in C This introduces a C implementation of changelogv2 records packing and unpacking operations matching the pure Python counterpart, similarly to what we already have for revlogv1 and revlogv2. This is also necessary to access changelogv2 record fields from future Rust code without going through the Python part, which would annihilate any performance benefit. Differential Revision: https://phab.mercurial-scm.org/D12178
Thu, 10 Feb 2022 16:20:14 +0100 revlog: memset whole record instead of dealing with padding
pacien <pacien.trangirard@pacien.net> [Thu, 10 Feb 2022 16:20:14 +0100] rev 48770
revlog: memset whole record instead of dealing with padding This is less error-prone. Differential Revision: https://phab.mercurial-scm.org/D12177
Fri, 11 Feb 2022 05:37:19 +0100 revlog: do not compute node location by hand in index_invalidate_added
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 11 Feb 2022 05:37:19 +0100] rev 48769
revlog: do not compute node location by hand in index_invalidate_added The node is not guaranteed to be at the same location all the time (e.g: changelog v2), so let's use the official existing API to get that value. Differential Revision: https://phab.mercurial-scm.org/D12176
Fri, 28 Jan 2022 11:54:44 +0100 rank: compute property incrementally
pacien <pacien.trangirard@pacien.net> [Fri, 28 Jan 2022 11:54:44 +0100] rev 48768
rank: compute property incrementally This replaces the naive rank computation with a more efficient incremental method, avoiding computing the whole ancestor set when possible. Differential Revision: https://phab.mercurial-scm.org/D12143
Fri, 28 Jan 2022 11:45:33 +0100 rank: add test with golden values
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 28 Jan 2022 11:45:33 +0100] rev 48767
rank: add test with golden values This adds a regression test for the computation of the rank, using the current values computed with the naive algorithm as the "golden" reference. Differential Revision: https://phab.mercurial-scm.org/D12142
Fri, 28 Jan 2022 11:45:18 +0100 rank: add minimal test
pacien <pacien.trangirard@pacien.net> [Fri, 28 Jan 2022 11:45:18 +0100] rev 48766
rank: add minimal test This adds a small test checking the rank computation in the case of a merge. Differential Revision: https://phab.mercurial-scm.org/D12141
Fri, 28 Jan 2022 11:35:41 +0100 rank: add context and template keyword
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 28 Jan 2022 11:35:41 +0100] rev 48765
rank: add context and template keyword This makes the stored rank property accessible, to be expanded and printed. Differential Revision: https://phab.mercurial-scm.org/D12140
Fri, 28 Jan 2022 11:33:01 +0100 rank: naive rank property computation and retrieval
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 28 Jan 2022 11:33:01 +0100] rev 48764
rank: naive rank property computation and retrieval This stores the rank (size of the ancestor set of a revision, including itself) in a changelog field and allows this property to be retrieved. This new property is used as part of stable-range computations, which will be introduced later on. The value is computed in a naive way from the definition of the rank. This will be replaced by a more efficient version subsequently. Differential Revision: https://phab.mercurial-scm.org/D12139
Mon, 07 Feb 2022 22:54:38 -0800 filemerge: move check for identical sides out of filemerge()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 07 Feb 2022 22:54:38 -0800] rev 48763
filemerge: move check for identical sides out of filemerge() `filemerge.filemerge()` returns `None` if no merge was necessary because the two sides were identical. I don't think it should be that function's responsibility to handle that case; we should ideally not even call `filemerge.filemerge()` if the two inputs identical. This patch therefore moves the check out to the caller (`mergestate.py`). The largefiles test changed because we now notice that the two sides made the same change, so we don't consider it a merge. Also note that the new message better matches the line above it in the test output. Differential Revision: https://phab.mercurial-scm.org/D12154
Mon, 07 Feb 2022 20:12:09 -0800 mergestate: use an early return for trivial merges
Martin von Zweigbergk <martinvonz@google.com> [Mon, 07 Feb 2022 20:12:09 -0800] rev 48762
mergestate: use an early return for trivial merges `filemerge.filemerge()` returns `None` if no merge was needed because the two sides were identical. I'd like to move that to the caller. This is a little refactoring to prepare for that. Differential Revision: https://phab.mercurial-scm.org/D12153
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 tip