- Apr 05, 2022
-
-
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
-
- Mar 29, 2022
-
-
Yuya Nishihara authored
If I understand it, mctx.readfast() is unreliable here if p1/p2 .hgtags nodes differ, and tags on that branch would be randomly discarded depending on which parent were picked. The test case added by this patch would fail only on zstd-compressed repository. I didn't try hard to stabilize the failure case.
-
- Mar 28, 2022
-
-
Raphaël Gomès authored
This was forgotten about in the initial implementation and was revealed while adding the `dirstate-v2` variant of `test-issue660.t`. Neither the existing Python implementation nor the upcoming Rust implementation suffer from this bug since they respectively have `None` and `Option<T>` to represent the lack of information. Differential Revision: https://phab.mercurial-scm.org/D12414
-
- Mar 22, 2022
-
-
Jörg Sonnenberger authored
It is pullbundles.manifest and not pullbundle.manifest. Differential Revision: https://phab.mercurial-scm.org/D12391
-
- Mar 21, 2022
-
-
Martin von Zweigbergk authored
`hg unamend` can currently undo any kind of rewrite, as long as it has an obsmarker. However, that has quite unexpected results if you run it after e.g. `hg rebase` (expecting it to behave like a generic `hg undo` command), because it updates to the predecessor and leaves the old changes in the working copy. I think it's better to allow `hg unamend` only after `hg amend` (and after `hg unamend` because that's documented as being supported). Differential Revision: https://phab.mercurial-scm.org/D12390
-
- Mar 17, 2022
-
-
Pierre-Yves David authored
The official utility scale its timeout with the run-tests.py one. So lets use it. Differential Revision: https://phab.mercurial-scm.org/D12382
-
- Mar 19, 2022
-
-
Martin von Zweigbergk authored
If copy information is stored only in the commit extras and not in filelogs, then they get lost on amend if the file wasn't also modified in the working copy. That's because we create `filectx` object from the old commit in those cases, and the `.copysource()` of such objects read only from the filelog. This patch fixes it by always creating a new `memfilectx` in these cases, passing the calculated copy information to it. Differential Revision: https://phab.mercurial-scm.org/D12387
-
Martin von Zweigbergk authored
When copy information is stored in changesets, it gets lost on amend. We didn't notice that until now because our users at Google have the config set to `compatibility`, which means copy information is stored in both changeset and filelogs. Differential Revision: https://phab.mercurial-scm.org/D12386
-
- Mar 18, 2022
-
-
Pierre-Yves David authored
This new versioning will help us to maintain backward compatibility in the docker image. This will be useful to deal with mismatch between default/stable in version and the re-run CI on older changesets in the future. Once this changeset land on stable, we will have to merge it in default. Then we can start make backward incompatible changes in a new image version. Differential Revision: https://phab.mercurial-scm.org/D12388
-
Raphaël Gomès authored
During benchmarking it was determined that the use of more threads is very advantageous... until we use more than 16. This is most likely due to some resource contention (thrashing, etc.). Until we have time to figure out and fix the underlying cause, let's just cap at 16 threads. Differential Revision: https://phab.mercurial-scm.org/D12384
-
- Mar 15, 2022
-
-
Julien Cristau authored
Fixes: a3cf460a6b1b ("stream-clone: also filter the requirement we put in the bundle 2") Differential Revision: https://phab.mercurial-scm.org/D12377
-
Martin von Zweigbergk authored
As explained in the previous patch, we incorrectly leave conflict markers in both `$local` and `$output` since D12190. I don't understand why it broke but the fix is simple and clear after all the recent refactoring. Differential Revision: https://phab.mercurial-scm.org/D12379
-
Martin von Zweigbergk authored
When a merge tool is configured to keep conflict markers, they are supposed to be written to `$local` if `$output` is not mentioned in the tool's `merge-tools.<tool>.args` config, and in `$output` if it is mentioned. However, I broke the latter case in D12190. Differential Revision: https://phab.mercurial-scm.org/D12378
-
- Mar 14, 2022
-
-
Julien Cristau authored
We treat "rank" as an int everywhere, but declare rank_unknown as a char. On architectures where char is signed, that works out ok, but when char is unsigned, rank_unknown is 255 instead of -1. Differential Revision: https://phab.mercurial-scm.org/D12374
-
Luke Granger-Brown authored
The type of libc::c_char is u8 on aarch64 rather than i8, which causes the use of a specifically-typed constant to fail. Differential Revision: https://phab.mercurial-scm.org/D12373
-
- Mar 01, 2022
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
- Feb 28, 2022
-
-
Raphaël Gomès authored
We shouldn't rely on this member being present in `dirstate.py`, this creates unnecessary coupling. This also can trigger certain issues in edge-cases where the policy is changed at runtime or multiple Python environments fight, which is an added bonus. Differential Revision: https://phab.mercurial-scm.org/D12217
-
- Feb 21, 2022
-
-
Raphaël Gomès authored
Differential Revision: https://phab.mercurial-scm.org/D12205
-
- Feb 18, 2022
-
-
Raphaël Gomès authored
Differential Revision: https://phab.mercurial-scm.org/D12204
-
Raphaël Gomès authored
Differential Revision: https://phab.mercurial-scm.org/D12216
-
Raphaël Gomès authored
Differential Revision: https://phab.mercurial-scm.org/D12215
-
- Feb 22, 2022
-
-
Pierre-Yves David authored
See the comment in the test itself. Differential Revision: https://phab.mercurial-scm.org/D12214
-
- Feb 18, 2022
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-