The main criteria here being that whatever system you decide on it must: make branching and merging feel almost trivial to you, have a command set that's easy and flexible, and allow multiple people to work on the same file at the same time. If your system can do all that and you and your coworkers are happy with it then don't change.
I'm going to stick my neck out here and suggest that you really ought to be using a distributed version control system. I don't care if you have a development team of one or one thousand. Traditional version control systems that work like CVS and Subversion are good. But, you're missing out on some truly great features if you stick with them.
The leaders, at the moment seem to be Darcs http://www.darcs.net, Git http://git.or.cz/, Mercurial http://www.selenic.com/mercurial/, and Bazaar http://bazaar-vcs.org/. Darcs has the advantage of a very well thought out set of commands, each with an corresponding undo. Git is being used to manage the Linux kernel and has some significant performance benefits. Mercurial is being used for the open source version of the Java Development Kit. Bazaar is being used to manage the Samba project but not much else of note. They're all conceptually fairly similar but each has taken a very different approach in their respective implementations. Darcs is written in Haskell, Git is written in C and leverages a variety of shell scripts, which means it doesn't work very well under Windows, and Mercurial and Bazaar are written in Python. All have Eclipse plug-ins in various stages of development.
It was my intent to discuss all the reasons that distributed version control systems are great here, but it turns out I've already discussed the feature that I find most advantageous above: branching. And, Mark Reinhold has summarized the high-points quite well with this:
Something Mark doesn't mention is the huge advantage a distributed VCS has for open source projects. If Mozilla has taught us anything it's that you're not going to get thousands of developers working on your project. So, while huge numbers of developers is something that distributed VCS handle exceedingly well it's pretty much a moot point. In my experience, a developer interested in some OSS (Open Source Software) project will download the source from a traditional VCS, poke around to understand it, and, if they're smitten with the idea, start customizing it for their needs. But, they are forced to either work without the benefits of version control or they have to check it into their own personal VCS. If they check it into their own the projects main developers can pretty much forget about ever getting patches from them because they're no longer able to sync with your tree and it would be way more work than they generally want to do to get synced and give you a patch that was useful. If they work without VCS (because they don't have commit rights to your VCS) they may send in a patch but the work to get there has been like climbing a rock face without lines and harnesses.
If the projects developers were to use a distributed VCS each developer would be working off of their own personal copy of it that could be synced at any point in time no matter how many changes, revisions, or commits they have made. They're generally not going to check it into their own VCS system because that's work that doesn't get them any real benefit because they already have version control via their checkout and the fact that it's a distributed system. The end result is that they don't need to work without the safety and security of an VCS and they will generally always be working on a system they can easily send you changes from when they're ready.
K. Rhodes 2007-05-18