Git and Mercurial

Solution 1:

Some time back google did an analysis of Git and Mercurial. You can read it online on

http://code.google.com/p/support/wiki/DVCSAnalysis

(according to a comment this may be related to the above dead link; since comments are volatile, I am editing it into the answer)

Solution 2:

You may want to read this question on stackoverflow:

What are the relative strengths and weaknesses of Git, Mercurial, and Bazaar?

---

Solution 3:

Git and Mercurial have more in common than they differ. Both are excellent.

I use Mercurial and have no experience with Git. From friends that use Git I hear that it takes some getting used to, but after that it's awesome.

Windows support... I believe there are GUI front ends for both. Mercurial is written in Python, so no problems there.

---

Solution 4:

Here's an article about distributed SCMs by Eric Sink:

Mercurial, Subversion, and Wesley Snipes

---

Solution 5:

For a sysadmin, I believe backwards compatibility, stability, robustness, security, and backup are important topics then it comes to deploying a new tool. I can give you some information about Mercurial:

• Backwards Compatibility: Mercurial has a stated policy on backwards compatibility. The rules say that different versions of Mercurial must always be able to talk to each other over HTTP(S) and SSH.

  This means that you can safely upgrade clients without upgrading the server at the same time. You can also do the opposite and upgrade the server alone, but this is normally much less important since new features show up in the clients and often wont require anything from the server.

  The on-disk format sometimes change — we've had 4 changes until now. When that happens, old clients will refuse to operate on the repository on disk (but remember that they can still push/pull over the network). New clients can still read/write old repository formats and will never automatically upgrade an existing repository to a new format in case the repository is shared with an old client over, say, NFS. All in all, we try to make upgrades painless.

• Output Stability: This is closely related to the above. As part of the compatibility rules, we also ensure that the output of Mercurial is stable. This means that the shell scripts you write today, will continue to work tomorrow.

• Robustness: Like Git, changesets are identified by a cryptographic hash value that is computed over each change and the parent changesets. This makes it infeasible to change any part of the history without it being noticed. The hashes are verified every time a file is checked out.

  Mercurial repositories consist of a lot of revlog files. They are designed to be append-only, which makes it possible to repair some forms of hardware corruption by simply truncating the files. You can always use hg verify on a repository to make Mercurial double-check that everything is as it should be.

• Security: When repositories are hosted using SSH, all the normal rules for access control applies — Mercurial is not doing anything special. So if I can log in and read the files in your repository, then I can also make a clone. If I also have write access, then I can push to the repository. Managing this is therefore easy: just setup a group and make sure that new files are made writable by the members of the group.

  When hosting with HTTP(S), it is the front-end webserver that handles authentication. We provide a CGI (with FastCGI, WSGI, and ISAPI flavours) that interacts with the repository, but the script is not doing authentication. This means that it's easy to integrate Mercurial with existing setups: if you're already using Active Directory to authenticate users, then you're all set for using AD with Mercurial. See this question for more about AD and Mercurial.

  Finally, instead of using the hgweb CGI script we supply, you can use something like RhodeCode. That is discussed further in this question.

• Backup: With the append-only design, you can almost just copy a "live" repository to make a backup. However, it can happen that you get too much data that way since a backup program might copy the "changelog" before it copies the "manifest", whereas Mercurial writes the manifest before it writes the changelog. The changelog references the manifest, so the backup will end up with an un-referenced entry in the manifest. Running hg verify will detect this and hg recover can rollback the incomplete transaction.

  The proper way to do backups is to use hg clone. That will make sure to copy a consistent snapshot, even when people are pushing data into the repository while the backup is running. Since you can clone over the network, you can easily send the data to an off-site machine for safe keeping.