The company I'm currently working at has decided to consider alternate version control systems. We're currently using CVS and some people have mentioned PVCS and others have mentioned Star Team. Has anybody used different version control systems on different projects and have some opinions on what to use?
OK. Here's the list that I have used to date, with comments. SCCS Free and supplied with almost all unix systems, plenty of books, manuals and people who know how to use it. Does not work well with projects in multiple directories, especially if any two files have the same name; so it's a no-go for web projects with umpteen "index.html" files. Old and not very flexible. Not easy to use over a network. Uses a "one person at a time" file locking system, difficult to merge different "branches" of development. RCS Free, and available for unix, linux, PC systems etc. Not always supplied with unix xystems, but easy to find and download. Copes better than SCCS with multi-directory projects, but still not very good at multi-machine work. Uses a "one person at a time" file locking system, difficult to merge different "branches" of development. Suits small-team single-machine unix projects quite well. CVS Free and very popular for open-source internet developments as it supports network access to a shared code repository. Uses a "diverge and merge" system. Easier to merge differing branches. Most CVS systems are built on top of RCS, and it can be a bit slow in use and strange to configure. It also seems to scatter its own directories all over the place, which I find a bit antisocial. PVCS This is what the project I'm currently working for uses and I hate it. It may be because the project hasn't bought enough licences (they are quite expensive), but it seems really clumsy to use. It's based on a DOS product, and use on unix seems to involve lots of jumping through hoops for a system that's no better than RCS. Perforce I used this on a previous project and liked it a lot. It's like a smoothed out and speeded up version of CVS/RCS. It's fast and easy to use both on a single machine and over a network, and lets you choose whether to work in "one at a time" or "diverge and merge" modes. Their tech support is loads better than PVCS, and there's a no-time-limit but limited number of users version for download. (www.perforce.com) I've seen lots of other systems, but not used them properly. As you can probably tell, my favourite of this list is Perforce. I'd recommend trying the eval version. I look forward to hearing other people's experiences.
Excellent feedback Frank. In looking around a bit, I found an all Java interface to CVS. Kinda tempts me to really use CVS. But I have to agree, those files everywhere are inappropriate and gotta go.
Does Perforce leave files around like that?
Joined: Jan 07, 1999
Paul wrote: Does Perforce leave files around like that? I don't remember it doing so. I last used it over a year ago, but I do remember being surprised at CVS, so I can only guess that Perforce didn't.
Joined: Apr 03, 2000
Hi folks I have only just joined the group, so apologies for this response being a little late. I have used PVCS (years ago at the OS/2 prompt), Visual SourceSafe (recently) and Perforce (currently). I can't comment on PVCS these days (their first port to PM was dire!). VSS looks pretty from a distance but I wouldn't trust it with a big/multibranch development (never trust a VCS that comes with a util to fix up the database - and that is required if your server powers off without warning, a VCS should have the same recoverability of an enterprise DBMS). Perforce is very competent at the command line, the Windows GUI is still in its early days and hopefully will soon a) start behaving like a proper Windows program and b) add all the functionality available at the command line. What Perforce lacks is decent reporting/searching and it also loses change history when a file is branched (given that this is the way we work, with multiple dev branches & merges - and that this is the way Perforce propose you work - I see this as a major annoyance). Regards Gary
Joined: Jan 20, 2000
I've been at two shops that use PVCS. I hate it - it's slow, clumsy, and difficult to manage. That said, I have been able to configure it to do most of what I wanted it to do (after spending hours hacking away at a command line interface and a very poorly written manual). I really would like to investigate CVS and one of the Java front ends but haven't had the time as of yet.
<B>Rich Wardwell</B><BR> <A HREF="mailto:email@example.com" rel="nofollow">firstname.lastname@example.org</A> <BR>Sun Certified Programmer for the Java 2 Platform
Joined: Jun 25, 2000
We're in the same boat with CVS the front runner. Why? Mainly because I can look at how BSD manages its source and match the pattern. BSD, which uses CVS and GNATS, has source available from R2 (it's on R4) and *every* module from that time is available via a web interface. More importantly, the web interface allows me to view by branch, revision or tag name. As for the file scattering? So what. Emacs leaves enough *~ files to fill an 4G hard drive. One perl script away from being clean. Perforce and StarTeam are the only for-pay contenders. StarTeam seems to have a very nice configuration management interface, but every little thing costs money. Perforce is my favorite, if I had the money. It pretty much does everything CVS does (I wasn't aware of the revision loss with branch. That doesn't sound right) and is fast. Furthermore it has an SCC module that works perfectly with Visual SlickEdit and command line programs that work with Emacs. It's been ported to everything known to man, and they say if you want it ported to X, they'll try to accomodate you. Their support is tremendous. I had correspondence with them for a month, and I hadn't even purchased the product. They sent me patches and workarounds for little annoyances I found with the SCC module. Top notch company...and at $600/seat (and no hidden costs) pretty decently priced too. Course, the $600/seat curve quickly outpaces the $0/seat curve. Tough to argue with a line of slope 0. Jesse