4 ms·

Perforce is not terrible. I'd even go so far as to say; of the centralized systems, it's better than any other I've tried (including Subversion, and cvs). It

Perforce is not terrible. I'd even go so far as to say; of the centralized systems, it's better than any other I've tried (including Subversion, and cvs). It could be better, but it could be much worse. Things we like about perforce: - Client side changelists for modified client side code. This helps organize our local changes to make sure when we're working on multiple things they stay separate. - The server is solid. - Can handle large files, including the ability to 'forget' previous revisions to save space on the server. It's abusing the system, and we've been told as much by Perforce. It just happens to be the way we do business, and changing that is another project. - It can do branching/merging - The visual diff and merge tools are pretty good (mostly, more below). - Everything that's under revision control is in one place. If you don't want to have the files on your workstation you can simply remove that tree from your view. Things we dislike about perforce: - It costs money. At the size of our organization it costs about as much as another employee. This is the reason we were 'given the OK'; developers don't really care about cost as long as we're employed, and management doesn't really care about features as long as we're productive. - We've had significant issues when merging. Conflicts are not properly flagged and "ghost" code (code that didn't exist in either branch) sometimes appear in the merge result. - The clients are very iffy. Crashes are frequent, and the merge problems are related to client-side bugs. - No one in the company is a fan of being required to 'check out' files to get them to be writable. This is how perforce knows when files are modified and because there is no equivalent for new files people frequently forget to add files and break the build. - It can only show you < 1000 files in a given changelist. Big changes like that are when it's most important to see what you're doing. This is pretty common when doing branch integrations. When this happens you have to hit the "auto-merge" and hope for the best. - Branching/integrating isn't streamlined enough to really support every developer having their own branch. If it was dead-simple we could support a distributed development model with a centralized server. - No real way to share code (for reviews, or collaboration) without going through the shared depot. We use p4tar, but it doesn't play nice with cygwin and has it's own problems. - No direct way to revert code. Reverting is a 5 step process that isn't entirely obvious. I think that's it.

thorax 18y ago
Excellent list there. I think all of your issues are all things I also see as drawbacks to Perforce. I think the main breaking point out of your list would be the merging instability you mention, which we haven't had at either of my last two companies. We do have merging issues in a different way, but it's always because someone used the wrong flag when merging the two or didn't properly create the initial branch. Still, this is significant anyway because merging/branching really needs to be easy to manage (i.e. hard to screw up) for a tool like this. In the mega integrations, we came up with a few tricks to work around the file size limit-- often involving merging subtrees one by one from the target branch. This is often needed organizationally for us anyway because the teams/experts are often different when it comes to resolving those merges. It results in more changelists, but it tends to work out okay and the integration history is actually in a better state regarding a proper contact for discussing it later. We wrote our own Perforce tools at our company for sharing code for code reviews, or some teams use user/feature/"pre" branches for that. I'd like to see that improve in Perforce, but it's been pretty bearable. What I really want is something with the maturity of Perforce in terms of tools/API/integration/monitoring/history/etc but is built on the premise of needing to do lots of merges and branches easily. I know some major organizations have gone with things like Mercurial because it felt to them like it would mature the fastest in terms of corporate needs, but I've yet to see any of the distributed version control systems that has gotten over the curve: http://en.wikipedia.org/wiki/Image:Gartner_Hype_Cycle.svg http://en.wikipedia.org/wiki/Image:Gartner_Hype_Cycle.svg I can't wait until they do, really, because the perspective that merging is central to version control is something I agree with.

thorax 18y ago

Excellent list there. I think all of your issues are all things I also see as drawbacks to Perforce. I think the main breaking point out of your list would be the merging instability you mention, which we haven't had at either of my last two companies. We do have merging issues in a different way, but it's always because someone used the wrong flag when merging the two or didn't properly create the initial branch. Still, this is significant anyway because merging/branching really needs to be easy to manage (i.e. hard to screw up) for a tool like this. In the mega integrations, we came up with a few tricks to work around the file size limit-- often involving merging subtrees one by one from the target branch. This is often needed organizationally for us anyway because the teams/experts are often different when it comes to resolving those merges. It results in more changelists, but it tends to work out okay and the integration history is actually in a better state regarding a proper contact for discussing it later. We wrote our own Perforce tools at our company for sharing code for code reviews, or some teams use user/feature/"pre" branches for that. I'd like to see that improve in Perforce, but it's been pretty bearable. What I really want is something with the maturity of Perforce in terms of tools/API/integration/monitoring/history/etc but is built on the premise of needing to do lots of merges and branches easily. I know some major organizations have gone with things like Mercurial because it felt to them like it would mature the fastest in terms of corporate needs, but I've yet to see any of the distributed version control systems that has gotten over the curve: http://en.wikipedia.org/wiki/Image:Gartner_Hype_Cycle.svg http://en.wikipedia.org/wiki/Image:Gartner_Hype_Cycle.svg I can't wait until they do, really, because the perspective that merging is central to version control is something I agree with.