StackOverflow (stackoverflow.com) is a more appropriate place for this, though I'm not sure they're any more in favor of discussion-based questions with no clear answer than ServerFault.
–
sh-betaMay 27 '09 at 19:53

1

well, scm is normally used by developers, but system admin uses them for deployment as well. that's why i've asked the question here.
–
Michael Ellick AngMay 27 '09 at 21:37

First, either one is going to be a huge step up from older systems - there's really not a bad option.

Git is a little harder to use but noticeably faster and arguably more powerful.

Mercurial is friendlier and - thanks to TortoiseHg - much easier to use on Windows.

In either case you have the option of excellent hosting (GitHub, Bitbucket, eventually Google Code), lots of guides and migration tools from other systems. If you need Windows users, I'd recommend Mercurial - otherwise it'd probably make sense to try both and see which one you prefer. I find Mercurial more comfortable but Git isn't that far behind and has some scary-cool features (i.e.rebase -i).

Unless you have very peculiar requirements, I would say that for 99% of the time both are very good at doing what you need.

I heard that Git windows support wasn't good (i.e., requires Cygwin which most windows dev do not have) but after seeing a demo of TortoiseGit I would say it's not true anymore.

Also I heard that you can obliterate files/dirs in Git easily and not in Mercurial but I just found that with convert --filemap it's easy as well! Also extensions in shell or Python can be very powerful (to create commands etc.) and the Queue extension allows to clean history by rebasing, like in Git.

In summary differences tend to get smaller: have a look at both and choose which ever, they are both good. If you already know subversion for example, Mercurial might be easier to handle as the similar commands do match more than in Git.

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.