Thu, 23 Feb 2023 19:07:58 +0100 bundlerepo: handle changegroup induced phase movement in the associated method
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 19:07:58 +0100] rev 50199
bundlerepo: handle changegroup induced phase movement in the associated method These movement comes from handling the changegroup part, so we keeps the code grouped. This will be important when handling more part (and more changegroup part in the future) This induce a small code duplication, but it does not looks terrible.
Thu, 23 Feb 2023 19:06:24 +0100 bundlerepo: move most attribute declaration earlier in __init__
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 19:06:24 +0100] rev 50198
bundlerepo: move most attribute declaration earlier in __init__ The expected attribute are clearer this way. The bundle handling code is responsible for setting most of it.
Thu, 23 Feb 2023 19:04:44 +0100 bundlerepo: move the handling of bundl1 in its own method
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 19:04:44 +0100] rev 50197
bundlerepo: move the handling of bundl1 in its own method This should make the overall flow simpler to follow.
Thu, 23 Feb 2023 19:02:01 +0100 bundlerepo: expliclty handing cg part from bundle2
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 19:02:01 +0100] rev 50196
bundlerepo: expliclty handing cg part from bundle2 We will handle other types of parts soon (phase-heads) so we need some cleanup first.
Thu, 23 Feb 2023 15:37:46 +0100 transaction: use the standard transaction mechanism to backup branch
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 15:37:46 +0100] rev 50195
transaction: use the standard transaction mechanism to backup branch Branch is a bit special : - It currently does not collaborate with the transaction (or any scoping) for writing (this is bad) - It can change without the lock being taken (it is protected by `wlock`) So we rely on the same mechanism as for the backup of the other dirstate file: - we only do a backup if we hold the wlock - we force a backup though the transaction Since "branch" write does not collaborate with the transaction, we cannot back it up "at the last minute" as we do for the dirstate. We have to back it up "upfront". Since we have a backup, the transaction is no longer doing its "quick_abort" and get noisy. Which is quite annoying. To work around this, and to avoid jumping in yet-another-rabbit-hole of "getting branch written properly", I am doing horrible things to the transaction in the meantime. We should be able to get this code go away during the next cycle. In the meantime, I prefer to take this small stop so that we stop abusing the "journal" and "undo" mechanism instead of the proper backup mechanism of the transaction. Also note that this change regress the warning message for the legacy fallback introduced in 2008 when issue902 got fixed in dd5a501cb97f (Mercurial 1.0). I feel like this is fine as issue 902 remains fixed, and this would only affect people deploying a mix of 15 year old Mercurial and modern mercurial, and using branch and rollback extensively.
Thu, 23 Feb 2023 04:53:34 +0100 transaction: no longer explicitly cache bookmarks
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 04:53:34 +0100] rev 50194
transaction: no longer explicitly cache bookmarks The transaction file generation is already dealing with the backup for this. So, no need to duplicate such backup.
Wed, 22 Feb 2023 18:58:02 +0100 transaction: no longer explicitly cache phaseroots
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 18:58:02 +0100] rev 50193
transaction: no longer explicitly cache phaseroots The transaction file generation is already dealing with the backup for this. So, no need to duplicate such backup.
Thu, 23 Feb 2023 04:28:24 +0100 narrow: enforce that narrow spec is written within a transaction
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 04:28:24 +0100] rev 50192
narrow: enforce that narrow spec is written within a transaction
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 tip