hosting git conversion of Fedora CVS tree on fedora infrastructure?

[Toshio Kuratomi]

Jim Meyering wrote:
> 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.

I don't really buy this because it's a one-way transaction.  The people 
that need to be convinced that there's value in switching to git vs bzr 
vs hg vs svn also have commit rights to the main repository.  For a demo 
to reach this audience you need to get them the ability to work from 
this tree.  Which means they need to be able to checkout, checkin, tag, 
and request builds from it.

[snip]

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

I'm in agreement with this part.  From trying to work up a trial before 
I have to say that the hardest part is figuring out how we can implement 
changes incrementally *and* non-disruptively.  (Note that the changeover 
will be disruptive.  But we want to make it a one-time event, not an 
on-going, this time we're switching to bzr, next time we're switching to 
exploded trees, etc.)

However, I don't see a read-only mirror as an incremental step towards 
moving to a new VCS.  It's more of a value-add for downstream 
distributions.  IMHO we'd be much better figuring out a real interim 
step to make it possible for package maintainers to do actual work 
within a new VCS.

-Toshio