hosting git conversion of Fedora CVS tree on fedora infrastructure?

[Toshio Kuratomi]

Jim Meyering wrote:
> Toshio Kuratomi <a.badger at gmail.com> wrote:
>> Jim Meyering wrote:
> ...
>>> 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.
> 
> Hi Toshio,
> 
> [didn't we talk at a Mexican place after the fudcon in Boston?]
> 
[Yeah, I think we did :-) ]

> Using such a mirror need not be a one-way transaction.
> Obviously, it'd be far less useful if there were such a limitation.
> 
> When I do serious work against an upstream CVS repository, I arrange to
> mirror the CVS repo to git, and do all of my work in git, committing
> changes on private git branches.  Then, I can easily rebase each of
> those branches (sort of like cvs update), to synchronize with newer
> upstream changes on the parent branch.[*]  When I want to commit to
> cvs, it's easy to automate using git-cvsexportcommit.  While this MO is
> not as comfortable as working in a git-only environment, it does help
> give you a feel for what it'd be like, and *I* certainly appreciate it.
> Of course, this can't help for tag/release-related operations, but it's
> a good start for the rest.
> 
That sounds better.  Where does all this get setup?  On the user's 
machine or the server?  I still don't know if you'll get many developers 
to try it since you still have to keep both the git and cvs tree so they 
can make tag and make build.  git can't push tags back to cvs?

> Even with this slightly-contorted routine, I've appreciated using
> git: for example, while using conventional diff, patch, and cvs,
> it's easy to forget to "cvs add" a new file that was added by a patch.
> It's also easy to forget to apply "chmod a+x..." to a script just added
> by a patch.  But in git, that doesn't happen as much, because the tools
> do more of the work for you.  And git-cvsexportcommit takes care of the
> details of making sure everything in a git change set makes it back
> into a cvs "commit".
> 
Git does that when you apply a patch?  Or only when you apply a patch 
that was generated via git?  (I tried git apply foo.patch but that 
didn't seem to have the behaviour you mention.)

-Toshio