|
[Tech]
Perforce Sucks, Let Me Count The Ways
[
topping
]
I've used several SCMs over time, including SCCS, RCS, CVS, SVN, Perforce, and ClearCase. Subversion has it's faults, apparently, but it's been so long since I've seen one that I forgot they exist. On to the subject of this entry. Perforce sucks rocks through straws. We've been porting a project to Maven, an Ant project stored in Perforce. Having done this once with an Ant project stored in Subversion, the process was simple: Create a branch, issue the svn copy commands to populate the branch (copying groups of files as needed to the new directory layout), then when the branch is working satisfactorily, push the branch back to trunk. Perforce, in it's infinite wisdom, has the broken concept of "integrate" with two variants: So called "file spec" and "branch spec". If you read the Perforce docs, the difference is about as transparent as roofing asphalt, but when you get down to it, you find that a branch spec is essentially a record of all the file spec used to create the branch. The problem is you have to do this completely correctly before you use it, or you have to blow away all your files and start over, every time you change the location of the destination. The Subversion user will casually say "duh, well, use a file spec". Unfortunately, file spec (instantiated via direct 'p4 integrate' commands in a CLI or dragging files in the GUI) are not persisted. One can look at the history of a file and see that it was branched, that the corresponding file in trunk has lots of changes that you want to grab, but you can't *do* anything with the information. It's just metadata. Fools! People are still working on the trunk, and I need their changes. WTF good is branching in SCM if I can't have the tool use the metadata to grab changes on the trunk and apply them to the branch? As best as anyone here can tell, that's not an option unless you excruciatingly visit each branched file and ask Perforce to kindly move the change across. Or use the aforementioned branch spec. There are about seventy distinct moves of files needed for it to recreate the new (saner) structure required for Maven. Generating that list would be impossible as some kind of stream-of-consciousness blurted out into a ten-line window in the GUI. This is insane. Arguably, this is a minor inconvenience compared to the next problem. Imagine we've got our branch working, we're ready to adjust trunk to match. Is it even possible? No. All it appears we can do is push the contents of the files in the branch back into the existing structure of the trunk, since a "reverse integration" simply means use the contents of the filespec in reverse. Or am I expected to write scripts to do this? It's certainly not outlined in the Perforce User Manual, but if I go to http://svnbook.red-bean.com/ I find these exact use cases outlined with clear steps. It's been said that there are a lot of commercial software projects that have been made irrelevant by superior open source projects. I remember being fond of Perforce a decade ago. Today, I am spoiled by Subversion. I feel bad wishing that Perforce would go out of business soon, but I can't help but wish this scourge of an SCM finds the dustbin of history as soon as practical. TrackBack"Fools..." Yes, you are fools. Did you try to reverse the direction of the integration? Obviously not. I work in Perfoce with the scenario you describe all of the time, and it works flawlessly. --Manuel P. Ferreira, May 4, 2007 10:01 AM
Post a comment
|