My offhand mention of switching from CVS to Perforce for source control at work brought an email from a friend. His company had also just made the same switch, and he wanted to know why we switched, how we chose, and what we thought so far.
We switched because our CVS server seemed a little flaky on Windows, and because CVS seemed uncertain with complex branch and merge topologies. We also knew we would get other benefits from switching, like tracking changes to a number of files as a single changelist rather than as a number of revisions.
We chose Perforce over ClearCase because our developers who had experience with Perforce loved it without reservation, and our developers who had experience with ClearCase loved it but said it took a lot of work to setup and keep running. Also, ClearCase was very salesperson-heavy, while Perforce would let you download the code from their website.
As to my impressions, here are the things I like better about Perforce and the things I like better about CVS:
First off, keep in mind that I have been using Perforce for about two weeks. I’m usually pretty quick at learning new tools, but I could be overlooking things Perforce can do, or ways it can do them. Feel free to teach me!
Perforce’s wins:
- It’s much faster than CVS.
- It treats a number of files changing at one checkin as a single changelist rather than a number of revisions. This is much easier when propagating changes from branch to branch.
- Its architecture is built to accommodate scripting. You still screen scrape a command-line utility, but the utility has been designed with that use in mind.
- Trent Mick’s p4lib.py is marvelous, and has done all the screen-scraping already.
CVS’s wins:
- It’s cheaper.
- .cvsignore files let me teach CVS about files that were not supposed to be stored in CVS. Perforce has no such concept.
- CVS did a better job alerting me to the fact that I had created new files which needed to be added to CVS.
- CVS would merge files changed by more than one developer automatically. Perforce will do the merge, but only if I tell to auto-merge. If the most merges don’t conflict, then why not just do it and let me know when conflicts happen? Maybe there’s a philosophical difference here that I am missing.
- CVS was better at off-line work (when you are not connected to the server). Perforce can accommodate it, but it’s got more of a disconnect-then-work-then-reconnect feel to it. With CVS, there was no need to communicate with the server to get work done, just when it was time to check code in, so disconnected work was very natural.
Things I don’t like about Perforce, though I can’t claim that CVS is better:
- The Perforce merge tool is an ugly unwieldy confusing mess. Maybe I just have to get used to it.
Comments
For branching, we created a developer's depot where each developer has their own branch. It is a little more work "integrating" your branch (synching back and forth from the main branch), but the ability to check in and check out revisions of your own work prior to submission is very nice, plus it is a built-in backup system!
I have been using Beyond Compare (Judd's tool) for diffs, for $30 a copy it is worth it.
Meanwhile, you can add mappings to your client view specs to ignore certain files (like .cvsignore) if you want.
Perforce takes a little while to get seriously to grips with (as opposed to just getting set up and basic check in/out) and I would recommend the Perforce User mailing list and browsing the Documentation/White Papers/Public Depot etc.
It is a bit of a hack, but works great.
Send me an email if there is any interest in the actual command to use.
write user * * -//....lib
That will remove access to all lib files. Of course you can be less heavy handed by only applying it to certain paths.
Add a comment: