hosting git conversion of Fedora CVS tree on fedora infrastructure?

[Jim Meyering]

Mike McGrath <mmcgrath at redhat.com> wrote:
> Jim Meyering wrote:
...
>> At 5GB+, (4.5GB for a copy of the cvs repo + 700MB for git) that's too
>> heavy for me.  And besides, it'd really be better under the Fedora
>> umbrella.  Seeing as how much more efficient the git protocol is,
>> if a few people switch to it from cvs, it'd actually decrease network
>> bandwidth requirements.
>>
>> Is there anything I can do to revive this idea?
>> For example, I'd be happy to own and set up the tools/infrastructure
>> required to make it all work (I've already done this on three public servers).
>> All I'd need is an open git port and access to the config files.
>
> If you think git is so much better than CVS (many would agree with
> you) come up with a proposal on how we can migrate to it, propose it,
> then convince people its the right thing to do.

I consider the automated cvs-to-git mirroring to be the first step
in any conversion proposal:

First, give people an idea of what they can expect in a git-based dVCS,
without requiring any change.  It lets people continue to use the tools
they're familiar with, and allows the better parts of a dVCS to begin
to show up the radar of those who haven't yet had time to explore them.
It also begins to highlight the parts (if any) of the existing process
that might end up being adjusted with a dVCS.  For example, in CVS,
there's no reason to put a summary on the first line of the commit
log message.  But with any dVCS, it's encouraged.  This shows up when
you compare views of commit summaries in pure-dVCS projects and those
where people have not yet adopted the first-line-is-summary standard.

Helping a big project transition is a big job, so IMHO, the only way to
do it is incrementally.  If you try to come up with an all-encompassing
proposal, you might never get buy-in from enough people and you'll wait
forever.  With something like this, a dVCS gets a foot in the door.
And if/when people conclude it's worthless or want to try another,
it's easy to revert or shift gears.

Here's a feature of git that'd be handy if there ever is a cut-over:
one can set up a read-only[1] cvs-pserver mirror to the master git
repository.  Then, while commits/pushes all go directly through git,
people can still use their cvs clients for read-only operations on the
very same git repository.  Offering that service helped to convert a few
projects on savannah.gnu.org from CVS to git: automake, autoconf, m4.
The git-cvsserver emulation is 'ok', but for example doesn't handle the
"-D date-string" part of the protocol.  Not a big deal, of course.

[1] you can even use git-cvsserver emulation to *write* into the git
repository, but I don't think it's mature enough for that.