- 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
-
- 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‽
-
Pierre-Yves David authored
spoiler: we do…
-
Pierre-Yves David authored
See inline documentation for details. See other changesets for actual cases.
-
- Feb 20, 2023
-
-
Pierre-Yves David authored
Previously, we would miss SystemExit, KeyboardInterrupt etc. This "fix" on the bug tested in "test-largefiles-update.t" by preventing the precisely tested situation to happens at all. However this reveal a similar bug with a different timing. I have not been able to deal with that pre-existing bug so far. So I updated the test to point that out.
-
- Feb 21, 2023
-
-
Pierre-Yves David authored
The behavior around this test is about to change. We update the test to make it more robust and the changes clearer.
-
- Feb 18, 2023
-
-
Pierre-Yves David authored
The test was deleting the log file to start anew. However a trailing working process might still be alive at this time, and recreate the very same log on exit. We see the trace of such worker in the expected content of server.log (see the trace modified by this patch). This is flaky because we don't know *when* the worker will write to the file and there is a race with the `hg init cached` command. A much simpler and reliable way to start anew without having such race is… to write to a different log file. No reuse → no conflict, no conflict → no race, no race → no flakiness.
-
- Jan 27, 2023
-
-
Dan Villiom Podlaski Christiansen authored
-
- Feb 14, 2023
-
-
Matt Harbison authored
It's kinda silly, but a clear error message is better than a stacktrace about subscripting `None` when trying to generate the default commit message. I'm surprised that `.revsingle(..).node()` returns None instead of `nodemod.wdirid`, but now there's a test to catch if this changes.
-
- Feb 16, 2023
-
-
Pierre-Yves David authored
Since the dirstate writes are already managed by the transaction, we already do a backup of the dirstate when necessary (and even trigger one to keep `hg rollback` happy). We needs some special code to deal with the initial empty checkout, but it is not too complicated. Managing variable filename (as dirstate-v2 uses) at the "journalfile" level, is complex and fragile (which is consistent with the fact these files are not journal…). If we no longer do it, our life is significantly simpler. In some sense, we apply the xkcd-1134¹ solution to our savebackup/restorebackup problem. [1] https://xkcd.com/1134/ (the change to test-hardlink are expect as decreasing the number of duplicated backup drive the hardlink count down)
-
Pierre-Yves David authored
The files is on its way out.
-
Pierre-Yves David authored
I now get about 80% of my `test-chg` CI run that fails on flakyness in this tests. It turns out this is only ambiguous status that end up doing file download. So… calling status early will do that potential download separately and the calls we scrutinize during that test will be just fine.
-
- Feb 15, 2023
-
-
Pierre-Yves David authored
Detecting this earlier will help us to affect the rollback process sooner, which will help the next changesets. To keep things simple, we degrade the behavior a bit when the `undo.desc` is missing. However since `hg rollback` is not supposed to be used and the `undo.desc` file have been introduced in mercurial 1.6 (2010). I think this is an acceptable evil.
-
Pierre-Yves David authored
The rollback behavior around `hg commit --addremove` has changed slightly. It does not really matters here but keeping that variant out of the way cannot hurt.
-
Pierre-Yves David authored
This make the situation clearer.
-
Pierre-Yves David authored
That test section is checking that --force is overcoming the safety check, however we did not check that the safety properly detect the situation. We now do for clarity.
-
- Jan 25, 2023
-
-
Pierre-Yves David authored
We need the `wlock` (to add files), the `lock` (to commit), a `transaction` (to commit) and a `changing_files` context (to add files). Strictly speaking, we could let the commit take the `lock` and create a `transaction`, but it seems more consistent that way.
-
Pierre-Yves David authored
This is the way.
-
- Feb 15, 2023
-
-
Pierre-Yves David authored
This was significantly more complicated than I expected, because multiple extensions get in the way. I introduced a context that lazily open the transaction and associated context to work around these complication. See the inline documentation for details. Introducing the wrapping transaction remove the need for dirstate-guard (one of the ultimate goal of all this), and slightly affect the result of a `hg rollback` after a `hg commit --addremove`. That last part is deemed fine. It aligns the behavior with what happens after a failed `hg commit --addremove` and nobody should be using `hg rollback` anyway. The small output change in the test come from the different transaction timing and fact the transaction now backup the dirstate before the addremove, which might mean "no file to backup" when the repository starts from an empty state.
-
- Feb 14, 2023
-
-
Pierre-Yves David authored
This will get in the way when we get more strict about holding the lock when writing the dirstate. Instead, we simply don't copy dirstate files around if there are None at backup time. A couple of tests are impacted they no longer need to backup such "empty" dirstate.
-
Pierre-Yves David authored
If no actual change have been made, we don't really need to roll them back. We only have to cleanup some temporary files and it seems reasonable to do that quietly. This will help us to use the transaction in wider context¹ without impacting the user experience. [1] as in Python context managers that lives longer.
-
Pierre-Yves David authored
Previously, these possibly important callback were "forgotten" when running a quick rollback. This is now fixed, as the tests shown.
-
- Feb 07, 2023
-
-
Pierre-Yves David authored
The previous test was relying on implementation details and harder to maintain. The new version is closer to the initial intend : "What happens if the process die without cleanup". This change is motivated by further changes around the transaction and dirstate logic that would break the fragile equilibrium that existed before this patch. Making this change early make it easier to review on its own and remove noise in future larger changes.
-
Pierre-Yves David authored
The previous test was relying on implementation details and harder to maintain. The new version is closer to the initial intend : "What happens the file get overwritten from under the current process" This change is motivated by further changes around the transaction and dirstate logic that would break the fragile equilibrium that existed before this patch. Making this change early make it easier to review on its own and remove noise in future larger changes.
-
- Feb 13, 2023
-
-
Pierre-Yves David authored
An empty repository, based on `null` is quite a corner cases. We create a more "natural" setup for this tests to make sure it can keep testing what it intend to test in the future.
-
- Feb 07, 2023
-
-
Pierre-Yves David authored
`hg commit -A` will revert the `hg addremove` step if the commit fails. However `hg rollback` currently does not. We are about to improve internal consistency around transaction and dirstate and the behavior of `hg rollback` will align on the other behavior in the process. Before doing so, we make sure the test is using a separate call to `hg add` to avoid the test scenario to be affected by that future change. note: the behavior change for `hg rollback` seems fine as it affect a niche usecase and `hg rollback` usage have been strongly discouraged for a while.
-
- Feb 13, 2023
-
-
Pierre-Yves David authored
`hg commit -A` will revert the `hg addremove` step if the commit fails. However `hg rollback` currently does not. We are about to improve internal consistency around transaction and dirstate and the behavior of `hg rollback` will align on the other behavior in the process. Before doing so, we make sure the test is using a separate call to `hg add` to avoid the test scenario to be affected by that future change. note: the behavior change for `hg rollback` seems fine as it affect a niche usecase and `hg rollback` usage have been strongly discouraged for a while.
-
Pierre-Yves David authored
`hg commit -A` will revert the `hg addremove` step if the commit fails. However `hg rollback` currently does not. We are about to improve internal consistency around transaction and dirstate and the behavior of `hg rollback` will align on the other behavior in the process. Before doing so, we make sure the test is using a separate call to `hg add` to avoid the test scenario to be affected by that future change. note: the behavior change for `hg rollback` seems fine as it affect a niche usecase and `hg rollback` usage have been strongly discouraged for a while.
-
Pierre-Yves David authored
`hg commit -A` will revert the `hg addremove` step if the commit fails. However `hg rollback` currently does not. We are about to improve internal consistency around transaction and dirstate and the behavior of `hg rollback` will align on the other behavior in the process. Before doing so, we make sure the test is using a separate call to `hg add` to avoid the test scenario to be affected by that future change. note: the behavior change for `hg rollback` seems fine as it affect a niche usecase and `hg rollback` usage have been strongly discouraged for a while.
-
- Jan 11, 2023
-
-
Raphaël Gomès authored
This makes it so that `rhg files -r NODE` works properly when using narrow.
-
Raphaël Gomès authored
Support for `rhg files -r NODE` in a future changeset.
-
- Feb 03, 2023
-
-
Pierre-Yves David authored
The previous debug output did not help to understand which file where fixed in which revision. The new output should cover that.
-
Matt Harbison authored
This will allow test dependencies to be installed within a venv, instead of tampering with sys/user sites. One thing to note here is that the `VIRTUAL_ENV` path takes precedence over system-site, unlike when run directly with an activated `venv`. For example, `sys.path` as viewed from a feature test in `hghave.py`, when running `hghave vcr` directly with an activated `venv`: sys.path: [ '/home/jenkins/hg-committed/tests', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/home/jenkins/test_venv/lib/python3.8/site-packages' ] vs `sys.path` from the same feature test, when run by `run-tests.py` with this change: sys.path: [ '/home/jenkins/hg-committed/tests', '/home/jenkins/hg-committed', '/home/jenkins/hg-committed/tests', '/home/jenkins/test_venv/lib/python3.8/site-packages', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/home/jenkins/.local/lib/python3.8/site-packages', '/usr/local/lib/python3.8/dist-packages', '/usr/lib/python3/dist-packages' ]
-
- Jan 31, 2023
-
-
Pierre-Yves David authored
-
- Jan 30, 2023
-
-
Matt Harbison authored
Previously, `hg log -r 'bundle()' -R bundle.hg` was failing for me when run from source, complaining about an unknown parent, when the system installed `hg` didn't. Some debugging showed the index was 0 length. It turned out that I didn't have the C extensions compiled, which a simple `hg log -r .` was able to indicate. The problem being that the RequirementError got handled by RepoError, which uses an empty directory as a fallback to process the bundle.
-