Git vs. Mercurial

Personally I'm more a fan of Git with the main reason being: Branching.

As far as I know Git still has problems handling Windows which is something Mercurial has never had to worry about. But since i am not a windows user (lover, or any other positive opinion holder), i don't really care.


Git

Pros
Lots of features
More hosting options.
Faster - slightly.
GitHub.
Solid local branch support.

Cons
Poor Windows support
Rubbish logo
Silly, long SHA1 hash of revisions.
You need to keep 'packing' the repo
History fiddling.


Mercurial

Pros
Portable
Its built with Python
Easily extensible using Python
Cool logo
Better documentation.
Local integer revision numbers on top of the SHA1
No need to keep packing/optimising.
Smaller repo footprint.
Better patch support (bundles and such)
Easy to learn.

Cons
Smaller feature set.
Few 3rd party hosting options.
Fewer 3rd party apps and plugins.
Smaller community.
Slower development.


Who Uses What

Mercurial
Mozilla
OpenSolaris
Aptitude
Netbeans
Dovecot

Git
Ruby on Rails Core
Linux Kernel
Google Android
Beryl
Fedora


Who Needs What
Mercurial is great for people who want to dive into distributed version control and get busy. Its clean, fast and easy to learn.

Git is for those who wish to fully exercise the benefits of source control and avoid the down's often happen when collaborating code.

A little bit abot Git

Distributed Nature

Git was designed from the ground up as a distributed version control system.

In a distributed version control software like Git every user has a complete copy of the repository data stored locally (a.k.a a local working copy), thereby making access to file history extremely fast, as well as allowing full functionality and access when disconnected from the network. It also means every user has a complete backup of the repository. If any repository is lost due to system failure only the changes which were unique to that repository are lost. If users frequently push and fetch changes with each other this tends to be an incredibly small amount of loss, if any at all.

In a centralized VCS like Subversion only the central repository has the complete history. This means that users must communicate over the network with the central repository to obtain older versions for a file, Backups must be maintained independently and if the central repository is lost due to system failure it must be restored from backup and all changes since that last backup are likely to be lost. (Depending on the backup policies).

Access Control

Due to being distributed, you inherently do not have to give commit access to other people. Instead, you decide when to merge what from whom.

Branch Handling

Branches in Git are a core concept used everyday by every user. In Subversion they are almost an afterthought and tend to be avoided unless absolutely necessary.

The reason branches are so core in Git is every developer's working directory is itself a branch. Even if two developers are modifying two different unrelated files at the same time it's easy to view these two different working directories as different branches stemming from the same common base revision of the project.

So than Git:

• Automatically tracks the project revision the branch started from.
  • Knowing the starting point of a branch is necessary in order to successfully merge the branch back to the main trunk that it came from.
• Automatically records branch merge events.
  • Merge records always include the following details:
  • Who performed the merge.
  • What branch(es) and revision(s) were merged.
    • All changes made on the branch(es) remain attributed to the original authors and the original timestamps of those changes.
  • What additional changes were made to complete the merge successfully.
    • Any changes made during the merge that is beyond those made on the branch(es) being merged is attributed to the user performing the merge.
  • When the merge was done

  • Why the merge was done (optional; can be supplied by the user).

• Automatically starts the next merge at the last merge.
  • Knowing what revision was last merged is necessary in order to successfully merge the same branches together again in the future.

Performance

Git is extremely fast. Since all operations (except for push and fetch) are local there is no network latency involved to:

• Perform a diff.
• View file history.
• Commit changes.
• Merge branches.
• Obtain any other revision of a file (not just the prior committed revision).
• Switch branches.

Space Requirements

Git's repository and working directory sizes are extremely small when compared to SVN.

Simple install Git on Leopard


mkdir -p ~/Downloads/src
cd ~/Downloads/src

# Set options since we don't have GNU gettext installed
export TCL_PATH=`which tclsh`
export NO_MSGFMT=1
export GIT_VERSION='1.6.0.2'

# Get and install git
curl -O "http://kernel.org/pub/software/scm/git/git-$GIT_VERSION.tar.bz2"
tar xjvf "git-$GIT_VERSION.tar.bz2"
cd "git-$GIT_VERSION/"

# When on Mac OS X
./configure
make
sudo make install

cd ..

# Install Man Pages
curl -O "http://kernel.org/pub/software/scm/git/git-manpages-$GIT_VERSION.tar.bz2"
sudo tar xjv -C /usr/local/share/man -f "git-manpages-$GIT_VERSION.tar.bz2"



Stepping Up: Migrating from an SVN to a Git repository

pull the svn history into a new git repository:

* mkdir project_name.svn
* cd project_name.svn
* git svn init path/to/svn/repo —no-metadata
* echo “svn_username = Real Name ” > users.txt
* git config svn.authorsfile users.txt
* git svn fetch

make an svn-free git repository:

* mkdir project_name.git
* cd project_name.git
* git init
* git remote add origin path/to/git/repo
* git pull project_name.svn
* git push origin master

yippie!

Free SVN/Git Hosting Services

Anyone who is not using any source control of what so ever, please never come back to this blog.
Now, seriously... you have to protect your work and efforts from evil nature (yap, coffee on the MacBook) damaging your precious work.
The conventional way is to get a personal server somewhere and install the source control of your choice on it, and giddie up, but for those of use who are still poor entrepreneurs with no wish what so ever to buy a server somewhere, here are some few options to consider when choosing a source control platform for your application.

Unfuddle - Nice, remindes my of Zoho for some reason . Web 2.0 to the max and packed with project tracking and management such as issue tickets, source control, time tracking, milestones and etc. (but still not a replacement for BaseCamp, but that's for another post), Their free package comes with 250Mb, support for infinite repositories on both Git and Subversion.

Assembla - only a small part of a feature-packed project management service, a basic 200Mb of SVN hosting. the project hosting comes with wiki pages, blogs, etc. The free package has all of this so even if you don’t stump up the $49 p/m for the paid you’ll get one hell of a service.

OpenSVN - One of the first to release free SVN hosting of open source projects and starting to show its age with a very clunky interface and barebones features. free but a trouble maker, i got a lot of 404s and peer resets during commits.

Bounty Source - Bounty Source offer your basic SVN along with a wiki and CMS for managing your projects online presence as well as a task tracker. Bounty Source have a unique feature though that enables a developer to be paid for the work they carry out on user feature requests.

SourceForge - Ya baby, the real deal, an old and great dino indeed. They tried to shot it up with some Web2.0 gradients and curves, but it still looks like Geocities in 1998 :)

Google Project Hosting - someone said gSourceForge? Google shamelessly (as for my opinion) simply took that old dino, and painted it blue :) . its features still lack and it is basically what i call an "executed to finish" job, like "yes, we at google now have a source tracker and such, but we didn't put to much work in it".

i personally moved from OpenSVN to unFuddle a few days ago, and i am very pleased at the moment.