Mon, 26 Feb 2024 12:59:57 +0100 rust-index: drop offset_override
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 12:59:57 +0100] rev 51513
rust-index: drop offset_override The inline `offsets` value diverge from the one on disk for added value, so the offset_override tricks is not going to work well once we start having the full revlog logic in Rust. We remove it beforehand and align the Rust logic to the Python one (adjusting the segment offset at read time for inline revlog).
Mon, 26 Feb 2024 13:41:02 +0100 rust-index: stop calling `with_offset` in the tests
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 13:41:02 +0100] rev 51512
rust-index: stop calling `with_offset` in the tests We are not adding any data, so why are we setting any offset?
Fri, 23 Feb 2024 15:57:50 +0100 branching: merge stable into default
Raphaël Gomès <rgomes@octobus.net> [Fri, 23 Feb 2024 15:57:50 +0100] rev 51511
branching: merge stable into default
Thu, 13 Jun 2024 09:52:39 +0200 test: better glob some timing related line to avoid flakiness stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 13 Jun 2024 09:52:39 +0200] rev 51510
test: better glob some timing related line to avoid flakiness If we go over 10 seconds, the number of white space changes.
Wed, 12 Jun 2024 11:27:01 +0200 Added signature for changeset a1a011d4b148 stable
Raphaël Gomès <rgomes@octobus.net> [Wed, 12 Jun 2024 11:27:01 +0200] rev 51509
Added signature for changeset a1a011d4b148
Wed, 12 Jun 2024 11:26:57 +0200 Added tag 6.7.4 for changeset a1a011d4b148 stable
Raphaël Gomès <rgomes@octobus.net> [Wed, 12 Jun 2024 11:26:57 +0200] rev 51508
Added tag 6.7.4 for changeset a1a011d4b148
Wed, 12 Jun 2024 11:25:49 +0200 relnotes: add 6.7.4 and warn about 6.7.{1,2,3} stable 6.7.4
Raphaël Gomès <rgomes@octobus.net> [Wed, 12 Jun 2024 11:25:49 +0200] rev 51507
relnotes: add 6.7.4 and warn about 6.7.{1,2,3}
Wed, 12 Jun 2024 02:16:14 +0200 inline-changelog: fix pending transaction visibility when splitting stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 12 Jun 2024 02:16:14 +0200] rev 51506
inline-changelog: fix pending transaction visibility when splitting We move the name back to the expected name of `changelog.i.a`.
Wed, 12 Jun 2024 02:15:20 +0200 inline-changelog: fix a critical bug in write_pending that delete data stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 12 Jun 2024 02:15:20 +0200] rev 51505
inline-changelog: fix a critical bug in write_pending that delete data Since a93e52f0b6ff we no longer use inline-revlog for the changelog. The goal there was to solve the lack of testing for the two variants (inline vs split) and reduce the complexity of the interaction with "diverted-write" on the changelog level. However many existing repository still have inline-changelog and we automatically move them to normal revlog as soon as we have the chances. Unfortunately This conversion is buggy and can result in the destruction of the changelog.i if hook triggers the "write pending" mechanism. The bugs comes from the "revlog splitting" logic and the "write_pending" logic stepping over each other. Ironically the change in a93e52f0b6ff aims at no longer having this kind of problem. This changesets fix this issue and add associated tests. Fixing this reveal that the transaction hooks end up not seeing the pending transaction content, because the name is not right ("changelog.i.s.a" instead of "changelog.i.s") we fix this in the next changeset.
Tue, 11 Jun 2024 03:05:20 +0200 bookmark: fix remote bookmark deletion when the push is raced stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 11 Jun 2024 03:05:20 +0200] rev 51504
bookmark: fix remote bookmark deletion when the push is raced Before this patch, running `hg push -B book` to push the `book` bookmark sideway at the same time as a commit making it moving forward might result in the removal of the bookmark remotely. After this changeset, the push can still be raced, but to remove deletion happens. This is progress.
Tue, 11 Jun 2024 03:03:47 +0200 hooks: add a prewlock and a prelock hooks stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 11 Jun 2024 03:03:47 +0200] rev 51503
hooks: add a prewlock and a prelock hooks This is useful for testing.
Tue, 11 Jun 2024 11:14:13 +0200 exchange: fix locking to actually be scoped stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 11 Jun 2024 11:14:13 +0200] rev 51502
exchange: fix locking to actually be scoped The previous code was taking locks before entering with statements, so exception before the with statement would not release the lock (except for garbage collection). We need to move to a try except here because the logic is more complicated.
Tue, 11 Jun 2024 11:13:36 +0200 exchange: fix locking to actually be scoped stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 11 Jun 2024 11:13:36 +0200] rev 51501
exchange: fix locking to actually be scoped The previous code was taking locks before entering with statements, so exception before the with statement would not release the lock (except for garbage collection).
Mon, 10 Jun 2024 10:59:44 +0200 rust-status: sort the failed matches when printing them stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 10 Jun 2024 10:59:44 +0200] rev 51500
rust-status: sort the failed matches when printing them This was making the tests flaky after the recent patch¹ that opened up more of the code to the Rust-augmented status. [1] 865efc020c3355dca1cbaa35db80600009c01dd5
Tue, 07 May 2024 15:15:41 +0400 chistedit: change action for the correct item stable
Anton Shestakov <av6@dwimlabs.net> [Tue, 07 May 2024 15:15:41 +0400] rev 51499
chistedit: change action for the correct item We have an experimental config histedit.later-commits-first from c820866c52f9, and when it's true, the order of commits in histedit UI is reversed, both in text mode and in curses mode. But before this patch key presses in curses mode would change histedit actions in the same old order, i.e. trying to edit the latest commit (which would be first now) would put "edit" action on the last commit in the list. This wasn't a cosmetic issue, histedit would actually proceed to edit the first commit in the list. Let's map rules to display items (hopefully now correctly).
Mon, 06 May 2024 18:48:37 +0200 Added signature for changeset 028dc3f92dbd stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 18:48:37 +0200] rev 51498
Added signature for changeset 028dc3f92dbd
Mon, 06 May 2024 18:48:34 +0200 Added tag 6.7.3 for changeset 028dc3f92dbd stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 18:48:34 +0200] rev 51497
Added tag 6.7.3 for changeset 028dc3f92dbd
Mon, 06 May 2024 17:51:21 +0200 relnotes: add 6.7.3 stable 6.7.3
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 17:51:21 +0200] rev 51496
relnotes: add 6.7.3
Mon, 22 Apr 2024 19:47:08 +0200 rust: blanket implementation of Graph for Graph references stable
Georges Racinet <georges.racinet@octobus.net> [Mon, 22 Apr 2024 19:47:08 +0200] rev 51495
rust: blanket implementation of Graph for Graph references The need comes from the fact that `AncestorsIterator` and many Graph-related algorithms take ownership of the `Graph` they work with. This, in turn is due to them needing to accept the `Index` instances that are provided by the Python layers (that neither rhg nor `RHGitaly` use, of course): the fact that nowadays the Python layer holds an object that is itself implemented in Rust does not change the core problem that they cannot be tracked by the borrow checker. Even though it looks like cloning `Changelog` would be cheap, it seems hard to guarantee that on the long run. The object is already too rich for us to be comfortable with it, when using references is the most natural and guaranteed way of proceeding. The added test seems a bit superfleous, but it will act as a reminder that this feature is really useful until something in the Mercurial code base actually uses it.
Mon, 06 May 2024 15:30:21 +0200 rust-cpython: don't swallow the dirstate error message stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 15:30:21 +0200] rev 51494
rust-cpython: don't swallow the dirstate error message In case we do get a dirstate error, we want to get the full error message and not just an opaque `Dirstate error`.
Mon, 06 May 2024 13:07:02 +0200 dirstate-v2: check that root nodes are at the root before writing stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 13:07:02 +0200] rev 51493
dirstate-v2: check that root nodes are at the root before writing More explanations in the previous changeset.
Mon, 06 May 2024 13:02:52 +0200 dirstate-v2: add check of parent/child nodes being related when writing stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 13:02:52 +0200] rev 51492
dirstate-v2: add check of parent/child nodes being related when writing This stems from a corruption seen in a private repository. We're not sure of the source of the corruption, and it's very possible that we're seeing compounded effects of multiple writes on a corrupted dirstate. Adding this check is not expensive in itself and large writes of the dirstate are not common. This change does not catch this problem at the root node, the next one will.
Mon, 06 May 2024 16:29:00 +0200 admin-verify: expect a number of errors to be returned stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 16:29:00 +0200] rev 51491
admin-verify: expect a number of errors to be returned It's the responsibility of the check to handle errors, we only care about the total count to sum up the check's work. We use `admin::verify -c dirstate` to test this path at least somewhat.
Mon, 06 May 2024 16:16:15 +0200 admin-verify: fix error message handling stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 16:16:15 +0200] rev 51490
admin-verify: fix error message handling `dirstate.verify` used to return tuples but does not anymore, it returns the pre-formatted error message, which is a nicer interface anyway.
Mon, 06 May 2024 12:31:29 +0200 admin-verify: pass p1 down to the dirstate function stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 12:31:29 +0200] rev 51489
admin-verify: pass p1 down to the dirstate function This was forgotten and can break with certain kinds of corruption.
Mon, 06 May 2024 11:27:29 +0200 Backed out changeset 3e0f86f09f26 stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 11:27:29 +0200] rev 51488
Backed out changeset 3e0f86f09f26
Mon, 06 May 2024 11:26:52 +0200 Backed out changeset fc317bd5b637 stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 11:26:52 +0200] rev 51487
Backed out changeset fc317bd5b637
Thu, 02 May 2024 02:20:42 +0200 re2: make errors quiet stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 May 2024 02:20:42 +0200] rev 51486
re2: make errors quiet By default, the re2 library will output error on its own instead of keeping the error in an exception. This make re2 printing spurious error before fallback to the stdlib remodule that may accept the pattern or also fails to parse it and raise a proper error that will be handled by Mercurial. So we also pass an Option object that changes this default.
Thu, 02 May 2024 08:46:58 +0200 fold-or-prune-me: update proposal stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 May 2024 08:46:58 +0200] rev 51485
fold-or-prune-me: update proposal This does the same things but with a narrower wrapping.
Sun, 31 Mar 2024 17:57:46 -0300 subrepo: propagate non-default path on outgoing stable
Felipe Resende <felipe@fcresende.dev.br> [Sun, 31 Mar 2024 17:57:46 -0300] rev 51484
subrepo: propagate non-default path on outgoing There was already a fix made in 5dbff89cf107 for pull and push commands. I did the same for the outgoing command. The problem I identified is that when the parent repository has multiple paths, the outgoing command was not respecting the parent path used and was always using the default path for subrepositories.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 tip