hosting git conversion of Fedora CVS tree on fedora infrastructure?
 

Jeremy Katz wrote:

On Tue, 2007-11-20 at 08:39 -0600, Mike McGrath wrote:


Karsten Wade wrote:


On Mon, 2007-11-19 at 12:01 +0100, Lennert Buytenhek wrote:


The git tree is currently a read-only (slave) version of the CVS
tree, and I expect it to stay that way for some time. But even though
Fedora isn't switching VCSes at this point, I think it would still
make sense to have git/hg/random-other-VCS conversions of the Fedora
CVS tree publically available ...


+1 to the general idea.

Are you interested in building and maintaining the solution in Fedora
Infrastructure? Just asking as a bystander ... :)

What problem are we trying to solve by doing this or what added
functionality will we get that people can't get by just downloading a
snapshot and importing it into git themselves?



Downloading a snapshot of what? The entire repo? Do we have that
actually available? Even if so, it's still not an incremental grab.




I think the closest is webfiles:

http://cvs.fedoraproject.org/webfiles/

-Mike

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list

hosting git conversion of Fedora CVS tree on fedora infrastructure?
 

Jim Meyering wrote:

Mike McGrath <mmcgrath@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

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list

hosting git conversion of Fedora CVS tree on fedora infrastructure?
 

Toshio Kuratomi <a.badger@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?]

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.

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

Jim
[*] In case you haven't seen it yet, "git rebase --interactive" is very
useful, if you care about the "perfect patch" sort of process.
With it, there's no need for quilt/stgit/etc.

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list