Head to head comparison between
SVN – GIT – MERCURIAL
Author: Animesh Das <animeshdas@yahoo.com>
SUBVERSION (aka SVN)
Offers a centralized repository
model. In other word SVN is one
repo and lots of clients.
Easier to use. Simple thus have
lesser features.
The process of starting a new
project in SVN is still sort of a
pain - importing, then exporting
the project, etc. Also managing
a SVN repository too.
Written in mix of C and Perl
SVN is old-school and is around
much longer.
Being older, already tons of
tools available.
SVN cannot not handle huge and
complex project due to its
branching and merging model in
use.
With SVN, everyone has a
working copy and changes are
committed to a central
repository. To work on a branch
a user must copy the trunk into
another directory and then
merge it back when complete.
With Subversion, you have to
create every branch remotely on
the server. This can get messy
depending on the size of your
team. If you decide to control
branching to keep things clean,
you forfeit the power branching
offers.
GIT
Decentralized distributed repository
model. GIT is a repo with lots of client
repos, each with a user.
Learning Git can be a bit daunting.
But once learned has much power,
flexibility and features than other has
to offer. With a GUI, it much easier
now.
Very straight forward.
Purely written in ANSI C.
Git is the new kid on the block,
already cached much attention. And
Git deserves it’s popularity.
Despite being young, already have
some good tools available for day to
day work in Windows.
GIT is fast and excellent for managing
large e or/and complex projects with
a complex/simple lifecycle with
many/few collaborators
With GIT, everyone has their own
copy of the entire repository.
Basically, everyone is always working
on their own branch and functional
code can later be merged into the
master. So, people can track their
own edits locally without having to
push things to an external server.
In Git, with each branch, no new files
are created in the project file
hierarchy on your system. Since you
have a full local repository, Git
creates the files you need on the fly
by processing the recorded changes.
To understand the core difference of
branching, merging and patch
between GIT and Mercurial ones must
read
http://stevelosh.com/blog/entry/2009/
8/30/a-guide-to-branching-in-
Mercurial (aka HG)
Decentralized distributed
repository model. HG is a
repo with lots of client
repos, each with a user.
Short learning curve, as the
command set are similar to
SVN and CVS.
Very straight forward.
Written in Python, thus
have more flexibility of
adding new plugins, code
changes.
Mercurial -another big
distributed system that's
out there (both were
created as a result of the
BitKeeper debacle) for
quite some time now.
Mercurial being written on
Python is cross platform
and modular.
Same as GIT.
Same as GIT
Mercurial also better allows
differences between the
HEAD branch (aka tip) and
your current working
directory state—you can
push into a repository with
a working directory without
confusing Mercurial; not so
with Git. This means
collaboration in Git requires
a third copy of the
repository for collecting
commits (or requires that

With Subversion, it all hits the
server.
With Subversion, you still have
the old copy until you update.
You either have to clean up
manually, or “update” to clean
up local and remote copies.
With Subversion, you’re literally
just working on a separate set of
files. Ultimately, it’s up to you
to manage retrieving and
editing these files.
Stashing temporary work, the
Subversion method is simpler,
but you could potentially end up
with several half-baked
branches and no record of when
you abandoned them.
Collaboration before public
commits, with Subversion, it’s
all on the server, all the time.
SVN has so many client
available on different platform.
Specially in Windows it has
excellent client like TortoiseSVN.
Subversion server has native
ports to many OS. Have rich
client on different platform.
mercurial/#conclusion repositories be updated
only by pull).
With Git, we only push our work to Same as GIT
the server AFTER collaboration.
Again, no file system work. Since Same as GIT
we’re using a local repository, we let
Git handle the details of removing the
branch.
The key thing to note in this and Same as GIT
every step is how we switch between
branches. In Git, the repository
handles this.
Git will “float” uncommitted changes. Same as GIT
This means that if simply did a “git
checkout C,” you’d bring with you all
of the uncommitted work you did for
A. However, you don’t want to
commit A because it’s not in a good
working state. Instead, you “stash”
your work. Stash is like a work in
process commit. Using it will tuck
away your WIP changes without a
formal commit, which allows you to
change to C without “floating” any of
your A changes. Git’s stash allows
you to list all stashes, and even write
a message when you stash. It is far
more powerful in this scenario.
Git has a nice feature to create Does not have this feature.
“patches.” They are simply changes
to code, very similar to a diff. The
idea is that you create patches from
commits you’ve only made on your
local copy of the repository. When
your co-worker sent you the patch for
E, no one else on the team had to see
his commit logs, branches, etc., in the
public repository because they never
existed there. You are collaborating
about E via emailed patches.
The problem is the Windows-aimed TortoiseHG is as much as
GIT client market is still pretty small. powerful as ToirtoiseSVN. It
But still GIT ships with a basic GUI for has big client list for almost
day-to-day work, and for anything all platform.
advance(mostly required for repo
admin) you need to get into CLI.
There are some people working on a
Tortoise port for GIT and it is already
stable enough for normal daily work.
It was originally heavily written for Platform independent.
POSIX platform. But it work on other
platform on top of POSIX emulation
layer. One of the Google Summer of
Code projects was to replace much of
these scripts with more portable (and
faster) C code. It’s quite possible that
the upcoming 1.5.4 or 1.6.0 releases
mean native Git on Windows.
SVN cannot be used over GIT
repository.
SVN has limited set of
functionality and the branching
merging hits performance and
becomes bottleneck for growing
repository.
SVN is more suitable for small
team and projects.
In subversion, revisions are
increasing integers, this is a
pain.
Takes more diskspace.
SVN is slow, speacially
branching, merging large repo
Works on top of Apache as
module. Also has svn over SSH
server.
Commits are atomic.
Renames are supported.
One can use GIT over SVN repository.
Git has excellent Subversion front-
ends. You can mirror an existing SVN
repository (say, the official version
control system at the office) into Git,
develop using all of Git’s tools, then
push changes neatly back into
Subversion and Perforce.
GIT is very powerful in this area.
Compared to Mercurial, branching
with Git is much easier. It is much
easier to use topic branches or git-
stash to arrange (and re-arrange)
commits and do small fixes. Git’s
view of branch heads as simply
pointers to some commit on a commit
graph and its constant tracking of
your commit history with reflogs
around allows you to develop without
fear of losing your work, even when
arranging things so that your
published history is pretty.
Suitable for both small and large,
team and project.
Git revisions are marked as SHA-1
hashes. Thus, if you want to do a diff
between two revisions, you have to
use long, non-user friendly hashes.
Takes lesser diskspaces. Its delta-
against-parent model reduce 50%
space consumption.
GIT is very very fast even with very
large repository.
Git uses a special protocol that runs
over a dedicate port, making it
somewhat less firewall friendly.
Commits are atomic.
Renames are supported for most
Mercurial has hgsvn and its
documentation suggests
that it can’t push changes
back into Subversion;
When developing features,
one would use Mercurial’s
patch queue extension to
develop features pieces
until they were ready to
commit. I would edit the
series file manually to
rearrange commits, in
particular to push out small
bug-fixes. Thus in
Mercurial, (in around
version 0.9.4), branches in
a single working tree were
still somewhat confusing
and hard to use.
Suitable for both small and
large, team and project.
Mercurial uses SHA-1
hashes for revisions, too, it
also assigns local integers
as aliases to the SHA-1
hashes. This means you
can still do things like hg
diff -r53 -r60. Because
these are local aliases only,
revision 53 on one
repository is not necessary
the same as revision 53 on
another, cloned, repository,
though. You’ll have to use
the full SHA-1 hash, which
is unique among
repositories.
Compared to GIT, it takes
little bit more diskspace
but quite lesser than SVN.
Mercurial is fast too, but
not as GIT is. Mercurial
team is constantly working
to gain performance boot
in this area.
Mercurial makes it
extremely easy to serve up
a repository, without
requiring starting a
daemon on any special
ports. hg serve is all you
need and you can
efficiently clone a Mercurial
repository over HTTP;
Commits are atomic.
Renames are supported.

