![]() | Ned Batchelder : Blog | Code | Text | Site Perforce vs. CVS » Home : Blog : May 2003 |
Perforce vs. CVSSunday 11 May 2003 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:
CVS's wins:
Things I don't like about Perforce, though I can't claim that CVS is better:
tagged:
source control» 5 reactions | |
Comments
I must react since my email was the thing that set you off. As for the merge and diff tools. The merge tool can be a nightmare, so a lot of folks have switched to Araxis Merge, which costs about a billion dollars. If you run into a lot of conflicts, this is your tool. For myself, I have not yet run into anything that was difficult (working in a lonely playground) so I am OK.
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.
There is a new merge tool coming out soon which I have hopes for! (Written with QT).
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.
Per-client view mappings can help to focus Perforce on the files it should care about, but how can I do that in a way that all of my developers will use them?
On Unix for merging I use emacs's 3 way diff for merging and have done pretty complicated merges.
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.
You can put a line in your protection table to exclude build cruft. Say you don't want .lib files. Tryt this:
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: