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