Reverting to Old Versions in Mercurial: A Practical Guide to Continuing Development from Historical Points

Core Requirements and Scenario Analysis for Version Reversion

In software development, developers frequently encounter situations where they need to abandon current work directions and revert to earlier versions. As described in the user scenario, the project history was originally linear, but changes from revision 38 to 45 proved unworkable, necessitating a return to revision 38 for a fresh start. The primary objectives in such cases are: restoring the working copy to revision 38's state, ensuring subsequent commits have revision 38 as their parent, and properly handling the legacy of revisions 39-45.

Semantic Differences and Selection Criteria for Mercurial Commands

Mercurial provides multiple commands involving version switching and state management, with crucial semantic distinctions:

• hg update (or hg up) changes both the working copy's parent revision and file content, making subsequent commits continue from the target revision. This represents the most direct method of branch creation.
• hg revert changes only file content without altering the working copy's parent revision, typically used to discard uncommitted changes. When combined with the --rev parameter, it can create new commits matching an older version's state.
• hg branch creates named branches, labeling subsequent changesets for workflow organization in team collaborations, but may be overly complex for simple reversion scenarios.

Method 1: Creating Explicit Branches with hg update

Following the best answer's guidance, executing hg update -r 38 (or hg update --rev 38) provides the most straightforward solution. This command switches the working copy to revision 38, updating file content accordingly. Revisions 39-45 then become "dangling heads"—branch endpoints without subsequent commits.

# Switch to revision 38
hg update -r 38
# Verify current state
hg log -l 1
# Begin new development work and commit
# ... modify files ...
hg commit -m "New implementation restarting from revision 38"

This approach creates explicit history forking: two branch lines emerge after revision 38—one containing the abandoned revisions 39-45, and another with new commits restarting from revision 38. When pushing to a remote repository, Mercurial warns about "multiple heads," as this structure suggests potential merge needs. If maintaining this forked state is intentional, hg push --force can enforce the push.

Method 2: Creating New Commits with hg revert

As a supplementary approach, hg revert --all --rev 38 followed by a commit achieves similar results. This command restores all files in the working copy to revision 38's state while keeping the parent revision as the current version (45). A subsequent commit creates a new revision (e.g., revision 46) identical in content to revision 38.

# Restore files to revision 38's state
hg revert --all --rev 38
# Commit the restored state
hg commit -m "Restored to revision 38's state"
# Continue development
# ... modify files ...
hg commit -m "New implementation based on restored state"

This method avoids explicit history forking by "overwriting" old states with new commits. Advantages include no warnings about multiple heads, making it more suitable for collaboration scenarios where revision 39-45 has already been shared. The drawback is historical inclusion of seemingly duplicate state commits.

Method 3: Isolating History Through Cloning

For scenarios requiring complete isolation from old history, create a new clone containing only up to revision 38: hg clone --rev 38 original-repo new-repo. This generates an independent working copy where revisions 39-45 do not exist. Development can continue in the new clone, with multiple repository copies managed through renaming.

# Create new clone with history only up to revision 38
hg clone --rev 38 project project-new
# Change to new clone directory
cd project-new
# Verify history range
hg log --graph
# Continue development in the new clone

This approach most thoroughly separates old and new work but requires managing multiple repository copies, potentially increasing complexity.

Practical Recommendations and Decision Factors

Method selection depends on specific requirements:

• If clear historical branching points are desired and multiple head warnings are acceptable, hg update is optimal.
• If collaborating with others who may have based work on revision 45, hg revert followed by commit is more appropriate, avoiding force pushes.
• If completely discarding revisions 39-45 is preferred and managing multiple clones is acceptable, cloning provides the cleanest separation.

Regardless of method, it's advisable to verify working copy status with hg status and hg diff before execution, using hg stash if necessary to temporarily store uncommitted changes. For already pushed changes, consider impacts on collaborators, potentially requiring communication and coordination.