Question
hg rollback leaves .hg/requires unchanged after storage-format migration
Mira Finch
0 reputation · 07 Mar 2024, 02:26 UTC
97.4K views1
Loading…
0 reputation · 07 Mar 2024, 02:26 UTC
The goal is to determine whether hg rollback should abort or adjust repository format requirements when the on-disk storage schema changed after the transaction being undone.
Mercurial rollback undoes only the most recent repository transaction and does not validate or downgrade entries in .hg/requires. If a storage-format upgrade modified repository requirements after the transaction, rolling back that transaction may leave the store incompatible with older clients or inconsistent with the current format. Mercurial has no built-in flag that automatically aborts rollback when schema requirements changed since the transaction.
Assumptions: behavior applies to standard Mercurial releases using transactional undo storage. Exact undo storage location and warnings may differ across versions, so behavior should be confirmed with the installed binary before relying on it.
Should hg rollback compare current .hg/requires against the requirements recorded when the transaction was created? Should rollback abort automatically if a storage-format migration changed repository requirements after the target transaction? Is there a supported way to detect schema incompatibility before executing rollback?
35275 reputation · 07 Mar 2024, 06:58 UTC
No. hg rollback does not compare the current .hg/requires against the requirements recorded when the target transaction was created, and Mercurial has no flag to abort rollback automatically when a storage-format migration changed requirements after that transaction. Rollback replays the undo journal for the single most recent transaction only; it does not recompute or downgrade repository format requirements.
A format upgrade, such as hg upgrade or an automatic store migration, writes new entries to .hg/requires and .hg/store/requires. If that write happens outside the transaction being undone, or as its own transaction, rolling back the later transaction restores data files but leaves the newer requirement entries in place. Newer clients can still open the repository, while older clients fail with an unsupported-requirement error.
| Behavior | Status |
|---|---|
hg rollback undoes only the most recent transaction | Well-established |
Rollback validates or downgrades .hg/requires | Not supported |
| Automatic abort on post-transaction format change | No built-in flag |
| Exact undo location and warnings | Varies by Mercurial release |
Check hg version and hg help rollback on the installed binary before relying on this behavior.
mercurial.hg/requires and .hg/store/requires, and run hg debugrequirements if available.hg verify before rollback and save the output.hg rollback only in the disposable copy.hg verify again.Do not delete or edit entries in .hg/requires to force an older format. Mercurial has no supported downgrade path; re-clone with an older client or upgrade the clients instead.
Provide the output of hg version, and note whether the format upgrade committed as a separate transaction from the change you want to undo. That determines whether rollback can touch the requirements file in your release.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.