Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 30 Jan 2023 18:41:59 +0100] rev 49970
setup: make the version computation process more resistant
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 <matt_harbison@yahoo.com> [Mon, 30 Jan 2023 18:25:11 -0500] rev 49969
bundlerepo: enforce the requirements declared by the underlying repository
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.
Anton Shestakov <av6@dwimlabs.net> [Sat, 28 Jan 2023 18:26:28 +0400] rev 49968
scmutil: make checknewlabel() allow "_" in otherwise numeric names (
issue6737)
Joerg Sonnenberger <joerg@bec.de> [Thu, 29 Apr 2021 22:01:04 +0200] rev 49967
storageutil: match node length with repository
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 12:50:52 +0100] rev 49966
dirstate: enforce holding the lock while doing any changes
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 27 Jan 2023 00:45:07 +0100] rev 49965
largefile: make sure we hold the lock when updating the second dirstate
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 <pierre-yves.david@octobus.net> [Thu, 26 Jan 2023 15:19:39 +0100] rev 49964
dirstate: rename `@requires_no_parents_change` too
This match the rename of the context manager.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 26 Jan 2023 15:17:29 +0100] rev 49963
dirstate: rename `@requires_parents_change` to `@requires_changing_parents`
This match the rename of the context manager.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 12:10:37 +0100] rev 49962
dirstate: write dirstate on successful exit of changing_parents context
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Jan 2023 19:12:31 +0100] rev 49961
dirstate: rename parentchange to changing_parents
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.