There's a new an very powerful model of distributed collaborative 
open source development that can be hard to understand at first. It's 
effectiveness it critically dependent on new functionality in 
distributed content-based SCM's like git and bazaar.

I'm becoming familiar with git so I want to describe how I understand 
it works here. See the end of this email for useful background and 
links.

In the git model I create a repo on my hard drive and make commits, 
branches etc.  If I want to share this I make a public git repo on a 
server and push my local git repo there.  In a star of collab (like 
svn) I add all of you to the list of people who can commit to the 
public git repo but to do this you all first clone the public repo -- 
this creates a copy of the entire repo on your hard drive. Now after 
you make changes and commit them locally you can push your changes to 
the main public repo.

That's basically just like what we do now except that each of us has 
a full clone of the whole repo. This is helpful if we need to ever 
look at or test older versions of the code. Doing a checkout of a 
changeset 100 revisions ago only takes a couple of seconds.

tech sidebar: One interesting functionality of the 
packing/compression available in git is that a WHOLE repository with 
ALL the commits can be smaller than just the svn co of the trunk 
revision. A git version of the whole jruby svn repository is about 
71MB. A svn co of just the trunk branch is 60MB.

There a MUCH cooler way people are using git however which has really 
pushed the collaborative aspects. It starts the same as above:

   I create a repo on my hard drive and make commits, branches etc. 
If I want to share
   this I make a public git repo on a server and push my local git repo there.

And it could even stay the same for all of us -- but lets add "Chad" 
(someone we don't want to give commit rights to our repo but who 
should be able to easily try things out and add to our code). Chad 
clones our repo and has a copy locally, he make all sorts of cool 
changes in a branch and wants to share them with us ... here are some 
options:

1) He can have git create a patch and email that to us. This isn't 
much different so far from the sourceforge model but the git-patch is 
constructed so when I get it I can trivially apply Chad's patch which 
makes a chad branch and inspect or try out his changes. There is 
nothing his patch has done which changes any of my other branches. If 
I like his code I can merge the changes on his branch with my main 
working branch.  If I like his code but want him to make more changes 
before I accept it I can let him know.

2) Chad can setup his own public git repo which is a fork of our git 
repo. He still works locally and makes his cool changes but now he 
pushes them to his public git repo. He even shares his cool changes 
with other folks who help him test them.  After he and his friends 
test all this cool stuff and make sure it works emails me and says 
I've got great new stuff, Pull the branch "chadsnewwork" from here:

  http://git.com/chad/myforkofstephenscode

I don't have to deal with an emailed patch I can pull directly and it 
also makes a new branch and I can try it out. If I like it merge to 
master and keep going.

The huge value in this is that Chad (and friends) have full advantage 
of a powerful SCM while they are separately developing the code they 
want to add. At any time they can pull updates form our original repo 
and merge or rebase to get the work they are doing up to date. It is 
also trivial for people Chad motivates to try out his changes by 
cloning his repo.

Forks used to be a sign of a severe breakdown in an open source 
project. Among people working with git the more forks the healthier 
the project.

Check out this page which list public git repositories on github 
sorted by most forked:

   http://github.com/popular/forked

I was talking today about rspec and webrat -- they have 40 and 20 
forks respectively.

Github offers free repo hosting for open source projects and adds a 
bunch of cool social networking functionality to help scaffold the 
community collaboration. For example I'm registered ther and with one 
click I can fork someone else's repo and make my own public git fork. 
I can also "Watch" other git repos I'm interested in. "Well that's 
not so interesting" you might say, "it's just like an rss feed to the 
changesets" ... Yes but now I can also see what projects are watched 
the most:

   http://github.com/popular/watched

Or I can check out Nick Sieger's profile (core JRuby developer) and 
see what other projects he is working on or what other projects he's 
forked:

   http://github.com/nicksieger

The functionality in git combined with the social networking value 
added by a site like github are shifting the way open source 
collaboration works.

------------------- Background ------------------

Linus Torvalds description of why he created git for Linux 
development (not so technical, mostly about distributed 
collaboration):
   http://www.youtube.com/watch?v=4XpnKHJAok8

Scott Chacon has a great series of screencasts on git (technical):
   http://www.gitcasts.com/

For programmers who want/need to understand just how git works I 
highly recommend the 55m one from RailsConf2008. Here's a feed of 
hi-res versions of the screencasts:
   http://feeds.feedburner.com/GitcastsHighRes

You can get a QT movie of the railsconf git talk in QuickTime format here:
   http://media.gitcasts.com/git-talk.mov.zip

if you want to use git on a Mac install macports and do this (on a 
high-speed network):
   sudo port install git-core +svn +doc: +gitweb +svn: +bash_completion

Git - SVN Crash Course (explains git to someone who knows subversion):
   http://git.or.cz/course/svn.html

An introduction to git-svn for Subversion/SVK users and deserters 
(using git with a svn repo directly):
   http://utsl.gen.nz/talks/git-svn/intro.html



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"SAIL-Dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/SAIL-Dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to