Mercurial is quickly fading from popularity. And many are looking for an alternative. That's why we break down Mercurial vs. Perforce P4 (formerly Helix Core) in this blog. We also share a Mercurial cheat sheet including Mercurial commands — and how they compare to Perforce P4 commands.
Table of Contents
- Mercurial vs Perforce
- Mercurial Commands: hg Commands vs. p4 Commands
- Migrate from Mercurial to Perforce P4
➡️ Easily Migrate From Mercurial
Mercurial vs Perforce
Mercurial is a distributed version control system. Perforce P4 is a centralized version control system. Many Mercurial teams migrate to P4 instead of Git.
Longevity
Mercurial's popularity is faded. And many version control systems have discontinued Mercurial support, such as Bitbucket. Others have considered Mercurial vs. Git, as well as Mercurial vs. Perforce.
Migrating to P4 is a wise choice for Mercurial users. See for yourself why Mercurial teams switch to P4. Try it free for up to 5 users and 20 workspaces.
Handling Work-In-Progress
The main difference is that while Mercurial includes modifications automatically, but Perforce P4 does not.
P4 maintains all work-in-progress via a concept known as a changelist, and in particular your work-in-progress is maintained in a changelist named “default”.
Mercurial users largely don’t need to worry about this. Simply run the reconcile command to prepare for a commit, and it will include all adds, deletes, and modifications in your default changelist.
Otherwise, work-in-progress is handled similarly by Mercurial and P4. Modifications to versioned files are part of your next commit by default. So, the only operations a Mercurial user typically expects to “tell” the system about are file adds and deletes.
This is usually handled via the “hg add” and “hg remove” commands, but the “hg addremove” command is a third alternative. It adds all new files and removes all missing files previously tracked with a single command. P4 reconcile command achieves a similar end result.
Shelving
Mercurial users have long enjoyed shelving as a feature. Shelving in Perforce P4 is similar but differs in that Mercurial shelves can be named whereas P4 shelves use a changelist, which is numbered and has a description instead.
For example, the default changelist has one shelf where work in progress will be saved automatically when switching branches or what not.
Paths
In Mercurial terms, a “path” is a “pointer” from/to which content may be cloned/pushed. Perforce P4 users know these as “remote specifications” or just “remotes” for short.
Further, a Mercurial “path” offers only a small subset of what P4 offers.
A P4 remote specification is much more powerful insofar as it includes the ability to map content very selectively. Folders and files may be flexibly remapped, completely changing the hierarchical structure for the local repository as needed.
And unlike Mercurial, a single P4 depot may also include content from multiple remote specifications (all of whose content may be re-mapped).
Commit
A Mercurial commit is also quite similar to the Perforce P4 submit, with one important difference.
Mercurial users are accustomed to their commits having two separate IDs: (1) a monotonically increasing integer unique and valid only within the scope of the current, local repository, and (2) a forty-character hash value that is both unique and valid in every version of the repository.
In contrast, each P4 changelist, submitted or pending, is identified by a single, monotonically increasing integer number. Many developers won’t care about these details, but DevOps personnel tasked with tying revision IDs to other integrated systems should be aware of them.
Defaults
There are also minor differences in the naming conventions.
Mercurial users are accustomed to their default path for push and their default branch name both being “default”. In contrast, Perforce P4 uses “origin” for its default remote name and “main” for the default branch name. This can be a source of confusion when Mercurial users first get started and can’t seem to switch back to the “default” branch; just use “main” instead and you’ll be fine.
Mercurial Commands: hg Commands vs. p4 Commands
Here's a quick Mercurial cheat sheet of Mercurial commands. We've also included a comparison of hg commands versions p4 commands.
The commands are fairly similar. For example, initializing a new repository requires a “p4 init” rather than an “hg init”, while the usual “hg addremove” followed by “hg commit” is instead “p4 rec” followed by “p4 submit”. All along the way “hg status” is replaced by “p4 status”.
| Task | hg Command | p4 command |
|---|---|---|
| Stage your changes | addremove | reconcile (rec for short) |
| List all branches | branches | switch -l |
| Branch and switch to it | branch newBranch | switch -c newStream |
| Create an empty branch | (no equivalent) | switch -cm newStream |
| Switch to a branch | up branchName | switch streamName |
| Clone a repository | clone repository | clone -p host:port -r remote |
| Clone part of a repository | (no equivalent) | clone -p host:port -f fileSpecification |
| Commit your work | commit | submit |
| Initialize a repository | init | init |
| Merge work from a branch | merge branchName | merge --from streamName |
| Get latest updates | pull update | fetch -u -r remoteName -S streamName |
| Push all local commits | push | push |
| Rewrite history | rebase | unsubmit / resubmit |
| List all remotes | paths | remotes |
| Create a new remote | (no equivalent) | remote newRemoteName |
| View your changes | status | status |
Migrate from Mercurial to Perforce P4
Mercurial is becoming more and more outdated. That's why it's time to migrate from Mercurial to Perforce P4.
As you can see, many of the commands are identical while others are a little different, but those provide what you need to get started. In fact, the above “cheat sheet” nicely serves the majority of day-to-day use cases.
Mercurial users transitioning to P4 should feel right at home with very little effort. See for yourself why migrating to Perforce P4 is the right choice for Mercurial users.