Mercurial and Perforce

I have been learning two different source control systems in the last couple of weeks. Source control systems are a vital tool in any software development activity so I want to share my impressions of these tools.

Mercurial

I finally got around to setting up a repository for my personal projects1. For these projects, I chose to use Mercurial. I have been hearing a bit of a buzz around Mercurial for a while and I decided it would do me good to try out one of these newfangled distributed source control systems2. So far, I am impressed. Mercurial is easy to setup and use and it seems quite capable.

So far my only real complaint is that Mercurial does not version directories. It only versions files and the directory structure are treated as meta-data about those files. This makes it impossible to have empty directories in the source tree. Not a huge deal but it is annoying at times.

Distributed source control is a bit of a different mindset than I am use to. The sort of source control systems I am familiar with are built around the idea that there is one-true-version of the code and that the one-true-version lives in the central repository. I think it may take a while to get completely comfortable with a source control system that believes that there are lots of versions of a project all of which are equally valid.

My unfamiliarity aside, I like the distributed approach because I think it accepts the reality of software development. There are usually multiple useful and meaningful versions of a particular project at any given time and a tool that embraces that fact ought to work better than one that does not. I need to use Mercurial quite a bit more to be sure it lives up to that promise, but so far it is looking good.

Perforce

At work, the SCM team recently settled on Perforce as our standard source control system and I get to be the first person in my group to use it for a real project. I have been using it for a couple of weeks now and I can say that it is cross platform3, reliable, fast. Those are all virtues, unfortunately Perforce falls way short on the ease of use.

For example, you might think that something like p4 rename old_name.rb
new_name.rb
would rename the file but in fact it just prints this

See ‘p4 help rename’ for instructions on renaming files.

And when you run that it prints a bit of text outlining a multi-step process, involving branching the file and then deleting the original, that will result in the file being renamed.

If you want to edit a file, don’t even think about just opening it with favorite editor and going to town. No, you need to explicitly inform Perforce that you are going to edit the file by running p4
edit myfile.txt
. As far as I can tell, Perforce does not have a way to list what you have changed since the last check-out (or sync in Perforce terminology).4 This means that you cannot just edit and change to your hearts and then notify perforce of the changes in a batch, no you have to interrupt your flow to inform the source control system that you are about to change a file.

The requirement to manually “open files for editing” and similar issues would probably be easier to deal with using the Perforce Emacs integration but I really despise tools that require IDE integration to be usable. Variety’s the spice of life. Sometimes Emacs will do it, sometimes – not often, but sometimes – I like the idea of using vi.

I have used much worse source control systems than Perforce but I would never choose it over the veritable cornucopia of better, and free, source control systems available.


  1. So far there is just one public project, PHP Markdown (with footnotes).

  2. Well, all that and it is written in Python.

  3. I have used it successfully on Windows, Linux, and FreeBSD with no problems.

  4. I find it really hard to believe that there is no Perforce equivalent to the status command in svn, cvs, hg, etc. I look for it in the documentation every couple of day, but so far any way to do this has eluded me.

9 thoughts on “Mercurial and Perforce

  1. In case you didn’t figure it out, p4 diff -f -se ./… will display all files that have modified since the last sync. You can pipe that to xargs p4 open to open those files for edit.

  2. p4 diff will show you what you’ve done.

    p4 change -o (or something like that) will show you your current changelist.

  3. I’m surprised you found renaming files in Perforce so difficult; usually I just right-click on the file in the GUI and select “Rename…” from the context menu.

  4. Argh. I pretty much love Perforce except for branching and renaming.

    I just renamed a project folder, and all the files now show revision 1/1. So you lose the change history. Well, you don’t really lose it, there is some way to turn it on or show it – but by default, it looks like it’s gone. Right-click Revision Graph displays it elegantly, but Time-Lapse View and File History show only 1 version. It’s just that the Perforce attitude on some things is so 1970’s mainframe – if you don’t like jumping through complicated incomprehensible hoops to accomplish certain basic tasks (like branching), then you’re a wimp and you just shouldn’t use Perforce. You know, “man up, quit whining and memorize this man-page. Once you’ve really grokked it you’ll see that you can easily accomplish X by combining G, Q and F in the proper sequence.” That whole 90’s revolution about ease-of-use, the job of software is to hide complexity, people have better things to do than worship at the alter of your software? Perforce missed that.

  5. I was also facing the issue with not being able to add empty directories to Mercurial. Using placeholder files for empty directories makes sure that the directory tree is entirely preserved. But you need to create them, and delete them if they are not necessary anymore. This is why I decided to write an open source tool MarkEmptyDirs, which manages the creation/deletion of such placeholders automatically. Best regards and have fun with it,
    Jonny Dee

  6. “p4 changes -m1 …” shows you your currently sync’d changelist (you could have pending changes in your workspace which are not yet checked-in, which won’t be shown in this command).

    “p4 opened …” will show you the files which you have that are currently opened for edit (or needing resolved, been deleted, etc).

    If you want to edit files by clearing the read-only attribute and then telling perforce about them later, this is how you can do it:
    “p4 diff -se … | p4 -x – edit”

    this will get the list of files which are different in your workspace than those checked in, and pipe that list into the perforce edit command, thereby opening them for edit and adding them into your default changelist (without wiping out your changes).

    Either way, I still think I like Mercurial better. :)

  7. Whoops… “p4 changes -m1 …#have” shows you your currently-synced-to-changelist…typo… my bad.

Comments are closed.