Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
A few data points:
First, any of the git piles are clones so the load can be distributed.
There is no central server in the git model. So the load does not need
to affect any one site.
Second, savannah.gnu.org offers git instead of CVS if you want.
Third, on the Axiom project we host the official sources in CVS
on savannah and sourceforge. These are used a read-only download
sources. We don't use them for code development. Once code development
freezes we update the official CVS sources. Thus savannah and
sourceforge carry the bandwidth loads.
Fourth, the git package contains a whole raft of commands like
git-add, git-commit, git-reset, etc so cogito is not needed.
Fifth, git has a git-cvs, git-svn, etc tool to allow push/pull with
cvs, svn, and others. Each person can switch without requiring others
Sixth, the highest cost to switching SCMs appears to be the religious
debate :-). Everyone likes the thing they understand most so it becomes
a pseudo feature war, hiding the real issue. Like lisp, you either
understand git or you don't.
Lastly, see linus talk abou git:
The hardest part about git vs CVS is the notion of changes.
CVS tracks changes by file. Renaming the file throws CVS off the
track. The side-effect is that you only do a single cvs add for
a file and then any changes automatically get committed.
Git tracks changes by change. So you can tell that code moved
from one file to another, or a file was renamed, etc. Git doesn't
know the concept of "file". The side-effect is that you do a git-add
for each change. Changes are not automatically committed.
Anyway, as much as I love git and think it worthwhile, what is the
upside/downside to changing SBCL development to use it?