• Centralized Version
Central, authoritative repository
All changes saved in one single
• Distributed Version
Everyone has their own repository
You get the safety net of frequent
check-ins without having to worry
about „breaking the build‟.
Clients can make changes in the
repositories and those changes will be
local to them unless they synchronize
with someone else.
Depending on the requirements, Git
also offers a centralized repository
SVN Dataflow Git Data Flow
Online Source Control
User must be online in order to
commit to the repository from
the working copy.
Offline Source Control
Clients can commit changes to their
localized repositories as new
revisions even while being offline
Longer time to store
because all of the
data is stored in a
Complete copy of the data is stored
locally in the client‟s system
Very less network
SVN help is more
There is some time wasted
since it is difficult to get a
quick reference from Git’s
More Storage Space
Two copies of a file in the
working directory of SVN
One copy is used for storing the
actual work while the other copy
hidden in .svn/ contains the
information used to aid operations
(status and commit)
When there are a lot of
documents, there is a huge impact
on disk space in the SVN
compared with Git
Less Storage Space
Has an efficient memory because
the data‟s file format is compressed
Git has a small index file to store the
info related to a particular file
Creating and working
on branch/Merge is
complex and difficult
Simple and Easy to use branch and
The working directory of a developer
is itself a branch.
Data is lost when simultaneous
commits of two or more working
copies are performed
Large number of users can put data to
the same repository
No need to worry about data lost or
immediate merging of others changes
The facility to merge data is also
there in SVN, but it is somewhat
SVN merge records seem to miss
some of the important details that
Git keeps track of.
Users to have control over the merging
of data in synchronized repositories.
Merges are always pulled by someone
and nobody can push to commit
merges in someone else’s repository.
SVN keeps record of files
File history is lost on renaming
Fixed by giving a file unique
long lived id
Git keeps track of contents.
Even a small change in content it tracks
it as a separate change.
Git needs a global check of the project
to determine changes
Checkouts at subdirectory level
Only Full Checkout
Git will not allow you to checkout a
Instead, the user will have to checkout
the whole repository.
Simpler to learn
• create, commit and checkout
Single central "master-repository”
Two modes of creating repositories
• checkout vs. clone
• commit vs. push.
You have to know which commands
work locally and which work with "the
Git has more concepts and more
many Git commands are cryptic, and
error messages are very user-
Projects using SVN Projects using Git
Steep Learning Curve
Mercurial's terminology and
commands are closer to
Subversion and CVS,
Easier to migrate
Flat Learning Curve
The volume can be intimidating to
Clean Windows Support
Mercurial is Python based
The official distribution runs cleanly
under Windows (as well as Linux,
Mac OS X, etc).
Indirect Windows Support
Git has a strong Linux heritage
Official way to run it under Windows
is to use cygwin
Not so ideal from the perspective of a
A MinGw based port of Git is gaining
popularity, but Windows still remains
a “second class citizen” in the world
Client Storage Management
If a branch is in the local repository,
then all of its revisions (back to the
very initial commit) must also be
Client Storage Management
Git allows previously pulled branches
to be discarded.
Git also allows old revision data to be
pruned from the local repository
(while still keeping recent revision
data on those branches).
Slightly slower Branching
Branching, merging and tagging
systems are equally powerful and
only slightly slower.
Faster Branching , but…
Suffers irregular heavy performance
Bob clones this repo, and ends up with a complete, independent, local
copy of Alice's store and a clean checkout of the tipmost revision d in his
Creating Branch and Merging in
Limited Number of Parents
Allows only two parents.
Unlimited Number of Parents
Git supports an unlimited number of
parent revisions during a merge
Mercurial does not require any
A lot less sophisticated with
respect to managing the clients
Git requires periodic maintenance of
Need to run the commad git -gc
The Manual of Git Says : “Users are
encouraged to run the above
mentioned task on a regular basis
within each repository to maintain
good disk space utilization and good
Structured more as an ever-
growing collection of objects
whose state cannot be changed
after they are created
Histories can be
Git is extremely powerful, and will do
almost anything you ask it to.
Unfortunately, this also means that
Git is perfectly happy to lose history.
For example,the command
can result in revisions becoming lost
in the remote repository.
GOOD HTTP SUPPORT: Mercurial
has very good support for HTTP
based stateless pushing and pulling
of remote repositories.
Less number of client – server calls
All of the relevant information is
bundled into a single large transfer.
Git includes support for HTTP pulls
(and WebDAV pushes), but the
implementation assumes that the
server knows nothing about Git.
It is designed such that you can have
a Apache simply serve the Git
repository as static content.
This method requires numerous
synchronous round trip requests
The following Web sites provide free source code
hosting for Git repositories
In terms of implementation effort,
Mercurial has a clear advantage
due to its efficient HTTP transport
Much faster if the team size is not
Eclipse supports Mercurial with
the MercurialEclipse plugin.
In terms of features, Git is more
powerful, but this tends to be offset
by it being more complicated to use.
Social coding : Popular and More
suited for shared open source project
involving many users.
Eclipse supports Git with
the EGit plugin.