Perforce certainly has a stellar reputation amongst software
developers; Perforce for real projects, and your choice of open source
version control system if you cannot afford to foot the Perforce bill.
This naturally leads to the idea that Perforce is for power users,
whereas systems like CVS or Subversion are for beginners. After a few
days using Perforce, however, (I had only ever used Subversion/CVS in the past), I noticed a striking contrast between the two groups that seems to contradict this.
Consider the standard use case for a version control system: editing files, and then committing those changes back to the repository. If you are using Subversion, you simply edit the files in place. When you are ready to commit, you issue a ‘status’ command to get a quick overview of files that have been changed, files that have been added, and files that have been deleted. You may choose to add some files that are not under version control, revert some files that shouldn’t have been edited, and then issue the commit command to finalize your session.
Now consider the same case under Perforce. You go to edit your first file, only to realize that it is read-only, requiring you to first ‘open it for edit’. After a number of edits, you decide you need to add a new module to your program. Don’t forget to add this file to
Perforce, because as far as I know, there is no way in Perforce to get a list of files that are not under version control. How many times has someone in your organization broken the build because they forgot to add a new file to Perforce? You then decide that you want to run a script to edit a large number of files. After you have modified these files to be read-write, you run the script, but then realize Perforce has not picked up the changes in ‘Pending Changelists’ screen. Of course not, because you didn’t explicitly open these files for edit! After you are ready, you issue the ‘submit’ command to check in your
changes.
Can you spot the difference? With Subversion, the version control system is not forcing you to be aware of your changes until you are ready to commit. With Perforce, you constantly have to be on top of your changes during development. Perforce is forcing you to think about version control while programming. While Subversion silently sits
in the background, Perforce is constantly poking you in the back whenever you want to do something. Could you get any work done if someone was doing that in real life?
The real issue boils down to Power Users vs Beginners. Perforce holds your hand and puts in restrictive measures to ensure you don’t break things. This is great for beginners, but quickly becomes annoying and frustrating for experienced users.
What about the other features of Perforce? Surely they must justify the 800$ per head price tag? Maybe, but as a developer, I’m focused on the edit-resolve-commit cycle for 95% of my time. Get out of the way and let me work. Now who broke that build…
The one thing I really liked about Perforce is being able to see what other people are working on. In the GUI client you can see a list of changesets created by other people so you might notice that someone has opened a couple of the same files as you for editing and this might prevent you from messing something up for them when you commit your changes.
As much as I appreciate Subversion, it doesn’t support the one feature of Perforce I found most useful: views. With P4, I can specify that I want /a/b/c, /d/e, and /f all checked out as siblings, so that my workspace contains c, e, and f. This is useful when I want to put a development branch, a directory full of test cases, and a directory containing a consistent set of libraries side by side. There doesn’t seem to be any way to do this in SVN.
I also found P4′s branch-and-merge model *much* friendlier than SVN’s: ‘copy’ is a lousy way to create and manage tags and branches.
For a long time Perforce was the only good alternative to CVS. Subversion is relatively new by comparison, and only really became viable with the FSFS backend introduced in version 1.1. I think a lot of shops got used to the Perforce way of doing things and are generally happy with the tool, making them reluctant to switch now. $800/seat might seem steep, but for large shops it’s money well spent even for just a small edge in productivity over other tools.
Greg, you should be able to setup sibling directories by using svn:externals.
Just create a ‘workspace’ directory for yourself in svn and do:
svn propedit svn:externals workspace
Add the following lines:
c http://foo.com/svn/a/b/c
e http://foo.com/svn/d/e
f http://foo.com/svn/f
Or something similar and you should get your directories setup as siblings.
Sounds typical of inexperienced perforce users. Ive been a long time use of perforce and was most recently exposed to svn.
not sure why you dont think you have the same problems in svn but ive already seen broken builds because a developer did not specifically add a file in svn (same problem you mentioned in perforce).
if you use an integrated plugin for perforce most of your listed problems go completely away, especially id combined with something like msdev(just bring up a file and hit a key to check the file out dont even have to go to the perforce client).
the perforce client is hugely better then any client for svn btw. It takes me a lot less steps to see file changes, do revision diffs, check out revision graphs, etc. then its does in svn or any or the primary svn clients.
let alone the fact ive noticed perforce to be significantly faster then svn on large projects.
plus the tech support for perforce is top notch.
cost of perforce goes down after the first year (use to be 600 first year and 120 a year after that per user, its gone a little since then).
Im actually really frustrated with svn, its lack of visibility of whats going on in the repository, who has what checked out, the difficulty with the concept of a client spec, lack of tons of features that perforce has and is constantly adding.
Perforce is lightyears ahead in many other areas as well, backups, cpu/memory utilization, and especially stability.
we have already had svn completely lose checkins and ive never seen that in perforce.
but all in all the svn clients are just awful, featureless, and buggy as hell.
svn has a lot of potential but I wouldnt use it for anything but small projects with a very small group of developers.
The add functionality in P4 really ticks me off. They do have a “View lcoal files not in depot” but you have to twiddle the tree. No flat view like the admittedly rudimentary WinCVS client. I constantly have something I didn’t add and I have P4WSAD! And if you compile in the source directories in your IDE drag and drop from explorer won’t work, P4 tries to add every G’d thing in the tree. uhhg.
Another thing is, if you edit a properties file like “build.properties” now you have it in your changelist. But why? I don’t want to accidentally overwrite what is in the depot by submitting this change list. So now I have a change list labeled “not for checkin”. How gay.
Another annoyance: When you change views of the depot the whole screen has to repaint. And why should I ever have to change the “view” of the depot anyway. Half of the ones that are up there I don’t even understand. My code is either checked into the particular branch or not, why do I need all these views? Can’t they use colors to tell me whether the file is in the depot?
And another thing, what about filters on the files listed in the view?
And another thing, what the heck does that little padlock that I get sometimes mean and what is the point if I can just unlock it?
The P4 state machine is just a headache. The author is dead on in saying that at least CVS (never used Subversion) stays the heck out of your way and gives you a concise view of what you have to do when it is time to commit. I wish Lewis Black was a coder so he could give one of his rants on ths VCS. Man the thing ticks me off.
Nevertheless, I sent most of this rant to the tech support at Perforce without a subscription account or anything, and they were very responsive. So it has been my experience that the support is super.
Would the quoted price for Perforce of $800 per seat be an annual or monthly price? Does this price include support? And then after the first year, I assume the price drops to $160 for support and maintenance alone. Is this correct?
Donna