- May 04, 2022
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
Nobody cares about this very narrow usecase, and py2 support is over by July 1st. This helps with the CI load, and removes some flakiness.
-
Raphaël Gomès authored
-
- May 03, 2022
-
-
kiilerix authored
The multiple lines were re-flowed to a single line, both in man page and html.
-
- May 04, 2022
-
-
Raphaël Gomès authored
This makes a programming error obvious in cases when it should not be skipped Differential Revision: https://phab.mercurial-scm.org/D12602
-
Raphaël Gomès authored
The Rust path never actually worked. This change also improves clarity of the comment. The next change will ensure we print something when this check fails. Differential Revision: https://phab.mercurial-scm.org/D12601
-
- Apr 28, 2022
-
-
Raphaël Gomès authored
As per the previous patch, the counter was incorrectly carried over from the old docket when it should be reset for a complete rewrite. Differential Revision: https://phab.mercurial-scm.org/D12594
-
Raphaël Gomès authored
This was picked up by @aalekseyev when doing unrelated debugging. The Rust implementation was never resetting this counter, so a brand new file would carry over the old counter. As I write this, my counter is a supposed 7389089 unused bytes for a total of 170978 bytes in the data file. Feel free to post your own high score. Differential Revision: https://phab.mercurial-scm.org/D12593
-
Raphaël Gomès authored
This is more robust. Differential Revision: https://phab.mercurial-scm.org/D12592
-
Raphaël Gomès authored
This is replaced by the more complete `--docket` option to `debugstate`. Differential Revision: https://phab.mercurial-scm.org/D12591
-
Raphaël Gomès authored
This is useful information that we don't easily have access to currently, unless you speak fluent xxd. This replaces `debugdirstateignorepatternshash`, which I'll remove in the next changeset. Differential Revision: https://phab.mercurial-scm.org/D12590
-
- May 03, 2022
-
-
Matt Harbison authored
This bug[1] was causing the zstd entry under "Available Compression Engines" to be omitted from the documentation for some versions of python3. I could upgrade, but past upgrades have broken venvs and clobbered installed packages. It's a trivial workaround, so there's no sense in leaving this subtle issue. It was flushed out by changing the module policy here from 'allow' to 'c', and seeing this error: ImportError: DLL load failed while importing parsers: The parameter is incorrect. [1] https://github.com/python/cpython/issues/87271 Differential Revision: https://phab.mercurial-scm.org/D12599
-
- Apr 25, 2022
-
-
Raphaël Gomès authored
In D12581 I introduced logic to remove the previous dirstate-v2 data file after a new one is created (and its corresponding docket), but the logic was flawed. I fixed it and made it simpler to understand by gather all logic in a single expression. Differential Revision: https://phab.mercurial-scm.org/D12586
-
- Apr 19, 2022
-
-
Raphaël Gomès authored
`rhg` is supposed to be a transparent executable, using a subprocess defeats that purpose. See inline comments for more details. This also introduces the `which` crate to check if the fallback executable actually exists to help debugging (plain `execve` doesn't give much information). The error code 253 is used to signify that the fallback is not found, but may mean in the future that it is otherwise invalid if we start being more specific. Differential Revision: https://phab.mercurial-scm.org/D12578
-
- Apr 27, 2022
-
-
Martin von Zweigbergk authored
Whoever wrote D8463 just used a hard-coded path to `.hg/last-message.text` instead of using the relative path that was already available in the `msgfn` variable (and used just a few lines up in related message). Let's fix that. Differential Revision: https://phab.mercurial-scm.org/D12585
-
- Apr 21, 2022
-
-
Raphaël Gomès authored
This was overlooked before and caused many data files to keep living forever. We could potentially consider adding a random cleanup of them in case they slipped through one day. Differential Revision: https://phab.mercurial-scm.org/D12581
-
Raphaël Gomès authored
This is currently only triggered with the tests ran with `--rhg` without `--rust`, by "luck", there probably always was something to write, like an mtime when also using Rust extensions alongside `rhg`. Differential Revision: https://phab.mercurial-scm.org/D12580
-
- Apr 13, 2022
-
-
Matt Harbison authored
The write function returns `None` if there was no room to write the given data[1]. I don't like that this is effectively an infinite loop if there's never any progress emptying the underlying buffer, but we're no worse off than before, and it fixes random stacktrace popups seen in the py3 build of TortoiseHg. [1] https://docs.python.org/3/library/io.html#io.RawIOBase.write Differential Revision: https://phab.mercurial-scm.org/D12555
-
- Apr 19, 2022
-
-
Martin von Zweigbergk authored
When there are removed files in the working copy and they are not selected to be amended into the parent, the `filectxfn` we create for the `memctx` would still return `None` before this patch. That's clearly incorrect; we should return the `filectx` from the unamended commit. Somehow it seems to not matter much except for the case with copies stored in changesets. Thanks to Kyle Lippincott for doing all the debugging and identifying the fix for this issue. Differential Revision: https://phab.mercurial-scm.org/D12573
-
Martin von Zweigbergk authored
See the fix in the next patch for explanation. Differential Revision: https://phab.mercurial-scm.org/D12572
-
- Apr 13, 2022
-
-
Kyle Lippincott authored
If a repo is sufficiently large, a six digit number "hash prefix" can somewhat easily reference an ambiguous hash prefix. Differential Revision: https://phab.mercurial-scm.org/D12552
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D12551
-
- Apr 07, 2022
-
-
Pierre-Yves David authored
This is a minor increase (5%) and makes the doc much clearer. Differential Revision: https://phab.mercurial-scm.org/D12484
-
Pierre-Yves David authored
Its might be a bit confusing, especially since `large-file.min-size` uses MB. Differential Revision: https://phab.mercurial-scm.org/D12483
-
- Apr 06, 2022
-
-
Pierre-Yves David authored
This is consistent with the main `lock.release` code. Differential Revision: https://phab.mercurial-scm.org/D12481
-
Pierre-Yves David authored
This should be useful for some shell invocation. Differential Revision: https://phab.mercurial-scm.org/D12480
-
Pierre-Yves David authored
On Windows msys seems to do awful mangling of the environment variable content that confuses everything to the death. Going through the config works fine, so we do that instead. Differential Revision: https://phab.mercurial-scm.org/D12479
-
- Apr 05, 2022
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
This also fixes the header for 6.1 from 6.1rc0
-
Raphaël Gomès authored
It's been stabilized a long time ago, so let's not rely on an implementation detail now. Differential Revision: https://phab.mercurial-scm.org/D12433
-
Raphaël Gomès authored
This was caught when writing unit tests for the `DirstateMap`. We were always setting `had_copy_source` to `false` since we erased the value just before. Differential Revision: https://phab.mercurial-scm.org/D12432
-
Raphaël Gomès authored
I found this bug when writing unit tests after the fact for the `DirstateMap`. We never decremented the tracked descendants counter since we were always resetting the node data before reading it. This also drops the use of `state`, in favor of the new API to get that information. Differential Revision: https://phab.mercurial-scm.org/D12431
-
Raphaël Gomès authored
When modifying the API I hit some... interesting errors (trying to allocate 178GB of RAM, for example) because I failed to keep the counters correctly updated. This counter underflow is likely to happen when code is changed around and can have up to eat-your-dirstate level of consequences, which is not nice. The very small runtime cost of checking these counters should really not be an issue and will help us uncover bugs when/if they do appear in the future. Differential Revision: https://phab.mercurial-scm.org/D12430
-
Raphaël Gomès authored
As per the previous patch, `OwningDirstateMap` is unsound. Self-referential structs are difficult to implement correctly in Rust since the compiler is free to move structs around as much as it wants to. They are also very rarely needed in practice, so the state-of-the-art on how they should be done within the Rust rules is still a bit new. The crate `ouroboros` is an attempt at providing a safe way (in the Rust sense) of declaring self-referential structs. It is getting a lot attention and was improved very quickly when soundness issues were found in the past: rather than relying on our own (limited) review circle, we might as well use the de-facto common crate to fix this problem. This will give us a much better chance of finding issues should any new ones be discovered as well as the benefit of fewer `unsafe` APIs of our own. I was starting to think about how I would present a safe API to the old struct but soon realized that the callback-based approach was already done in `ouroboros`, along with a lot more care towards refusing incorrect structs. In short: we don't return a mutable reference to the `DirstateMap` anymore, we expect users of its API to pass a `FnOnce` that takes the map as an argument. This allows our `OwningDirstateMap` to control the input and output lifetimes of the code that modifies it to prevent such issues. Changing to `ouroboros` meant changing every API with it, but it is relatively low churn in the end. It correctly identified the example buggy modification of `copy_map_insert` outlined in the previous patch as violating the borrow rules. Differential Revision: https://phab.mercurial-scm.org/D12429
-
Raphaël Gomès authored
See inline comments. Differential Revision: https://phab.mercurial-scm.org/D12428
-
- Apr 01, 2022
-
-
Valentin Gatien-Baron authored
When hg is interrupted, it creates ui.log like this: 1970/01/01 00:00:00 user @0000000000000000000000000000000000000000 (62488)> killed! exited 255 after 1.78 seconds This is due to a scoping problem: two different uses of the name "msg" collide. So rename one of them. Differential Revision: https://phab.mercurial-scm.org/D12427
-
- Jul 23, 2021
-
-
Sushil Khanchi authored
Before this patch, if we try to `hg prune` (without any successors) an already obsoleted cset which has at least one successor, it would false warn about new content-divergence. As we know, pruning cset without any successors can not create any divergence. Differential Revision: https://phab.mercurial-scm.org/D12002
-
- Mar 24, 2022
-
-
Valentin Gatien-Baron authored
I don't really know how, but I ran into this error: $ hg clone --stream ssh://user@dummy/empty-repo local-empty-repo streaming all changes abort: unable to apply stream clone: unsupported format: [255] I think you need an empty list of requirements for this to happen, which is weird, but an obscure error like this is not exactly helpful either. Since this is the result of an encoding bug anyway, just fix it. Differential Revision: https://phab.mercurial-scm.org/D12402
-