Ok, I don't have a good answer, but I do have some opinions that will, hopefully, contribute to one.
Firstly your choice is between a server based system and a distributed one (DVCS).
The server based model is one that is well understood - the repository lives on the server, you checkout files locally and you commit changes back. You can do branches and tags and merges - usually without too much stress - and its all good.
DVCS is a bit more interesting - the notion of a central server is gone (which is both a good and a bad thing) instead you have local repository that you can clone (copy in its entirety) to as many places as you want on your local machine or on a remote machine. You can then push and pull changes between repository instances. This gives you a couple of advantages, its very flexible and its fast(er) no handshake between client and server. DVCS also use much finer grained diff algorithms/storage which means that they are better at merging (not perfect, been bitten by that, just better). The speed and flexibility encourages you to commit more often and the quality of merge encourages branching for distinct development strands at a very low level. Couple of problems - both significant - first is that you don't need a server and if your source code is only on one machine then you're losing one of the key benefits of VCS. Second is that there's nowhere obvious to go for the "definitive" copy - the line that's the core that you could build and deploy your live system from (because its the source for your live system). Fortunately (!) this is not exactly a hard problem to solve, you clone your repository to a server location, make that the "definitive" copy and then push completed features and fixes to that copy (and similarly pull from that copy if you want a clean set of code).
Whether you have server based of DVCS you should also consider getting a continuous integration (CI) server that builds your application(s) each time they are committed to specific branches (specific server based repositories if DVCS).
I use and can therefore recommend, I have for ages. Its good, it works and whilst yes, we've had some fun merging on occasions its very seldom been because of the limitations of SVN - more us not pulling changes over or inconsistencies in our IDE setups.
I'd also take a look at Sourcegear's Vault - http://www.sourcegear.com/vault - commercial (i.e. not free) but built by people who know what they're doing explicitly to replace SourceSafe.
I'm also playing with Mercurial which I like, a lot. I really really like the ability to do a local commit (commit early, commit often...) and the fact that it in theory it means I can commit changes that I couldn't using SVN because they would cause the build to fail. I haven't fully worked out the "server" side yet (I haven't yet got a CI server on my personal stuff) but the idea is that one commits changes locally 'til one gets to a point where one has a set that can safely/collectively be pushed to the (appropriate) server repository and its the push to the server that will trigger a build. I also need to play more with the notion of multiple concurrent development branches (kind of tricky for solo development!)
Suggesting a CI server is much easier, go for TeamCity - http://www.jetbrains.com/teamcity (I'm looking at hudson as well for my personal stuff)
Finally, opinions... I think, that if I were starting more or less from scratch, today, I would want a DVCS - for the "local" commit and the flexibility. I think they're harder to get to grips with if you have prior VCS experience but the benefits (if done right - got to be able to wire it into continuous integration) outweigh the challenges (e.g. the tooling isn't yet on a par with that for subversion - as evidenced by tortoiseSVN vs tortoiseHg).
I would probably choose Mercurial - but look at git and bazaar and fossil (and worry if you should wait for veracity...)
One last thought (I do go on) you need to think about how whatever you choose will fit into your organisation - the workflow you use get from source code in your repository to the live instance(s) of your application(s) - without a clear method for build and deploy (I deploy from builds from my CI server) you're not addressing the whole of the problem.