- 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.
-
Raphaël Gomès authored
This allows the callers to use any error type that converts to `CommandError` instead of a particular concrete type.
-
- Jan 12, 2023
-
-
Raphaël Gomès authored
-
- Jan 11, 2023
-
-
Raphaël Gomès authored
This will be used elsewhere in the code, starting from the next commit.
-
Raphaël Gomès authored
The `files` logic predates the centralized dirstate logic. It was duplicated, an didn't receive bugfixes along the way.
-
Raphaël Gomès authored
This is a useful general-purpose function. It will be used in the next changesets.
-
Raphaël Gomès authored
-
- Feb 03, 2023
-
-
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 30, 2023
-
-
Matt Harbison authored
I'm pretty sure that this was the intention, given `error.LookupError` is raised a few lines above with the same arguments. Note that PyCharm complains about `self.display_id` (and the use above this too) being `() -> Any` instead of `bytes`, but it may be confused about the `util.propertycache` annotation on it.
-
Matt Harbison authored
Not sure how/when these skewed, but these were flagged by PyCharm as having different signatures.
-
- Jan 31, 2023
-
-
Pierre-Yves David authored
-
- Jan 30, 2023
-
-
Pierre-Yves David authored
Choking on Mercurial's stderr mean armless warning can derails the whole install process. We do like to be able to issue warning to people so we stop considering any stderr is a fatal mistake. This allow us to actually boostrap a version of Mercurial without loosing to many sanity point. For example in case where evolve is not loaded, something that happens when the recorded version is malformatted. Creating a wonderful ouroboros.
-
Pierre-Yves David authored
The tag fetching might return and empty string¹, from there everything derails quickly. As setup tools becomes more picky about version format we make the whole seems a bit more robust. The resulting version will be obviously weird, but at least it will actually install itself. [1] This is a problem we will address in the next changesets.
-
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.
-
- Jan 28, 2023
-
-
Anton Shestakov authored
-
- Apr 29, 2021
-
-
Jörg Sonnenberger authored
-
- Dec 13, 2022
-
-
Pierre-Yves David authored
This seems like a sensible sanity check. This already caught the issue in largefile. This will catch more issue when we start using similar context manager for operation other than the parent changes.
-
- Jan 26, 2023
-
-
Pierre-Yves David authored
The largefile extension uses a second dirstate file (and object) to track some states. In some situations, it is lazily updated when needed. These operations might not have the lock taken. This means they might conflict and race with other ongoing operations. So we now take the lock to do these operations. This was caught by the next commit.
-
Pierre-Yves David authored
This match the rename of the context manager.
-
Pierre-Yves David authored
This match the rename of the context manager.
-
- Dec 13, 2022
-
-
Pierre-Yves David authored
This is the first step toward having more sensible and predicatable write patterns for the dirstate. Having better write/rollback patterns will greatly reduce and clarify the needs to backup the dirstate.
-
- Jan 25, 2023
-
-
Pierre-Yves David authored
Since the new argument breaks the API anyway, we can rename it to a better name. The previous name `parentchange` might be seen as something active, a function that would directly change the parents, however this is just a context manager to frame the operation that will change the parents and adjust the dirstate content accordingly. In addition, the future sister method that will be about changes to tracking and files would have a hard time fitting in the same naming scheme in a clear way. The new naming uses a clear prefix will make it more distinct from other dirstate methods and easier to extend with other similar contexts.
-
Pierre-Yves David authored
If we want the context to be responsible for writing (and we want it), we need to have access to a localrepository object. So we now requires a localrepository object as an argument to this context manager.
-
- Dec 13, 2022
-
-
Pierre-Yves David authored
Now that the invalidation is dealt with by the context manager itself, we should no longer need this in the unlocking code. We start with issuing a warning if this is the case before actually dropping this code later.
-
Pierre-Yves David authored
When an error occurs during changing parents, we should invalidate all dirstate modifications and reload the dirstate. This is currently done by a `unlock` callback on the `wlock`. To fix this anomaly, we start dealing with the error directly in the context manager and its potential nesting. The "hard" part is to make sure that, when the parent-change context are nested, we and higher level nesting do not continue to use the invalidated dirstate. We introduce dedicated code to enforce that.
-
- Jan 28, 2023
-
-
Cédric Krier authored
When the rust extension is the first to be build, the target directory may not exist so the copy fails.
-
- Jan 25, 2023
-
-
Cédric Krier authored
See inline documentation for details.
-
- Jan 09, 2023
-
-
Raphaël Gomès authored
This was caught by `clippy`. I guess the narrow tests leave something to be desired, since this previously only checked the first valid pattern.
-
- Jan 12, 2023
-
-
Raphaël Gomès authored
Just a little cleanup of a TODO found along the way.
-
- Jan 25, 2023
-
-
Anton Shestakov authored
-
Anton Shestakov authored
There are 3 of them, and them all having the same name triggered code checkers.
-
Anton Shestakov authored
-
Anton Shestakov authored
This .t file was failing for me when running run-tests.py with python3.11. Then I tried to run it with python3.10 and it failed anyway, even though it's the default python3 interpreter. But with `python3 ./run-tests.py` it worked fine. And this is what I found while looking at the way pygments lexer checks if a file without extension is likely to be a python script: shebang_matches(text, r'pythonw?(3(\.\d)?)?') Take guess why it doesn't work for python >= 3.10. To work around this issue, we can simply hardcode an "easier" shebang for pygments. This path to python interpreter obviously doesn't need to be accurate, since we're not running this script.
-
Raphaël Gomès authored
So far, only errors would trip the CI, this makes it so all warnings are elevated to errors, making it a CI fail if any warnings are present. This was the intended behavior, I just missed this when adding clippy.
-
Raphaël Gomès authored
-