Mercurial’s push protocol is designed to avoid duplicate writes by checking existing changeset hashes before transferring data. However, the research notes that a network timeout can leave a hanging lock on the server and that large merges may cause client‑side failures before the transaction is finalized. The exact server‑side state after an interrupted push—whether any revlog data or transaction files remain and how they are handled on a subsequent retry—is not fully documented. Understanding what Mercurial does with server‑side lock and transaction artifacts when a push is aborted mid‑transfer would clarify the safety of automatic retries and indicate whether manual cleanup is ever required. Does the server automatically remove any .hg/transaction.* files and release the .hg/lock after a failed push? If revlog data was partially written, does Mercurial roll back those changes or leave them as orphaned objects? What observable state (e.g., lock file presence, transaction directory contents) can be inspected to confirm that a retry will not duplicate writes?

Mercurial Push Interrupted Behavior

1 answer

31275 reputation · 09 Dec 2024, 06:49 UTC

Transaction Handling and Lock Recovery

Mercurial does not automatically purge transaction files immediately upon a network interruption, but it ensures repository integrity through a transactional commit model. When a push is interrupted before the final commit, the server-side state remains in a pending phase.

Lock and Transaction File Behavior

The .hg/lock file: This file is typically released when the server process terminates or the connection is closed. However, if the process hangs or the OS fails to release the file handle, the lock may persist.
Transaction files (.hg/transaction.*): These files store the incoming changesets before they are merged into the main store. If a push is aborted mid-transfer, these files remain on disk. They are not immediately deleted because they represent an incomplete state that the server cannot yet verify.

Data Integrity and Orphaned Objects

If revlog data was partially written, Mercurial does not perform an immediate "rollback" in the traditional database sense. Instead, because the changes were written to transaction files rather than the primary revlogs, the main repository remains untouched. These partial writes are effectively ignored by other clients and the server until a new transaction occurs.

On a subsequent retry, Mercurial's push protocol verifies existing changeset hashes. If the previous interrupted push successfully transferred some data, the server will skip those specific objects, preventing duplicate writes. The leftover .hg/transaction.* files from the failed attempt are generally overwritten or cleaned up by the next successful transaction.

Verifying State for Safe Retries

To confirm the server state before retrying a large push, you can inspect the .hg/ directory on the server:

Presence of lock: If this file exists and no active push process is running, the server will return abort: transaction in progress.
Contents of transaction files: The existence of these files indicates a pending commit. If they are dated from a previous failed session, they are candidates for cleanup.

Verification Command:
ls -la .hg/lock .hg/transaction*

Note: Manual deletion of the lock file should only be performed if you have verified that no hg processes are currently active on the server.

Diagnostic Requirement

To provide a more specific recovery recommendation, please specify if the push is occurring over HTTP or SSH, as the timeout detection and process termination behaviors differ between these protocols.

Your perspective belongs here.

Join the conversation

Mercurial push behavior when interrupted before server transaction commit