Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Infrastructure (http://www.linux-archive.org/fedora-infrastructure/)
-   -   hosting git conversion of Fedora CVS tree on fedora infrastructure? (http://www.linux-archive.org/fedora-infrastructure/8786-hosting-git-conversion-fedora-cvs-tree-fedora-infrastructure.html)

Toshio Kuratomi 11-29-2007 10:58 PM

hosting git conversion of Fedora CVS tree on fedora infrastructure?
 
Jim Meyering wrote:

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?]


[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

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

Jim Meyering 11-30-2007 09:44 AM

hosting git conversion of Fedora CVS tree on fedora infrastructure?
 
Toshio Kuratomi <a.badger@gmail.com> wrote:
...
>> 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?

The only part that's done on the server is to maintain the git repo
in sync with the master CVS repository. For my usage, I keep two
checked-out repos for each such project: the cvs one and the git one.
I never change anything in the CVS one manually. That's only for the
automated commit-from-git-to-cvs process. Other than that, there's almost
no set-up required. I use a tiny bash function to encapsulate the details
of "apply this git change-set to the corresponding CVS working directory".
That just runs git-cvsexportcommit with options that apply the patch
and ensure that there was no fuzz. git-cvsexportcommit has an option
to perform the commit, but I don't use that -- prefer to verify, first.
git-cvsexportcommit's output includes the "cvs commit -F .msg file1
file2 ..." command that'd be required to commit the affected files,
using the same message you used in the git commit.

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

We won't know until we try, will we? :-)

> git can't push tags back to cvs?

That's not part of git-cvsexportcommit's charter.
However, the cvs-to-git mirroring operation does preserve tags.

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

Yes. In the scenario I described above, it does, since git generates
the patch and applies it, too. The format of classical "diff" output
does not (and cannot) contain the information required for git tools to
perform the extra checks.

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

Right. That's an inherent limitation in the standard format.

FYI, once you've committed a change in git, you can get the latest
change set in patch format like this:

git-format-patch --stdout --signoff HEAD~1 > patch

or the latest N change sets:

git-format-patch --stdout --signoff HEAD~N > patch

Then, you can later apply that series of change sets via git-am, e.g.

git-am patch

Applying patches that way preserves file permissions, author name
and email, dates, etc.

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


All times are GMT. The time now is 01:39 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.