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.
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.
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.
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 04:42:17 +0100] rev 50191
narrow: write the narrow spec in a transaction during share
It will be simpler if all write happens within transaction.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 04:36:19 +0100] rev 50190
narrow: open the transaction sooner when unbundling
That way, the narrow spec changes will be done within a transaction.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 04:35:16 +0100] rev 50189
narrow: write the narrow spec in a transaction during clone
It will be simpler if all write happens within transaction.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 03:28:44 +0100] rev 50188
narrow: drop the dedicated backup code
Now that the transaction manage the writes, we can simply use the transaction for backup.
Some extra cleanup to ensure all changes happens within a transaction will be
made in the next changesets.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 03:25:44 +0100] rev 50187
narrow: delegate the dirstate's narrow spec writing to the transaction
This make it more transactional and will help us to simplify their backup.
The implementation is not great, but it keep the patch simple as this is not the
time for a larger refactoring yet.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 04:15:16 +0100] rev 50186
narrow: delegate the narrow spec writing to the transaction
This make it more transactional and will help us to simplify their backup.
The implementation is not great, but it keep the patch simple as this is not the
time for a larger refactoring yet.