- Feb 28, 2023
-
-
Matt Harbison authored
The LFS extension requires this, and if it isn't enabled on the client (or the LFS extension isn't loaded), a web client gets a 500 instead of a sensible error message. Now it gets a different (client) error, but maybe it can be handled more gracefully. c0f11347b107 indicates that treemanifest repos have this issue too. 29cfc474c5fd mentions gating this behind `experimental` so that the format could change, but that was 7 years ago and we now have an experimental `changegroup4` as well. We can keep this as a config for the next cycle in case someone runs into an unexpected problem, and then jettison it if the infinitepush bundle name changes are either acceptable as-is or can be created differently.
-
- Mar 02, 2023
-
-
Pierre-Yves David authored
The clippy god had to be appeased on some aspect.
-
- Feb 28, 2023
-
-
Matt Harbison authored
I *think* this is the only diffopt exposed on the command line. TortoiseHg had a similar issue creating diffopts, and this was caught by type hints in the next commit.
-
- Mar 01, 2023
-
-
Raphaël Gomès authored
This allows us to detect changes of `.hg/dirstate`, which is either the full dirstate (in dirstate-v1) or the docket file (v2) without relying on data inside the file. It only works on UNIX systems. This fixes a race condition for dirstate-v1 (as demonstrated by the test changes) and adds a confortable layer of sanity for dirstate-v2.
-
- Feb 28, 2023
-
-
Raphaël Gomès authored
This fixes the following race: - process A reads the dirstate - process B reads and writes the dirstate - process A writes the dirstate This either resulted in losing what process B had just written or a crash because the `uuid` had changed and we were trying to write to a file that doesn't exist. More explanations inside. This doesn't fix the issue for dirstate-v1, a later patch addresses it.
-
Pierre-Yves David authored
Now that most code behaves properly, we can simplify the expected matching.
-
Pierre-Yves David authored
If we cannot read the dirstate data, this is probably because a writing process wrote it under our feet. So refresh the docket and try again a handful of time.
-
Pierre-Yves David authored
If we cannot read the dirstate data, this is probably because a writing process wrote it under our feet. So refresh the docket and try again a handful of time.
-
Pierre-Yves David authored
If we cannot read the dirstate data, this is probably because a writing process wrote it under our feet. So refresh the docket and try again a handful of time.
-
- Feb 27, 2023
-
-
Pierre-Yves David authored
This covers more ground and finds more bugs. At that point I gave up on making things as `known-bad-output` / `missing-correct-output` as this gets too messy.
-
- Feb 26, 2023
-
-
Pierre-Yves David authored
More cases mean different issues.
-
Pierre-Yves David authored
More problems to solve.
-
Pierre-Yves David authored
More problems to solve.
-
Pierre-Yves David authored
Once in a while, rhg is the only one to behave right here.
-
- Feb 24, 2023
-
-
Pierre-Yves David authored
More problems to solve… yeah ! (I guess)
-
- Feb 27, 2023
-
-
Raphaël Gomès authored
See next changeset for the other race in the same kind of logic and why there are two different places.
-
- Feb 25, 2023
-
-
Pierre-Yves David authored
This shows that `rhg` is misbehaving here.
-
- Feb 24, 2023
-
-
Pierre-Yves David authored
The way the racing process touches the dirstate results in different challenges for the raced process. We now test each variant in the `test-dirstate-status-race.t` tests.
-
- Feb 28, 2023
-
-
Raphaël Gomès authored
This will help us to write predictable tests checking behavior in each case.
-
- Feb 24, 2023
-
-
Pierre-Yves David authored
Previously we were only testing it with the default (dirstate-v1 currently). Now we explicitly test each variant.
-
Pierre-Yves David authored
This shows that `rhg` is misbehaving here.
-
Pierre-Yves David authored
This shows that `rhg` is misbehaving here.
-
- Feb 23, 2023
-
-
Pierre-Yves David authored
This shows that `rhg` is misbehaving here.
-
- Feb 24, 2023
-
-
Pierre-Yves David authored
This shows that `rhg` is misbehaving here.
-
- Feb 28, 2023
-
-
Raphaël Gomès authored
We add the `devel.sync.status.pre-dirstate-write-file` config option to easily test what happens when other operations happen during the window where `hg status` is done working but has not updated the cache on disk yet. We introduce the framework for testing such races too, actual tests will be added in the next changesets. For now the test is only checking dirstate-v1. We will extend the test coverage later too. Check test documentation for details. Code change from Raphaël Gomès <rgomes@octobus.net> Test change from Pierre-Yves David <pierre-yves.david@octobus.net>
-
Matt Harbison authored
These versions of python are no longer supported by Mercurial.
-
Matt Harbison authored
It looks like this predicate isn't used at all(?)
-
- Jan 31, 2023
-
-
Pierre-Yves David authored
This is not that hard to implement and makes our life easier on a regular basis.
-
- Feb 23, 2023
-
-
Pierre-Yves David authored
This make it clearer which type of delta we are talking about.
-
Matt Harbison authored
The phase information contained in the changegroup part and the explicit `phase-heads` part are now taken in account. Initial changes and test by Matt Harbison, code rework by Pierre-Yves David.
-
Pierre-Yves David authored
Branch is a bit special : - It currently does not collaborate with the transaction (or any scoping) for writing (this is bad) - It can change without the lock being taken (it is protected by `wlock`) So we rely on the same mechanism as for the backup of the other dirstate file: - we only do a backup if we hold the wlock - we force a backup though the transaction Since "branch" write does not collaborate with the transaction, we cannot back it up "at the last minute" as we do for the dirstate. We have to back it up "upfront". Since we have a backup, the transaction is no longer doing its "quick_abort" and get noisy. Which is quite annoying. To work around this, and to avoid jumping in yet-another-rabbit-hole of "getting branch written properly", I am doing horrible things to the transaction in the meantime. We should be able to get this code go away during the next cycle. In the meantime, I prefer to take this small stop so that we stop abusing the "journal" and "undo" mechanism instead of the proper backup mechanism of the transaction. Also note that this change regress the warning message for the legacy fallback introduced in 2008 when issue902 got fixed in dd5a501cb97f (Mercurial 1.0). I feel like this is fine as issue 902 remains fixed, and this would only affect people deploying a mix of 15 year old Mercurial and modern mercurial, and using branch and rollback extensively.
-
Pierre-Yves David authored
The transaction file generation is already dealing with the backup for this. So, no need to duplicate such backup.
-
- Feb 22, 2023
-
-
Pierre-Yves David authored
The transaction file generation is already dealing with the backup for this. So, no need to duplicate such backup.
-
- Feb 23, 2023
-
-
Pierre-Yves David authored
Now that the transaction manage the writes, we can simply use the transaction for backup. Some extra cleanup to ensure all changes happens within a transaction will be made in the next changesets.
-
- Feb 24, 2023
-
-
Arseniy Alekseyev authored
For example, on my box I'm seeing: $TESTTMP.sh: line 250: $pid Killed hg ci -qAm z
-
- Jan 09, 2023
-
-
Raphaël Gomès authored
The previous method was fragile and somewhat flaky on fast machines.
-
- Feb 22, 2023
-
-
Pierre-Yves David authored
This show that the recent changes on default fixed the issue with transaction overwriting content in `test-transaction-wc-rollback-race.t`
-
Pierre-Yves David authored
We actually do not! Great.
-
Pierre-Yves David authored
spoiler: we do… /o\
-
Pierre-Yves David authored
We actually do not! Great. …Why are doing a backup of the `branch` files at transaction creation then‽
-