I find these tools difficult and extremely painful to use. Or maybe it’s just the poor and incomplete integration of these tools at my current place of employment.

I often have to go back in the source tree created and locate the code that I wrote and recheck it into the current branch.

It’s the developers fault. Yeah right.

However, I just have to say that your description of conflict resolution workflow looks pretty much exactly like my experience of CVS conflict resolution in many a real situation, so I’m sort of curious how it’s supposedly better. *smile*

Branching and lack of changesets are definitely big weaknesses in CVS, though. (On the other hand, there’ve been times where the non-atomic nature of CVS commits has been really handy for one reason or another, so I’m sort of torn on that issue.)

Anyway, a fun read nonetheless.

With Perforce, I have wasted many a day trying to do something that should be somewhat simple. One big plus is they have phone support. However, beware of the frequent response, “We don’t support that, because it does not follow the Perforce philosophy”. My philosophy is I want to get my job done and not break the build, hopefully that follows the Perforce philosophy. Perforce’s philosophy seems to mean no local metadata, which creates problems.

One huge problem with Perforce is its offline behavior. If you are ever on a laptop and need to make changes you are in for a world of hurt later when you go to sync up later. When you are on the road you have to write lock the file and when you can talk to the server create a changelist but the way they recommend ends up adding a bunch of files to the changelist you don’t want to add. It seems kind of stupid because all you are doing is telling the server that you are about to work on a file. This does force you to get the latest version which is not a bad thing, but I would want to see better support for offline editing, especially in a commercial product. Part of the problem here is that there is no meta data in the local directory. So there is no easy way to indicate that a local revision has changed. The other reason why it is a problem is your workflow completely changes depending on whether you are connected on the network or not.

Subversion is better at working offline, you can edit files and because it keeps a cached version of the original in the meta data you can even revert offline. You can also do diffs offline. Because it has local metadata, it should also be faster because all it has to do is send the diffs when committing.

The lack of meta data also creates problems, if you accidentally change workspaces to the same set of files, perforce can get very confused and lose data. This does not happen in CVS or Subversion because the meta data is linked to the checkout.

Sometimes, Perforce can get out of sync, and you must “force sync”, which causes perforce to check every single file in the subtree you select to see if it is newer than the local file, this is a slow operation. This does not usually happen very often but can create huge problems if even just one file is out of sync, you get people complaining, that the build is broken, but the real problem is the latest file did not get synced. Telling people when you use force sync is kind of hard to explain, especially less saavy users. Often times users always use force sync once they have been burned by a bad sync. This ties up the server and takes a lot of time, especially if you have a lot of files.

Another problem, touched on above, in is that Perforce write locks all your local files until you check it out from the server, many programs are unable to deal with locked files gracefully or are not integrated with Perforce. So you have to go to the command line or to the separate p4 gui to edit the files that do not have built in Perforce integration. This is not a problem with CVS or subversion.

Another major problem with Perforce is that it does not have any built in way to do a reverse sync. That is, I have added new files on my local directory and forget to add them to Perforce. Perforce will not tell you that you forgot to add the files so you break the build. I don’t know how many times, I have checked in files, thinking that I would work on it when I got home, but forgot to check in one or two so the whole evening is shot. CVS and Subversion both tell you if you forgot to add files. You can set up, once again, in metadata, which files to exclude when reverse syncing.

Subversion fixes almost all of the problems with CVS. I would recommend it, I think it is the future of source code control. Its only problem is that is still kind of new so integration is not completely there yet. If you are the cautious type, wait for another year. Unless you are currently using CVS, then, I would consider switching now.

This is not say that Perforce could not fix the problems I mentioned but they seems somewhat unwilling to do so, we asked for the improvments metioned years ago, but have not seen any movement in that direction and got the philosophy response. The lack of local metadata, I think, actually hurts them.

We went from VSS to Perforce. It was a painful transition, but has been worth it. We currently have people from Japan, Ireland and both coasts of the US using our system. We have a huge base of cross-platform code that is distributed amongst several projects.

Perforce is un-simple. It is not wise to implement this system if you are unwilling to devote time and energy, as well as money to it. You definitely need a dedicated administrator, and this admin needs to do their homework. I administer our server. It makes me rather stressed when the developers are demanding answers right now. We use a Windows server. The server is a big commitment. Choose wisely. I am not a huge Windoze fan, but it has done well for us. There are many aspects to a server, such as which ones the IT Department will support.

If the lack of a one-click installer is enough to make you eschew this kind of product, then run away. Fast. Perforce has so many nooks and crannies that your blood will run cold.

Me, I’m a geek. I kinda like them all. I have developed some interesting automation that leverages them.

Hmm… From what I can see, CVS doesn’t seem to be any simpler, but I don’t use CVS. I use Perforce, so I won’t pretend to compare. I only evaluated CVS briefly at the time we switched away from VSS, and chose Perforce.

One aspect of the free two-user demo is that it doesn’t let you create multiple clients (what a rotten name -it should be “workspace view” or something.) Multiple clients are the life blood of our system.

