What is the more efficient version control methodology: checkout or merge?

Question

I've always used Subversion or CVS for version control, which use a 'merge' methodology. One of my friends raves about Perforce and how great it is with its change lists and check-out methodology.

While I'm sure a lot of it comes down to experience & personal preference, I was wondering if any research had been done into which method of version control is more efficient to work in?

EDIT: To clarify, I know both Perforce & SVN allow locking & merging, but SVN 'encourages' a liberal edit & merge method, whereas as I understand it, Perforce encourages a checkout-checkin method.

Answer 1

Merge is more efficient. For the simple reason that changes to the same file simultaneously tends to be common, and merge allows you to recover from that. In contrast, single checkout prevents that little bit of extra work but it does so at the cost of huge inefficiencies in scheduling. Typically it takes a short amount of time to merge two changes to the same file (e.g. minutes), whereas it takes a significant amount of time to make changes to a file (e.g. many hours or days) so that preventing access to editing a file is a huge inefficiency.

Note that Perforce does not force the checkout methodology, it allows concurrent checkouts (equivalent to merge).

Answer 2

Not sure about the research, but here's one data point for you:
My team chose PVCS (checkout) mostly because of comfort. Doubts about merge and lack of awareness of tools like Subversion definitely contributed to that.

Answer 3

I'm not sure I understand the question here - I'm not aware of any modern source control system (other than Visual SourceSafe) that doesn't fully support merging.

Answer 4

Perhaps you meant Source Safe rather than Perforce? Perforce supports merging, and in fact had better merge support than SVN until SVN 1.5 where named merges were added (as well as change lists, which Perforce has always had and I mis very much moving to a shop that used SVN, but we won't upgrade until 1.5 has been a bit more time tested.)

It's worth noting that SVN and Perforce both allow you to do a locked checkout, so you can do the "unmerged" model if you want, but aside perhaps from managing binaries with version control, I don't see much use for this.

Anyway, the simple answer to your question is "merge models are far better any time more than one developer is involved."

Answer 5

If I understand correctly, Perforce makes all files that are not checked out read-only. This is similar to the behavior under Microsoft TFS and VSS. Subversion on the other hand does not set read-only attributes. IMO, the Subversion method is easier because you don't have to bother with a source control client in order to modify files -- you go ahead and modify with reckless abandon and then compare what has changed on disk with the server when you are ready to check in.

When all files are read-only, I find myself constantly changing a file, attempting to save, discovering it is read-only, then having to hop over to the source control client to check it out. Its not so bad if the source control client is integrated into your editor, but if you are storing things that are not source code under version control this often isn't an option.

Answer 6

If I understand correctly, Perforce makes all files that are not checked out read-only.

This is only the default behaviour. If required, frequently changing files can be set to be read-write instead. See a full list of file modifiers here.

Also, for my environment, I am using Eclipse with the Perforce Plugin. With this plugin, editing a file immediately opens the file for edit.

Answer 7

Honestly I think it depends on the discipline of the developers.

I use Subversion for my personal work and I've used it at a few jobs. What I like about Subversion is I don't have to hunt someone down and ask them why they're working on something and if it would be OK for me to do some work. The problem comes when someone decides to start working on something and doesn't check it in for a while; this can make merging difficult as several changes get made between their check-out and check-in.

I use Perforce right now and for some reason I like SVN better. Perforce definitely gives me a better indication that there's going to be merge conflicts, and even has built-in tools to help me resolve the merges. It has the same problem where if someone makes tons of changes over a long time, the merge will be more difficult.

Basically both models require you to check in changes often. If you make numerous check-ins, then you reduce the likelihood that you'll require a merge. I'm guilty of keeping stuff checked out for too long way too often. Personally I feel like SVN's price tag makes up for anything it lacks compared to Perforce; I haven't found a difference between them yet.

Answer 8

I definitely prefer the merge methodology.

I've used Visual Sourcesafe (hopefully never again), CVS, subversion and bzr. Visual sourcesafe enforces the "checkout before editing" methodology and can be painful. CVS and subversion haven't been great at accepting merges historically, though I hear subversion 1.5 has improved that.

I would recommend using a VCS that has been designed with frequent merging in mind from the start. bzr is the one I've used that does this, but the other major distributed vcs systems (git and mercurial) also do.

But ultimately I don't know of any research on this specific area. In general there is very little research into efficiency of programming, Peopleware being one of the notable exceptions.

Answer 9

In our last evaluation, Perforce beat subversion in its support for branching and integrating changes between branches. Work was underway on Subversion to remedy this short-coming, but we haven't been back to check it out.

In Perforce, when you branch a file, Perforce "remembers" where it came from and which revisions have been "integrated" into the two versions. It also has some storage optimizations in the repository so that a branch copy doesn't really materialize until someone makes a change in the branch, and then (if I understand correctly), it uses diffs against the base copy, just like revisions within a branch.

Perforce's tracking of the relationships between branches is a huge asset. If Subversion has implemented this now, please give me a heads up.

Answer 10

I don't really get the question, to be honest. But I can vouch for Perforce's efficiency and ability to handle more than one person modifying a file asnychronously, and handling the merging of edits.

In Perforce, if someone checks in a file that you are also modifying, then when you next sync from the server (i.e. get latest files) you get informed that there are some changes that need resolving. The choice on when to do this is up to you. When you "resolve" a file, it does the merge into your local version - and the tools are good for this.

Having a choice on when you do it is important - you may be syncing so you can get some updates not directly related to your task (bugfix, say), and you don't at that stage want to deal with working out if someone else's change to the same files you are working on will affect you. So you carry on, do your build & test, then after that you resolve the files in your own time.

The other case is that you submit your edits without having first synced to the updated file. In this case, Perforce prevents the submission and flags the files to be resolved. Any sensible developer at this stage will do the merge, then recompile and/or test before submitting the change back into Perforce.

What I like about this is that it tries really hard to stop you submitting changes back to the central server that have not been explicitly processed, and hence minimises the chances of breaking the build. The resolve process is easy and very low overhead, so there is not an efficiency issue at all.

Perforce is very explicit in giving you choice and control on how changes are propagated, and backs this up with excellent tools to manage merging of edits. Personally I like choice and the power to exercise choices easily. Doubtless Subversion has its own alternatives too.

I guess it probably comes down to what you are used to - I don't think there is a significant or measurable efficiency issue.