This just reeks of the problem with Google. They are sooo into themselves and into thinking that everyone smart works there. The reality is that far less than "all great programming brains" actually work at Google. I'd bet that not even 5% of the best programming brains work there - in fact, I'd bet that less than 1% even work there.

Google has become so cocky as of late that they think all the good people want to or do work there. That's just not the case.

We've recently hired 4 or 5 guys away from Google, and they are so into themselves for having worked at Google that they are almost impossible to work with. They think that they have some special 'rights' just because their resume says "google" on it. They are far from the most talented engineers where I work. But don't go telling them that.

Technically, it's MSFT. MS is Morgan Stanley.

Not even sure where to begin. But I guess I should start my response by qualifying how I've used Perforce, so that we can at least agree that I'm qualified to comment on it (which you assert I am not qualified to do).

I use Perforce at a Fortune 500 company, with over 3000 developers on the system. My particular project spans Linux for the back end (approximately 5mm lines of code), and uses Windows on the front end (another 2mm lines of code). Our developers span the globe, from the West Coast of the USA, to New York, to London, to Hong Kong, Australia.

So I think we can agree that I'm qualified to comment on the platform.

I do not work at Perforce, never have, don't own shares, etc. etc.

Quite a few of the arguments I see you have above are the religious ones - you'd prefer that your files are read/write 100% of the time. Perforce's model is that if you don't have the file checked out, then you can't touch it or change it. The reason it does this is that it wants to know exactly when you _started_ editing a file, so that that it can keep track of any changes that might come after you. Timestamps in the filesystem are not able to do this, so you have to tell revision control when you start editing.

OK, so the religion of read-only takes some getting used to, and it's different than 100% writable files. But the idea is pretty simple - don't ever edit a read-only file. Check it out, then edit it.

100% of the IDE integrations just do this for you, so if you are on an IDE it's pretty seamless. If you are in VI or emacs, you have to check the file out before you touch it.

If you don't agree with that religion, p4 is not for you.

Some of the commands you say are impossible are actually super simple, so let me clarify for anyone reading who wants to know how to do these things.

This isn't true - just set the host to an empty string, and it works on any host.

You'll have to let me know why this is a bad thing. So if you lose your local machine, you have EVERYTHING still in revision control? That sounds great.

You state that branching is impossible and takes many commands, but that just isn't true.
o Create a branch
  p4 integrate dev/... branchname/...
  p4 submit branchname/...

o Merge between branches
  p4 integrate dev/... branchname/...
  p4 resolve branchname/... # resolve any conflicts
  p4 submit branchname/...

Umm .. if you didn't change the file, then you probably never checked it out. If you checked it out because the read-only thing was bothering you, then just revert any unchanged files via:

  p4 revert -a ...

p4 opened ...

I have to just plain disagree - given my project size, and the fact that we were on a WAN, it was very very fast. Our tree was enormous.

You don't really substantiate this with much information, so all I can say is that I haven't seen what you are referring to here.

Again, not much information here, but I've never seen p4 take time to do really much of anything. The only thing that can take a while is if you have to pull a 5 GB file over a slow network connection, then it's going to take a while in any revision control system. But that is just a network constraint, not a p4 constraint.

This is true.

However, given that Perforce is:
1. Fast
2. Easy to do branches and merges (FAR better at branching and merging than SVN, which doesn't really keep track of your branch - that's "your" job ...)
3. Integrates with tons of IDEs
4. Can handle absolutely huge code bases
5. Is quite popular and very well supported by the company, so there are add ons and a big developer community where you can get great information
6. Is extremely stable
7. Works fast on many platforms (Git is renowed for being very slow on Window$)

and much more. It's very solid choice. It does cost money though.