git ­ the stupid, fast, distributed content trackergit ­ the stupid, fast, distributed content tracker

   

Why the name – 'git' ?

"I'm an egotistical ***, and I name all my projects after myself. First 'Linux', now 'git'"

   

What I'm not going to talk about

How to use git  There are plenty of resources on the net which you 

can just visit and learn about git. The internal implementations of git.

You can subscribe to git mailing list, or go through their archives, or even 'get git by git' to explore its internals.

http://git.or.cz/

   

My talk is about... 

Why we chose git over other SCMs at Therap? Looking back at our decision after using git for a 

major release. Sharing our experience with others so that they 

can replicate the sucess we had with git.

   

Therap's first SCM

First SCM Therap used was SCCS (Source Code Control System)

At that time it was not available outside commertial unix systems.

We love Linux as developer's desktop at Therap, so we chose to move to CVS.

   

Our days with CVS

Major flaw with CVS was commits were not atomic.

As around that time our repository was in US, if the internet like broke in the middle of a commit, we ended up having a partial commit.

We decided to maintain our local BD repository with TLA (GNU Arch).

   

Why not SVN?

Though SVN was a popular choice at that time, having more than one repository was not natural to SVN.

They had two type of storage, and one of them was discontinued later on. This gave us the impression of unstability of SVN and we chose not to trust it with our source codes.

   

The realm of GNU Arch (TLA) 

TLA allowed us to have two repositories easily, one at BD and another in US.

We were able to apply changes made in BD repository (branch) easily to US repositor and vice versa.

Storage of TLA was simple.

   

As our growth continued...

After three years of development, we have more than 600K lines of code and more than 5000 files that we track in the SCM.

TLA was aging. Commits and updates started to test our 

paitence.  Applying changes to US repository started to 

take around 20­30 mins!

   

We needed a better SCM

Linus's talk at Google Tech Talk inspired us. We decided, unless we try git in full scale at 

Therap, we won't figure out its strengths.

   

Starting with git

In the first week, everything seemed like a problem.

During the end of first week, a set of best practices have evolved.

By the middle of the second week, everyone seems to have gotten the hold of it and reap benifit out of git.

   

git is FAST, DISTRIBUTED, RELIABLE

Updating our repository at US now takes only around 30 seconds!

Our source code and its history is now safer than it ever was before, as we now have 30+ repositories instead of 2.

Because of the way SHA1 is used in git, a repository corruption will be detected early.

   

Branching is native in git

My branch is local at my box and if I fail at first attempt I don't have to share my codes with everybody in the development team.

Facilates branching between the team members which promotes them to do more experimental stuffs along side regular development.

   

Trust fabric is distributed in the team

git promotes the way human interact, through trust network

Team leads pull from their team members, and can push to a restricted repository, or 'Super Lead' can pull from team leads.

   

Questions

?