Thu, 02 Mar 2023 11:54:29 +0100 dirstate: deprecate calling `setbranch` without a transaction parameter
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 11:54:29 +0100] rev 50266
dirstate: deprecate calling `setbranch` without a transaction parameter The new way is now enforced.
Thu, 02 Mar 2023 14:46:37 +0100 branch: pass current transaction when writing branch for transaction backup
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 14:46:37 +0100] rev 50265
branch: pass current transaction when writing branch for transaction backup This will requires more change soon (as we can simplify this backup). This will be done in later changesets.
Thu, 02 Mar 2023 14:46:51 +0100 branch: pass current transaction when writing branch in shelve
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 14:46:51 +0100] rev 50264
branch: pass current transaction when writing branch in shelve
Thu, 02 Mar 2023 14:45:39 +0100 branch: pass current transaction when writing branch in import
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 14:45:39 +0100] rev 50263
branch: pass current transaction when writing branch in import
Thu, 02 Mar 2023 14:45:29 +0100 branch: pass current transaction when writing branch in backout command
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 14:45:29 +0100] rev 50262
branch: pass current transaction when writing branch in backout command
Thu, 02 Mar 2023 14:45:21 +0100 branch: pass current transaction when writing branch in branch command
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 14:45:21 +0100] rev 50261
branch: pass current transaction when writing branch in branch command
Thu, 02 Mar 2023 14:44:43 +0100 branch: pass current transaction when writing branch in merge
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 14:44:43 +0100] rev 50260
branch: pass current transaction when writing branch in merge
Thu, 02 Mar 2023 14:44:33 +0100 branch: pass current transaction when writing branch in rebase
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 14:44:33 +0100] rev 50259
branch: pass current transaction when writing branch in rebase
Thu, 02 Mar 2023 14:44:26 +0100 branch: pass current transaction when writing branch in keyword
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 14:44:26 +0100] rev 50258
branch: pass current transaction when writing branch in keyword
Thu, 02 Mar 2023 14:44:17 +0100 branch: pass current transaction when writing branch in histedit
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 14:44:17 +0100] rev 50257
branch: pass current transaction when writing branch in histedit
Thu, 02 Mar 2023 11:47:18 +0100 dirstate: write the `branch` as part of the transaction if any
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 11:47:18 +0100] rev 50256
dirstate: write the `branch` as part of the transaction if any Bypassing the transaction means we could get out of sync with the dirstatemap content. The branch is stil written right away if no transaction is around, but at least it no longer bypass the transaction. Actual caller of this still need to be updated.
Thu, 02 Mar 2023 11:46:51 +0100 dirstate: factor the transaction abort logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 11:46:51 +0100] rev 50255
dirstate: factor the transaction abort logic We will need it in more occasion if the branch is to be written as part of the transaction.
Thu, 02 Mar 2023 14:50:17 +0100 dirstate: use a context manager to handle the file used for writing the branch
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 14:50:17 +0100] rev 50254
dirstate: use a context manager to handle the file used for writing the branch This is more modern.
Thu, 02 Mar 2023 11:54:21 +0100 style: rewrap `ui.deprecwarn` declaration
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 11:54:21 +0100] rev 50253
style: rewrap `ui.deprecwarn` declaration This get easier to read, especially with the type annotation.
Thu, 02 Mar 2023 19:02:52 +0100 branching: merge stable into default
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 19:02:52 +0100] rev 50252
branching: merge stable into default The clippy god had to be appeased on some aspect.
Thu, 02 Mar 2023 15:21:36 +0100 Added signature for changeset 8830004967ad stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 02 Mar 2023 15:21:36 +0100] rev 50251
Added signature for changeset 8830004967ad
Thu, 02 Mar 2023 15:21:23 +0100 Added tag 6.3.3 for changeset 8830004967ad stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 02 Mar 2023 15:21:23 +0100] rev 50250
Added tag 6.3.3 for changeset 8830004967ad
Thu, 02 Mar 2023 15:07:47 +0100 relnotes: add 6.3.3 stable 6.3.3
Raphaël Gomès <rgomes@octobus.net> [Thu, 02 Mar 2023 15:07:47 +0100] rev 50249
relnotes: add 6.3.3
Thu, 02 Mar 2023 04:16:47 +0100 narrow: read pending file when applicable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 Mar 2023 04:16:47 +0100] rev 50248
narrow: read pending file when applicable Now that this is part of the transaction, this is necessary to make sure we read the right data in hooks (if any).
Tue, 28 Feb 2023 16:42:38 -0500 typing: add typehints to mercurial/diffutil.py stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Feb 2023 16:42:38 -0500] rev 50247
typing: add typehints to mercurial/diffutil.py Lack of typehints here caused the fact that TortoiseHg was passing str instead of bytes as the key in `opts` to be missed, resulting in shelf corruption in cases where `diff.git` is required.
Tue, 28 Feb 2023 18:14:11 -0500 patchbomb: respect the `--git` option stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Feb 2023 18:14:11 -0500] rev 50246
patchbomb: respect the `--git` option 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.
Wed, 01 Mar 2023 16:48:09 +0100 rhg: remember the inode of .hg/dirstate stable
Raphaël Gomès <rgomes@octobus.net> [Wed, 01 Mar 2023 16:48:09 +0100] rev 50245
rhg: remember the inode of .hg/dirstate 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.
Tue, 28 Feb 2023 17:58:15 +0100 rust-dirstate-v2: don't write dirstate if data file has changed stable
Raphaël Gomès <rgomes@octobus.net> [Tue, 28 Feb 2023 17:58:15 +0100] rev 50244
rust-dirstate-v2: don't write dirstate if data file has changed 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.
Mon, 12 Dec 2022 17:08:12 +0100 rust-dirstate: remember the data file uuid dirstate was loaded with stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 12 Dec 2022 17:08:12 +0100] rev 50243
rust-dirstate: remember the data file uuid dirstate was loaded with This will be used in the next patch to fix a race condition.
Wed, 01 Mar 2023 02:38:20 +0100 dirstate: set identity whenever we read the dirstate's v2 docket stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 01 Mar 2023 02:38:20 +0100] rev 50242
dirstate: set identity whenever we read the dirstate's v2 docket The docket can be loaded outside of a full read (for exemple when pre-fetching parents), so the current code would read/set the identity after loading the data, opening a race condition: A0: first process docket is read B0: other process appends new data to the dirstate (and changes the docket) A1: first process sets the identity (based on pre-B content, but with post-B identity) A1: first process loads the dirstatemap from the data file A1: first process does not detect the race and overwrites the update from B.
Tue, 21 Feb 2023 15:10:12 +0100 dirstate: factor the identity setting code in the dirstate map stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 15:10:12 +0100] rev 50241
dirstate: factor the identity setting code in the dirstate map We need it in more locations, so let us start factoring thing out first to make sure the same code is called everywhere. This bears some similarity with 85746485a4dd on default, but at a smaller scope and for a different purpose.
Wed, 01 Mar 2023 00:07:26 +0100 dirstate: simplify the dirstate's read race testing stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 01 Mar 2023 00:07:26 +0100] rev 50240
dirstate: simplify the dirstate's read race testing Now that most code behaves properly, we can simplify the expected matching.
Tue, 28 Feb 2023 19:36:46 +0100 dirstate: deal with read-race for pure rust code path (rhg) stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 28 Feb 2023 19:36:46 +0100] rev 50239
dirstate: deal with read-race for pure rust code path (rhg) 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.
Tue, 28 Feb 2023 23:35:52 +0100 dirstate: deal with read-race for python code using rust object stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 28 Feb 2023 23:35:52 +0100] rev 50238
dirstate: deal with read-race for python code using rust object 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.
Tue, 28 Feb 2023 19:01:20 +0100 dirstate: deal with read-race for pure python code stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 28 Feb 2023 19:01:20 +0100] rev 50237
dirstate: deal with read-race for pure python code 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.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 tip