Mercurial and Git are both distributed version control systems that allow developers to work offline and synchronize changes later. Some key differences are: - Git has a steeper learning curve due to more commands and concepts, while Mercurial's model is closer to Subversion and easier to migrate to. - Mercurial has cleaner Windows support as an official Python distribution, while Git has stronger Linux heritage and Windows support through third parties. - Git allows discarding old branch data to optimize disk usage, while Mercurial requires keeping all revision history locally at all times. - Both systems effectively support branching and merging, though Git can have irregular performance drops and Mercurial branching is slightly slower. Overall, Mer

1. - SEARCH FOR THE BEST RCS
vs vs
Vinoth Kumar Kannan
Vinoth.kannan@widas.de

2. THE NEED
Why do we need a Revision
Control System(RCS) ?
• Storing
• Retrieval
• Logging
• Identification
• Merging of revisions

3. THE CHALLENGERS
Apache Subversion
- Centralized version control system
Mercurial
- Python Distributed version control system
- Linux based Distributed version control system

4. MATCH 1

5. • Centralized Version
Control Systems
(DVCS)
 Central, authoritative repository
 All changes saved in one single
location
 Client-Server approach
• Distributed Version
Control Systems
(DVCS)
 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

6. SVN Dataflow Git Data Flow
Working
Dir
Remote
Repository

7. 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

8. Longer time to store
because all of the
data is stored in a
centralized repository.
 Extremely Fast
Complete copy of the data is stored
locally in the client‟s system
 Very less network
response time

9.  SVN help is more
organized
 There is some time wasted
since it is difficult to get a
quick reference from Git’s
search.

10. 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

11. Creating and working
on branch/Merge is
complex and difficult
to use
 Simple and Easy to use branch and
Merge
 The working directory of a developer
is itself a branch.

12. Sequencial Commits
 Data is lost when simultaneous
commits of two or more working
copies are performed
Non-Sequencial Commits
 Large number of users can put data to
the same repository
 No need to worry about data lost or
immediate merging of others changes

13. Merge
 The facility to merge data is also
there in SVN, but it is somewhat
incomplete
 SVN merge records seem to miss
some of the important details that
Git keeps track of.
Merge
 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.

14. Revision Tracking
 SVN keeps record of files
 File history is lost on renaming
 Fixed by giving a file unique
long lived id
Revision Tracking
 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

15. Particially Checkout
 Checkouts at subdirectory level
are possible.
Only Full Checkout
 Git will not allow you to checkout a
subdirectory.
 Instead, the user will have to checkout
the whole repository.

16. Simple usablity
 Simpler to learn
• create, commit and checkout
 Single central "master-repository”
Complex usablity
 Two modes of creating repositories
• checkout vs. clone
• commit vs. push.
 You have to know which commands
work locally and which work with "the
server“
 Git has more concepts and more
commands.
 many Git commands are cryptic, and
error messages are very user-
unfriendly

17. Projects using SVN Projects using Git
BitBucket
Gitorious
Codeplex

18. MATCH 1 RESULT
3 : 7

19. VIDEO
http://www.youtube.com/watch?v=_yQlKEq-Ueg&feature=player_embedded

20. MATCH 2

21. Steep Learning Curve
 Mercurial's terminology and
commands are closer to
Subversion and CVS,
 Easier to migrate
Flat Learning Curve
 More commands
 More options
 The volume can be intimidating to
new users

22. 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
Windows user
 A MinGw based port of Git is gaining
popularity, but Windows still remains
a “second class citizen” in the world
of Git.

23. 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
present
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).

24. Slightly slower Branching
 Branching, merging and tagging
systems are equally powerful and
only slightly slower.
Faster Branching , but…
 Slightly faster
 Suffers irregular heavy performance
drops

25. 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
working directory:
Creating Branch and Merging in
Mercurial (1)

26. Creating Branch and Merging in
Mercurial (2)

27. Creating Branch and Merging in
Mercurial (3)
Pull
Merge
Commit

28. Creating Branch and Merging in
Mercurial (4)

29. Limited Number of Parents
 Allows only two parents.
Unlimited Number of Parents
 Git supports an unlimited number of
parent revisions during a merge

30. No Maintenance
 Mercurial does not require any
maintenance.
 A lot less sophisticated with
respect to managing the clients
disk space
Needs Maintenance
 Git requires periodic maintenance of
repositories
 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
operating performance.”

31. Immutable History
 Structured more as an ever-
growing collection of objects
whose state cannot be changed
after they are created
Histories can be
changed….
 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
git-push --force
can result in revisions becoming lost
in the remote repository.

32. Integration
 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.
Integration
 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

33. Fans Fans
The following Web sites provide free source code
hosting for Git repositories

34. Summary
 In terms of implementation effort,
Mercurial has a clear advantage
due to its efficient HTTP transport
protocol.
 Much faster if the team size is not
large
 Eclipse supports Mercurial with
the MercurialEclipse plugin.
Summary
 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.

35. SCREENSHOT OF TORTOISE HG GUI
CLIENT HISTORY

37. MATCH 2 RESULT
? : ?

38. WHO DO YOU THINK WON?

39. • Reference
 http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
 http://code.google.com/p/support/wiki/DVCSAnalysis
 http://www.ericsink.com/entries/hg_denzel.html
 http://www.rockstarprogrammer.org/post/2008/apr/06/differences-
between-mercurial-and-git/
 http://en.wikipedia.org/wiki/Mercurial
 http://www.wikivs.com/wiki/Git_vs_Mercurial