SVN does not support Intelligent
Merging after Moves or
Renames. "svn help me" says
"Note: this subcommand is
equivalent to a 'copy' and
'delete'." There's a bug report
about it.
Support File and Directory
Copies and it's a very cheap
operation (O(1)) that is also
utilized for branching.
Indirectly support of Remote
Repository Replication, by using
Chia-liang Kao's SVN::Mirror
add-on or Shlomi Fish' SVN-
Pusher utility.
Support Propagating Changes to
Parent Repositories, using either
Chia-Ling Kao's SVN::Mirror
script or the svn-push utility by
Shlomi Fish.
The WebDAV-based service
supports defining HTTP
permissions for various
directories of the repository.
Subversion have partial
Changesets' support. There are
implicit changeset that are
generated on each commit.
Support Tracking Line-wise File
History
There is no such feature as Per-
File Commit Messages
Documentation is very good.
There is a free online book and
some online tutorials and
resources. The book is written in
DocBook/XML and so is
convertible to many different
formats. The command-line
practical purposes. Git even detects
renames when a file has been
changed afterward the rename.
However, due to a peculiar repository
structure, renames are not recorded
explicitly, and Git has to deduce them
(which works well in practice).
Git does not have Intelligent Merging
after Moves or Renames. As detailed
in the Git FAQ: "Git has a rename
command git mv, but that is just a
convenience. The effect is
indistinguishable from removing the
file and adding another with different
name and the same content."
No, It does not support File and
Directory Copies
This is very intrinsic feature of Git.
Yes. (The Linux kernel development
process uses this extremely often)
See contrib/hooks/update-paranoid
that ships with Git. See the path_rules
code for the closest equivalent to
svnperms. Not straight forward.
Yes, Changesets are supported, and
there's some flexibility in creating
them.
Support Tracking Line-wise File
History. Also, branches are very
lightweight in Git, and could be
considered a kind of storage for
"uncommitted" code in some
workflows. Also see the "git stash"
command.
Commit messages are per changeset.
Documentation is medium. The short
help is too terse and obscure. The
man pages are extensive, but tend to
be confusing. The are many tutorials.
Yes, intelligent merging
after renames is supported.
the Mercurial book says: "If
I modify a file, and you
rename it to a new name,
and then we merge our
respective changes, my
modifications to the file
under its original name will
be propagated into the file
under its new name. (This
is something you might
expect to 'simply work,' but
not all revision control
systems actually do this.)"
Yes it support File and
Directory Copies
Yes it support.
Yes it support.
It is possible to lock down
repositories, subdirectories,
or files using hooks.
Yes. Changesets are
supported.
Support using hg diff.
There is no such feature as
Per-File Commit Messages
Very good documentation.
There is a companion book
and a wiki. Every command
has integrated help.
client also provides a good
online help system that can be
used as a reference.
A Subversion service requires
installing an Apache 2 module (if
one wishes to use HTTP as the
underlying protocol) or its own
proprietary server. The client
requires only the Subversion-
specific logic and the Neon
WebDAV library (for HTTP).
Installation of the components is
quite straightforward, but will
require some work, assuming
Subversion does not come
prepackaged for one's system.
A CVS-like command set which
is easy to get used to for CVS-
users.
Networking support is very
good. The Subversion service
can use either WebDAV+DeltaV
(which is HTTP or HTTPS based)
as its underylying protocol, or its
own proprietary protocol that
can be channeled over an SSH
connection.
Portability : Excellent. Clients
and Servers work on UNIX,
Windows and Mac OS X.
Web Interface : Yes. ViewVC,
SVN::Web, WebSVN, ViewSVN,
mod_svn_view, Chora, Trac,
SVN::RaWeb::Light, SVN
Browser, Insurrection and
perl_svn. Aside from that, the
Subversion Apache service
provides a rudimentary web-
interface.
Availability of Graphical User-
Interfaces is very good. There
are many available GUIs:
RapidSVN (cross-platform),
TortoiseSVN (Windows Explorer
plug-in), Jsvn (Java), etc. Most of
them are still under
development.
In addition, try to do this scenario on your laptop while not connected to the Internet. With Git/HG, no
issues, the repository is local; however, with Subversion, you’re out of luck. Your new branches will
have to wait. The advantages of Git/HG for branching are clear in this simple branching scenario.
Both Mercurial and Git communities are working on TortoiseHg/TortoiseGit types of GUIs for Windows
users. Git appears to have a sane Windows port now as well.
Binary packages are available for
modern platforms. C compiler and
Perl are required. Requires cygwin on
Windows, and has some UNIXisms.
Command set is very feature-rich,
and not compatible with CVS.
Excellent networking support. Can
use native Git protocol, but works
over rsync, ssh, HTTP and HTTPS also.
Portability : The client works on most
UNIXes, but not on native MS-
Windows. The cygwin build seems to
be workable, though.
Web Interface: Yes. Gitweb is
included in distribution.
Gitk is included in distribution. Qgit
and Git-gui tools are also available.
But have limited GUI available till
date. Work in progress of cloning
tortoise tool to support GIT.
TortoiseGIT has release a stable
version of the GUI which is good
enough for day to day work.
Excellent deployment
functionality. Binary
packages are available for
all popular platforms.
Building from source
requires only Python 2.3 (or
later) and a C compiler.
Commandset,tries to follow
CVS conventions, but
deviates where there is a
different design.
Networking support, uses
HTTP or ssh. Remote
access also works safely
without locks over read-
only network filesystems.
Portability : Excellent. Runs
on all platforms supported
by Python. Repositories are
portable across CPU
architectures and endian
conventions.
Web Interface : Yes. The
web interface is a bundled
component.
History viewing available
with hgit extension; check-
in extension (hgct) makes
committing easier. Some
third-party IDEs and GUI
tools (e.g. eric3, meld)
have integrated Mercurial
support. Mercury now
support full blown Tortoise
client TortoiseHG.
For most uses, Mercurial and Git are more-or-less interchangeable, especially with the usability
improvements in versions 1.5 of Git and later. The most basic commands like status, diff, commit, and
log behave very similarly (at first glance). Commands execute quickly, even for large trees. Both
systems are very flexible with modules and scripts that bring most features to parity. For myself,
having learned how to work with Git, I prefer the power Git offers with fast branches and powerful tools
like reflogs and rebase. For the undecided, fortunately there are tools that convert repositories from
Git to Mercurial and vice-versa, so other than mental switching costs, there is little to fear in choosing
one or the other. I won’t be using Subversion or CVS any more if I can help it.

In conclusion, GIT or Mergurial(HG) stands out far better, robust and built keeping the requirement of
new breed of programmers and collaborated development environment in mind. And SVN is slowly
outdating. Now, please read this article to understand where GIT and Mercurial stands at this point.
http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html