- SEARCH FOR THE BEST RCS

vs vs

Vinoth Kumar KannanVinoth.kannan@widas.de

THE NEED

Why do we need a Revision Control System(RCS) ?• Storing

• Retrieval

• Logging

• Identification

• Merging of revisions

THE CHALLENGERS

Apache Subversion - Centralized version control system

Mercurial - Python Distributed version control system

- Linux based Distributed version control system

MATCH 1

• 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

SVN Dataflow Git Data Flow

Working Dir

Remote Repository

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

Extremely Fast Complete copy of the data is stored locally in the client’s system

Very less network response time

SVN help is more organized

There is some time wasted since it is difficult to get a quick reference from Git’s search.

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 to use

Simple and Easy to use branch and Merge

The working directory of a developer is itself a branch.

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 

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.

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

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.

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

Projects using SVN Projects using Git

BitBucket

Gitorious

Codeplex

MATCH 1 RESULT

3 : 7

VIDEO

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

MATCH 2

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

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. 

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

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

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)

Creating Branch and Merging in Mercurial (2)

Creating Branch and Merging in Mercurial (3)

Pull

Merge

Commit

Creating Branch and Merging in Mercurial (4)

Limited Number of Parents

Allows only two parents.

Unlimited Number of Parents

Git supports an unlimited number of parent revisions during a merge

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

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.

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

Fans FansThe following Web sites provide free source code hosting for Git repositories

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.

SCREENSHOT OF TORTOISE HG GUI CLIENT HISTORY

MATCH 2 RESULT

? : ?

WHO DO YOU THINK WON?

• 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