transaction: actually delete file created during the transaction on rollback
Transaction currently has two modes:
- one where file created during the transaction are deleted on rollback,
- one where file created during the transaction are truncated to 0 on rollback.
Before this change, `hg rollback` and `hg recover` are using the "delete" mode
and transaction abort is using the "truncate" option. This difference is never
really explained. A long time ago, there was two code paths, with this
divergence existing for unclear reasons. When the two code paths got merged into
a single one, a boolean argument have been added to preserve this divergence,
mostly probably as a cargo cult.
The divergence is weird and induce bad surprises, and the truncate behavior is a
bit odds, introducing other bad surprises (e.g.
08ecbdba186f)
So solve this, we stop using the "truncate" behavior and unify on the "delete"
behavior. Despite being currently more "common", the truncate behavior seems
less natural, resulting in the transaction leaving empty file around.
This is landed on default, early in the cycle, to help us catch problems that
could emerge.
--- a/mercurial/transaction.py Fri Jul 28 17:08:37 2023 +0100
+++ b/mercurial/transaction.py Mon Jul 24 05:13:52 2023 +0200
@@ -867,7 +867,7 @@
self._vfsmap,
entries,
self._backupentries,
- False,
+ unlink=True,
checkambigfiles=self._checkambigfiles,
)
self._report(_(b"rollback completed\n"))
--- a/tests/test-transaction-rollback-on-revlog-split.t Fri Jul 28 17:08:37 2023 +0100
+++ b/tests/test-transaction-rollback-on-revlog-split.t Mon Jul 24 05:13:52 2023 +0200
@@ -396,7 +396,6 @@
The split was rollback
$ f -s .hg/store/data*/file*
- .hg/store/data/file.d: size=0
.hg/store/data/file.i: size=1174