Perforce has second-to-none product support, and that is very important when it comes to a product this complex. I have had to use it numerous times. The people who answer my emails (often frantic emails) are extremely knowlegable and polite. I’ve asked many stupid questions, and have yet to be slapped upside the head for it.

I think that they have given MacOS short shrift, They have a long list of OSes that they support, but the great majority are varieties of Eunuchs. We run Mac and Windows here. Windows is OK, but the Mac CW plugin is shaky. I find their HFS/POSIX confusion to be particularly yucchy, but they did address it with the AltRoots hack.

Perforce uses a server model. This makes it very, very fast, as the server and client exchange information about their contents, as opposed to VSS, which was file based, and absolutely agonizing over slow connections. The downside is that the server can get confused about what is on your client workspace. The server always knows best, even if it don’t know diddly. Sometimes you need to do a force sync or a synchronize status just to convince the server that it suffers from a rectal/cranial inversion.

In any case, we’re a pretty satisfied customer. One thing that I definitely don’t miss with VSS was the inevitable database corruption just at critical release time. Perforce has been pretty solid, with the exception of some line-ending shenanigans that they still need to fix.

I’ve put some notes on using Perforce on OS X here:

http://peterb.telerama.com/weblog/archives/000018.html

Yes, I’m in the same situation — we often have developers working on the same files, or even the same parts of files. It would kill our development if we had to serialize access to files. Basically, p4 lets any number of users edit any file at any time in their own private workspace. When they submit those files back to the repository, they may have to resolve their changes with changes that occurred while they had the file checked out. Perforce makes that resolve step as easy as it can be, IMHO.

The p4 workflow in more detail looks something like this:

-there’s the repository, or depot. That’s where the files are
-there’s a “client view”, which is some space in the filesystem that maps a view of the repository at a given changenumber. client views can be synced to any changelist number with ease. A user can (and will) have many client views into different branches, or to the same branch, of the depot.
-when you want to edit a file, you do “p4 edit “. That makes the file writable and gives notification to anyone else that wants to edit the file. Note, you’re not -locking- the file here — other people can go right ahead and edit it (the version they have synced to the repository in their client view), they just get a nice little note saying “so-and-so is also editing this file.”
-you go ahead and do your edits.
-you submit to the repository with “p4 submit”.

If no one has submitted a new revision in the meantime, the submit just happens. If someone has submitted a change in the meantime, p4 says “hey, this file has changed,” and you type “p4 resolve” to resolve the changes. resolving brings up a pretty nice tool that shows you exactly what lines changed in your submit and in the version in the depot, and asks you what to do.

If you haven’t touched the same lines as the other submits, 98% of the time you can just say “p4 resolve -as” which is perforcese for “just go ahead and do the right thing.” p4 merges the changes and then you can submit.

If the changes you made conflict with the changes someone else made, p4 asks you to resolve them by hand — you can throw away your changes, throw away the other guy’s changes, or (the usual choice), edit the file. p4 then gives you an annotated version of the file to play with. A (fake) example might look like this:

int some_function(int param)
{
int ix, jx;
>>>> ORIGINAL VERSION file.c#8
char str[10];
====
>>>> THEIR VERSION file.c#9
char name_string[10];
===
>>>> YOUR VERSION file.c
char *str;
str = malloc(MAX_STRING_LEN);
if (str == NULL) {
return -1;
}

I work in an organization separated by wide timezones and hugely different development schedules even for some of the developers in the US.

Using an exclusive access model for us just won’t work. We’d lose days of work if we constantly had to be bugging each other about checking files back in.

You don’t really talk about how P4 handles such concurrency. I’d be interested to hear more.

Another weakness of CVS you neglected to mention is its horrible support for binary files.

Wade

foobar: Obviously, I don’t consider “not free and open” to be a “fatal flaw.” For those who are more concerned that their software be politically correct than that it actually work, I agree that Perforce might not be the right choice.

Dave: I haven’t set up P4 myself on OS X, although I’ve done it on other platforms. I could believe that it’s not super-integrated onto OS X. Tell you what — I’ll give it a shot this week and report back on how it goes. My instinct is that there’s a level of assumption that the documentation makes which is reasonable — for example, if I was writing documentation for how to install a unix-based program, I don’t think I would explain how to adjust the user’s path — to me, that fits into background knowledge. But hey, you’re the user, and if you found the documentation inadequate, I’m not going to tell you otherwise!

macnixer: the first paragraph of my article points out that there are probably lots of other great SCM systems than Perforce. I talk about p4 because it’s the one I know and love. Thanks for bringing Surround to my attention!

When we compare tools and price is not a criteria then we should be able to look at what is in the market, else we have a comparision that is one sided. As I understand the author of this article has used only Perforce and CVS and for obvious reasons is more happy with Perforce. Try Surround SCM and you will find a lot of what you want to do.

Another factor to consider when we talk about version control: a roundtrip system. a bug tracking tool is as important as the Version control. Only Seapine provides that capability on the Mac presently. And the beauty is it is cross-platform (across – platforms).