I am about to start a project and was thinking of using Google Code to host it. It gives the option of using Mercurial or SVN for version control. I have never before used a VCS, and would like to know which one is easier to work with.
The project involves two main programmers, but a few others may contribute small amounts. It is mostly in python and we use Emacs as the primary editor. We are both using the Windows operating system.
If you've never used a VCS before, choose either. Both will more than suffice for your needs, and you'll have to learn either from scratch.
Mercurial is decentralised like git, but I wouldn't worry about that too much for a 2 programmer team, who've never been exposed to source control.
Pick either and forget about it.
Well, I think you should use SubVersion. Not because SVN is somehow better than Mercurial in functional terms, but because SVN is very popular and there is a lot of documentation for it (e.g. a free eBook) as well as some very good free plugins (AnkHSVN for VS, TortoiseSVN for Windows Explorer). I think the documentation will quickly get you up and running, if you've never used a VCS before...
HTH!
The Simple answer is SVN - fire up TortoiseSVN and TortoiseHg and you'll see that the former is some distance ahead of the latter in terms of aesthetics and usability however I don't think that the simple answer is good enough in this case.
If you're going to start using version control for the first time I'd be tempted (for all that I'm currently far more comfortable with SVN than Hg) to suggest that Mercurial is the better way to go. Distributed Version Control (DVCS) currently offers more flexibility than Subversion does with its dependency on a central repository. In particular your ability to commit locally code that is not complete prior to pushing completed changes to your colleagues. Mercurial has a "book" so you've got a set of guidelines to work from and it has general acceptance as a tool so peer support is available.
My principal concern with DVCS is that I regard version control as being incomplete without a separate server (or at least without a repository not on your dev box) for various reasons. However in this case you will have a central repository... so that argument is less valid.
I have a secondary issue that I think that one should be aiming to introduce a Continuous Integration server (build and test) into one's projects at the earliest opportunity but again that's something that can be done with DVCS given the shared/central repository.
I still think that SVN has a lot to commend it, our work repository is and will remain SVN for the foreseeable future (note that I'm the one that gets to decide!), but equally I'm doing my personal stuff with Mercurial and learning as I go.
If you have never used a VCS, you will probably have a hard/easy time with either one. I don't think there's principle differences in that. An important difference between these two, however, is that SVN is centralized and Mercurial is decentralized.
If you work from where you have no network access (planes, trains etc.), a decentralized VCS will allow you to commit your changes locally before you start on new changes. Later you synchronize with the central repository. This can be handy.
A centralized VCS does not allow this. You can, of course, still work on your code, but since you cannot check in between changes, you will have to commit the accumulated changes at once when you are back to having access to the repository.
Use Mercurial.
Both systems will be easy, but Mercurial will be fast. Want to compare the differences between what someone else did last night and what you did last night? With SVN that's going to take a couple of seconds per file while it talks to Google's servers. With Mercurial it will be pretty much instant.
A couple of seconds per diff might not sound like a lot, but the benefits of a snappy, responsive interface will become apparent once you use a system that eliminates (most) of those pauses.
Oh, and people can fork your project without it being a huge pain in the ass. That's pretty cool too.
EDIT: Mercurial also doesn't feel the need to slap a .svn folder in every single folder in your project. Those things are ugly (and not hidden by default on Windows, like they would be on *nix system). There will just be one .hg folder at the root of your project, which is much cleaner.
EDIT: One more reason to use Mercurial: hg bisect. Tracking down a bug in 10 minutes instead of 2 hours because you were able to find the exact revision that caused it is awesome. It looks like there's a Perl svn-bisect tool but it's not in the core, and SVN's slowness in updating between revisions will make it a much longer process.