Mercurial for Perforce users

(Might also be usable as "Perforce for Mercurial users")

(The structure of this topic is borrowed from CvsConcepts. Thanks, guys!)

(Perforce is a quite good commercial ["SCM"] - see http://www.perforce.com/)

• [#architecture Architecture]
• [#rev Revisions]
• [#tag Modules, branching and tagging]
• [#convert Converting a Perforce repository]
• [#collab Collaborating with other people]
• [#keyword Keywords expansion]

Anchor(architecture)

Architecture

Perforce is a ["CentralisedSCM"]. The repository for all users and branches lives on a central server. The command p4 is used for communicating with the server and working with local/repository files. Users create a "client" and checks files out from the repository to a working directory in their local file system.

Perforce requires that you have network access to the central repository (the depot) in order to perform any operation. E.g. are files write protected until they are opened for edit (and thus given an advisory lock).

By contrast, ["Mercurial"] is a ["DistributedSCM"]. Each working directory is self-contained and contains the files being worked on as well as a copy of the ["Repository"]. The command hg is used for working with files/repositories. You do not need to be connected to any server in order to perform any operation. You can even share your changes with others using USB memory sticks. E.g. can files be edited immediately; Mercurial efficiently finds the changes.

Anchor(rev)

Revisions

Perforce changelist numbers are similar to ["Mercurial"] revision numbers. Perforce repositories are central and common for all users, and the changelist numbers are thus globally unique and used as such.

["Mercurial"] ["RevisionNumber"]s describe the history of a local ["Repository"] and will thus be different even in similar repositories. To identify ["ChangeSet"]s ["ChangeSetID"]s are used instead; they are hashes of the content and are thus probably unique.

Anchor(tag)

Modules, branching and tagging

Perforce basically knows nothing about branches - but does it quite well anyway. Any file can be branched anywhere in the depot, even though branch specs often are used to specify branching paths. Client specs are used to decide which part of the depot to put in the working directory.

Branches

In ["Mercurial"], a branch is a repository. Nothing more or less. A repository is a branch. Repeat the soothing mantra.

The verb "to branch" simply means "to make a clone of a repository at a particular revision".

If every repository is a branch, how do you keep track of which one is which? That's simply a matter of convention. ["Mercurial"] has no idea which ["Repository"] is "main", or which is a "branch"; it's all a matter of how you use the repositories. See WorkingPractices and CvsLikePractice for some suggestions.

Tags

A Perforce tag is a symbolic name for a subset of files at certain revisions in a depot.

A Mercurial ["Tag"] is just a symbolic name for a ChangeSet. See ["Tag"] for a little more discussion.

Clients

In Perforce, a client is a collection of directories that you can check out under one name.

The equivalent Mercurial concept is the ["Repository"], but there's no notion in Mercurial of "bundling" repositories together in the way that Perforce can map any repository files into a working directory.

Anchor(convert)

Converting a Perforce repository

For a way to convert a Perforce repository to a ["Mercurial"] ["Repository"], see ConvertingRepositories.

Anchor(collab)

Collaborating with other people

With Perforce, the standard way to share changes with other people is simply to check them in. Some projects have a convention of posting UnifiedDiff patches to a mailing list before making a check-in.

In ["Mercurial"], collaboration is much more flexible. You can share changes in any number of ways, including (but not limited to) the following:

• ["Export"] one or more ["ChangeSet"]s and

  • put the exported ["PatchFile"]s on a server for someone to download

  • email the ["PatchFile"]s to a maintainer or mailing list

  • copy the ["PatchFile"]s onto a memory stick and give them to someone else

• ["Push"] (or rsync) the ["ChangeSet"]s into a ["Repository"] from which other people can ["Pull"] them

• ["Clone"] a copy of the ["Repository"] onto a CD-ROM and hand it to someone else

Running a server

With Perforce a daemon is running on the server, serving all clients over the network.

Anonymous access

In ["Mercurial"], you can provide anonymous access using HTTP. You can do this either with a CGI script (see the hgweb.cgi script in the distribution) or by running a dedicated server (using the hg serve command).

Mercurials HTTP server provides no access controls, so anyone who can connect to your web server can clone any repositories you publish, unless you take steps to secure them in some way.

Authenticated access

Mercurial allows authenticated access to repositories, by tunneling using the ssh command. To perform an operation over ssh, compatible versions of Mercurial must be installed on both the local and remote sides, and available through your shell's search path on the remote side.

Anchor(keyword)

Keywords expansion

Perforce can expand keywords such as $Revision: 1.12 $ by adding information from it. This feature is not in ["Mercurial"] - see http://www.selenic.com/pipermail/mercurial/2005-August/003887.html .