Rails and Perforce vs. SVN

I've been doing Rails work, both at work and for some personal projects. At work we use "Perforce":http://www.perforce.com for version control, but at home I use Subversion. It's interesting to compare the two. For example, Jonathan Rentzsch "does not like Perforce":http://rentzsch.com/notes/whyNotPerforce. Also, Rails is a little harder to use with Perforce (P4), and has some specific integration with SVN (for example, the "--svn" switch to some scripts).

My take is that SVN is a HUGE improvement over CVS - the atomic checkins alone make SVN all of a sudden a very viable version control system, whereas I think CVS pretty much sucks. But how does Perforce compare? First, I agree with most points Rentzsch makes. P4 is not ideal when you want to work disconnected. And, yes, once you've used a system like SVN or CVS where you aren't required to check out a file, P4's (and several other VC systems) requirement for this is somewhat painful. However, P4 completely blows most others (all others I've used, including CVS, SVN, Visual Source Safe, PVCS, and one or two I can't remember) away when it comes to branches and the use of what we call at work, "sandboxes" or workspaces.

I've come to almost not want to work without sandboxes. What are they and why are they so great? So, a sandbox is essentially just a branch, in fact it specifically is a branch. Every developer has their own sandbox, and then there's the main code line (and on my current project, there is another sandbox between those that is for our sub-team, but I won't complicate things with that right now). What this does is allow you, as individual developer to fully leverage version control in your own work area. Then, when you are ready, you can integrate your code back to the main line.

Before I go further, I want to say how incredibly easy it is to merge/integrate code back and forth between main and your sandbox, when using P4. This is, to me, probably Perforce's top strength and what sets it apart from most other version control systems. In CVS and SVN, it's a complete pain to merge back and forth between branches. You have to look up last merge times, etc. With Perforce, you simply run an integrate command on your sandbox branchspec, and P4 takes care of the whole thing, either direction. It does a merge, and shows you what conflicts, then has many automated ways to resolve conflicts. I should also note that P4's merge abilities are top notch (SVN has no auto-merge that I'm aware of). Perforce's merging and branch handling is so good that I regularly do this multiple times any given day.

Anyway, once you work in this manner, you come to rely on it. It's superb as well if you work in a cross platform environment with compiled code. For example, you can develop a feature say on your Mac, build and test, then check it in to your sandbox. Then, you go to your Windows box, sync up to your sandbox, build and test. Once it's dialed on both platforms, then you can merge to main.

These techniques are very useful with teams, as one can imagine. However, it's also useful just for a solo developer as well. With such easy branch use, you can create branches for experiments, or longer term/parallel work.

Coming back around to Rails, I use P4 with it at work, but it's more difficult due to P4's requirement to check files out prior to editing them. As Rentzsch mentions, various editors will make this easier with their P4 integration, but this doesn't work for Rails' various generators or say plugin installer scripts. These scripts just expect to be able to directly edit a file. Luckily you can at least do a dry run, and pre-check out files, but that's kind of a pain. So, I'm hoping to start working on adding a "--p4" parameter corollary to the "--svn" parameter. If/once I get that done, I will contribute it back of course. Feel free to let me know if you'd find that interesting.

Tags: Rails, Perforce, Subversion