- Dec 07, 2021
-
-
Pierre-Yves David authored
A share will use the same format as its source for the store, but there are no reason to not lets it control the working copy variant at creation time. So we make it so. Differential Revision: https://phab.mercurial-scm.org/D11892
-
- Dec 08, 2021
-
-
Pierre-Yves David authored
This give the "same" result, while taking in account that the requirement file might be in different location, like what `share-safe` is doing. Differential Revision: https://phab.mercurial-scm.org/D11895
-
Pierre-Yves David authored
This will make the test less sensible to unrelated format changing. Differential Revision: https://phab.mercurial-scm.org/D11894
-
- Dec 07, 2021
-
-
Pierre-Yves David authored
This will make the test less sensible to unrelated format changing. Differential Revision: https://phab.mercurial-scm.org/D11893
-
- Nov 07, 2021
-
-
sliquister authored
In 6.0 this used to result in the size being stored in the dirstate is wrong. This was fixed by other change to the mtime gathering logic. Differential Revision: https://phab.mercurial-scm.org/D11749
-
- Dec 07, 2021
-
-
Arseniy Alekseyev authored
Differential Revision: https://phab.mercurial-scm.org/D11882
-
Arseniy Alekseyev authored
Differential Revision: https://phab.mercurial-scm.org/D11880
-
- Dec 10, 2021
-
-
Simon Sapin authored
With dirstate-v2 and rhg both enabled, this test would sometimes fail for me with: ``` --- tests/test-status.t +++ tests/test-status.t#dirstate-v2.err @@ -943,7 +943,7 @@ $ rm subdir/unknown $ hg status $ hg debugdirstate --all --no-dates | grep '^ ' - 0 -1 set subdir + 0 -1 unset subdir ``` Meaning that `status` did not write a directory mtime in the dirstate as expected. This can happen if the observed mtime of the directory is the same as "current time" at the start of `status`. This current time is obtained by creating a temporary file and checking its mtime. Even with ext4 on my system being able to store nanosecond precision, identical mtime for successive but separate operations is still possible becuse the kernel may cache the current time: https://stackoverflow.com/a/14393315/1162888 0.1 second should be enough for this cache to be updated, without significantly slowing down the test. Differential Revision: https://phab.mercurial-scm.org/D11900
-
Simon Sapin authored
Copy sources are collected during `status()` rather than after the fact like in Python, because `status()` takes a `&mut` exclusive reference to the dirstate map (in order to potentially mutate it for directory mtimes) and returns `Cow<'_, HgPath>` that borrow the dirstate map. Even though with `Cow` only some shared borrows remain, the still extend the same lifetime of the initial `&mut` so the dirstate map cannot be borrowed again to access copy sources after the fact: https://doc.rust-lang.org/nomicon/lifetime-mismatch.html#limits-of-lifetimes Additionally, collecting copy sources during the dirstate tree traversal that `status()` already does avoids the cost of another traversal or other lookups (though I haven’t benchmarked that cost). Differential Revision: https://phab.mercurial-scm.org/D11899
-
- Dec 06, 2021
-
-
Pierre-Yves David authored
We have more and more requirement that does not affect revlog or that only affect some of them. It is silly to force a full processing of all revlog to juste move the requirement around, or to simply rewrite the dirstate. So now, only the revlog that needs to be touched will be touched. Unless the --changelog & al flags are used. Differential Revision: https://phab.mercurial-scm.org/D11871
-
Pierre-Yves David authored
This is more explicite and prepare for a smoother transition to smarter picking of the revlog we will process. Differential Revision: https://phab.mercurial-scm.org/D11870
-
Pierre-Yves David authored
Some format upgrade/downgrades -needs- revlog to be recomputed. So we now detect that individually and warn when it contradict explicitly passed flag. This is part of a larger series to make `debugupgraderepo` smarter about which revlog it picks by default. Differential Revision: https://phab.mercurial-scm.org/D11869
-
- Dec 07, 2021
-
-
Raphaël Gomès authored
See inline comments Differential Revision: https://phab.mercurial-scm.org/D11874
-
- Dec 06, 2021
-
-
Pierre-Yves David authored
This used to crash as the dirstate file does not exist in this case. Differential Revision: https://phab.mercurial-scm.org/D11866
-
Pierre-Yves David authored
There is no reason to gate this anymore. Differential Revision: https://phab.mercurial-scm.org/D11865
-
- Dec 07, 2021
-
-
Pierre-Yves David authored
This breaks on Windows, so lets use `>2 /dev/null` like in the other tests. Differential Revision: https://phab.mercurial-scm.org/D11873
-
- Dec 06, 2021
-
-
Pierre-Yves David authored
This will make the test less noisy when new requirement are added. Differential Revision: https://phab.mercurial-scm.org/D11864
-
- Dec 04, 2021
-
-
Martin von Zweigbergk authored
The caller is now trivial, so the indirection is pointless. Differential Revision: https://phab.mercurial-scm.org/D11860
-
Martin von Zweigbergk authored
This patch removes the `premerge` argument from `_filemerge()` and makes it do both the "premerge" and "merge" steps without the caller having to call it twice. Differential Revision: https://phab.mercurial-scm.org/D11859
-
- Dec 03, 2021
-
-
Martin von Zweigbergk authored
The separation between `preresolve()` and `resolve()` was something added for the "merge driver" feature. Since we removed that in 32ce4cbaec4b (mergedriver: delete it, 2020-09-17), we don't need the separation anymore. More cleanups will follow. Differential Revision: https://phab.mercurial-scm.org/D11855
-
- Dec 04, 2021
-
-
Martin von Zweigbergk authored
The `failfilemerge()` function always raises an exception without looking at its arguments, so let's use `*args` and `**kwargs`. Differential Revision: https://phab.mercurial-scm.org/D11854
-
- Nov 26, 2021
-
-
Raphaël Gomès authored
Differential Revision: https://phab.mercurial-scm.org/D11807
-
- Nov 25, 2021
-
-
Simon Sapin authored
Differential Revision: https://phab.mercurial-scm.org/D11840
-
- Dec 04, 2021
-
-
Pierre-Yves David authored
They are minor output different to be taken in account. Differential Revision: https://phab.mercurial-scm.org/D11861
-
- Nov 16, 2021
-
-
Arseniy Alekseyev authored
This adds a minimal support that can be implemented without parsing the narrowspec. We can parse the narrowspec and add support for more operations later. The reason we need so few code changes is as follows: Most operations need no special treatment of sparse because some of them only read dirstate (`rhg files` without `-r`), which bakes in the filtering, some of them only read store (`rhg files -r`, `rhg cat`), and some of them read no data at all (`rhg root`, `rhg debugrequirements`). `status` is the command that might care about sparse, so we just disable rhg on it. For narrow clones, `rhg files` clearly needs the narrowspec to work correctly, so we fall back. `rhg cat` seems to work consistently with `hg cat` if the file exists. If the file is hidden by narrow spec, the error message is different and confusing, so that's something that we should improve in follow-up patches. Differential Revision: https://phab.mercurial-scm.org/D11764
-
- Dec 03, 2021
-
-
Pierre-Yves David authored
This make the various option clearer. Differential Revision: https://phab.mercurial-scm.org/D11852
-
Pierre-Yves David authored
Before this change `--merge` override `commands.update.check=abort/noconflict`, and `--check` "override" `commands.update.check=none/linear`. However the `--no-merge` and `--no-check` version where not doing anything. The `--no-` two flags now behave properly. Differential Revision: https://phab.mercurial-scm.org/D11851
-
Pierre-Yves David authored
I don't see this behavior tested anywhere. Differential Revision: https://phab.mercurial-scm.org/D11850
-
Pierre-Yves David authored
This helps readability and searchability. Differential Revision: https://phab.mercurial-scm.org/D11848
-
- Nov 24, 2021
-
-
Pierre-Yves David authored
This will be used to support the `mtime-second-ambiguous` flag from dirstate v2. See format documentation for details. For now, we only make it possible to store the information, no other logic have been added. Differential Revision: https://phab.mercurial-scm.org/D11842
-
- Nov 23, 2021
-
-
Pierre-Yves David authored
If the test was fast enough, some mtime where not stored. We now wait long enough to ensure the mtime is no longer ambiguous. Differential Revision: https://phab.mercurial-scm.org/D11798
-
- Nov 19, 2021
-
-
Pierre-Yves David authored
Now that all¹ stored mtime are non ambiguous, we no longer need to apply the `need_delay` step. The need delay logic was not great are mtime gathered during longer operation could be ambiguous but younger than the `dirstate.write` call time. So, we don't need that logic anymore and can drop it This make the code much simpler. The code related to the test extension faking the dirstate write is now obsolete and associated test will be migrated as follow up. They currently do not break. [1] except the ones from `hg update`, but `need_delay` no longer help for them either. Differential Revision: https://phab.mercurial-scm.org/D11796
-
- Nov 18, 2021
-
-
Pierre-Yves David authored
We record the filesystem time at the start of the status walk and use that as a boundary to detect files that might be modified during (or right after) the status run without the mtime allowing that edition to be detected. We currently do this at a second precision. In a later patch, we will use nanosecond precision when available. To cope with "broken" time on the file system where file could be in the future, we also keep mtime for file over one day in the future. See inline comment for details. Large file tests get a bit more confused as we reduce the odds for race condition. As a "side effect", the win32text extension is happy again. Differential Revision: https://phab.mercurial-scm.org/D11794
-
Pierre-Yves David authored
In the test we want to trigger a write after the underlying dirstate changed. To do so, we need a write. And as we are about to make dirstate update smarter we need to meddle with the script a bit to make sure there will be a write. Differential Revision: https://phab.mercurial-scm.org/D11793
-
- Nov 23, 2021
-
-
Pierre-Yves David authored
Otherwise the could get size from one version of the file while the on-disk version is still clean but with another size. This fix the previously introduced error. Differential Revision: https://phab.mercurial-scm.org/D11792
-
- Nov 17, 2021
-
-
Pierre-Yves David authored
Gathering information here assume that they are valid cache information for a clean file. It is true most of the time, but not garanteed. Accurate data can still be explicitly provided. We drop the spontaneous and will let the next `hg status` call record actual information. Differential Revision: https://phab.mercurial-scm.org/D11791
-
- Nov 22, 2021
-
-
Pierre-Yves David authored
The current `set_clean` usage is racy (the file might be modified between its restoration and the `set_clean` call). So we simply leave the file as ambiguous and the next status will fix that. We still have to make sure the copy information is dropped, so we teach dirstate how to do that. The win32txt extension is confused after this because current logic is broken in more location. However this series will ultimately fix that so we "ignore" it for now. Fixing it now is complicated without some extra fix landing later. Differential Revision: https://phab.mercurial-scm.org/D11788
-
- Nov 17, 2021
-
-
Pierre-Yves David authored
We will need it during update. Differential Revision: https://phab.mercurial-scm.org/D11783
-
- Oct 25, 2021
-
-
Raphaël Gomès authored
See comment above the changed line, you can get a millions of line of output in case of failure. When don't need to have them all. Differential Revision: https://phab.mercurial-scm.org/D11780
-
- Nov 23, 2021
-
-
Pierre-Yves David authored
For the test to work, we need some mtime to be recorded. For them to be recorded, they need to be "clearly in the past", otherwise edit with the same mtime would be possible. Strictly speaking there might be file system with a minimal mtime increment longer than one second. However it is unlikely that we will run the test on them for now. We can be smarter about this in the future if it becomes necessary. Differential Revision: https://phab.mercurial-scm.org/D11779
-