Distributed Version Control

The Problem

Many institutions are utilizing a 'vendor drop' strategy to maintaining their local modifications to Sakai.  This results in their inability to view the true history and authorship of files.  This makes sharing changes back and upgrading to new versions difficult.  A 'massively inclusive' svn has been proposed as a solution, and while this is a step in the correct direction, it cannot scale and puts an unnecessary burden on the svn admins and central repository.

 A Proposed Solution

Using a distributed version control system such as git or mercurial would fit the Sakai development model much better than the current centralized paradigm.   That being
said, git's submodule support (think svn externals) is severely lacking in usability.  The good news is that the git community is aware of the problem and massive projects like KDE that have to use submodules are pressuring that work to get done.  Considering all of the previous, Georgia Tech plans to have a gatech/tsquare 2-5-x branch in the "massively inclusive"
repo that we'll manage with git-svn for now while keeping an eye on git submodule with the intention of switching once using it isn't so painful.

What it Would Require

If we were to switch to git today the work involved would be cloning every tool into individual repositories and setting up the submodules by hand for every revision that we care about (trunk, 2-4-x, 2-5-x, all the tags). Developers then have to use the current submodule support, which is lacking but improving quickly. Each institution would then maintain their own branch in their local repo that would have full history and support for pulling from any other public sakai repo (so I could merge directly from bspace to tsquare if I wanted, and the repo was public). If your repo is in the inclusive svn you just clone it out to git and start working, if you do vendor drops the loss of history and commit info will prevent git from recognizing the central sakai repo as an ancestor of your repo so you'll have to effectively start over.

Encouraging Experimentation and Contribution

I can make any number of branches in my local repo that no one else cares about, allowing me to experiment with things without cluttering everybody up. If I complete something that should go into community code I can push that branch (provided I have upstream permission) or I can request the upstream maintainer pull the branch from me (possibly to a staging branch where it gets reviewed and signed off) or I can tell git to format it as a patch to upstream and automatically email it to a list that a maintainer watches. All this does not preclude my feeling that the inclusive svn is a step in the right direction, I just think moving to git would encourage distributed development rather than stymie it.