Transaction Plan

Improving transactionality of Modern Mercurial

1. Current Situation

The current transaction implementation focus on the ability to rollback on disk data in case of failure. All other aspects of transaction (data visibility, hook scheduling, cache validity, etc.) are handled locally by other logics. The lack of vision on the actual live spawn of the transaction in each of these location makes it difficult to behave correctly.

We plan to expand the responsibility and API of the transaction to handle all these cases properly.

2. List of current issue

(non-exhaustive)

• Nested transaction expose new changelog too early,
• new obsstore content is exposed too early,
• no "pending" mechanism for obsstore (append only file),
• no "pending" mechanism for phases and bookmarks (full content generation files),
• new cache values (branchmap, tagcache, …) are written too early,
• new cache values are not rollbacked with the transaction,
• scheduled post transaction hook (commit, changegroup, …) are still executed even if the nested transaction fails.
• File are not updated atomically on disk

3. Steps

1. implement API on transaction to handle event related to:

   • - pending: flushing pending-changes for hooks

     - finalize: writing new data to conclude the transaction

     - postclose: perform all actions that need to be done on the transaction is successfully closed.

2. Allow the transaction to backup, rollback, and generate files outside of .hg/store/. This is necessary to handle, bookmark, dirstate and various caches.
3. Add pending handling to relevant file (obsstore, bookmark, phases, etc)
4. provide an upgraded repository format that allow consistent view of all files involved in the repository and atomic update of them (cf sprint note)