using git to track the GDB CVS: A summary

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

using git to track the GDB CVS: A summary

Joel Brobecker
Following a message I sent on this mailing list a few weeks ago
regarding the use of git to track the GDB CVS tree, I received
a few answers.

My question was about importing the GDB CVS into a git repository.
My hope was that the git-cvs bridge was sufficiently powerful and
efficient that I would be able to have a "git" mirror of the public
CVS.

Given the size (in terms of number of changes) of the GDB project,
and the extreme slowness of importing a CVS project through the network,
I was hoping that it'd be possible to import the CVS HEAD and mirror
the CVS tree from that point only. I haven't found a way to do that
yet. I should ask on a git forum to confirm my findings (or lack
thereof), but my searches on the web never talk of importing only
partially a CVS tree.

On the other hand, all the answers that I received used a hybrid
CVS+git/hg approach. JimB reported that he has been using mercurial
(hg) with great satisfaction. I will post his typical work-flow
a little later, but the principles are the same, so I will talk
about git only in the rest of my email.

The idea is to checkout the GDB sources from CVS, and to import
the result in git (including the CVS control files).  You can then
work on your changes using git. Once in a while, when you want to
pull the latest changes in the FSF tree, you simply do a "cvs up"
followed by "git commit".  This is possible because the CVS files
were kept during the initial import in git.

Vladimir explained his work-flow as follow:

> I have git repository which has a branch named 'mirror' and my
> work branches. The 'mirror' branch was created by importing
> CVS checkout of FSF tree -- and I did not remove the CVS directories.
>
> Say, I have branch always_inserted, which was originally created from
> mirror, where I have several commits, converted them to emails and sent
> to gdb-patches and one patch is approved.
>
> Then, I go this:
>
> 1. Switch back to mirror:
>
>        git checkout mirror
>
> 2. Make sure it's up-to-date:
>
>        cvs co gdb
>
> (Note that "co", on existing working copy, works just like "up",
> but handles that 'modules' thing better).
>
> 3. Apply the approved patch
>
>        git cherry-pick <id of commit>
>
> 4. Commit using CVS
>
> 5. Update git's branch
>
>        git commit -a -m "Update"
>
> 6. Return back to work branch:
>
>        git checkout always_inserted
>
> 7. Rebase:
>
>       git rebase mirror
>
> The latter command is supposed to remove patches already present
> in 'mirror'.
>
> So, in a certain sense the history of CVS HEAD is present, except that
> individual CVS commits are not available.

For mercurial, JimB described his typical work-flow as follow:

> I'm using Mercurial (hg) for my GDB work, and I like it a whole lot.
> I have one tree I call 'pub' that is both a CVS working copy and a hg
> working copy.  I never make changes there.  Whenever I like, I run a
> script that does (roughly):
>
>   cd $pub
>   cvs -d :ext:[hidden email]:/cvs/src co gdb
>   cd $pub/src
>   hg addremove
>   hg commit -m 'from public CVS'
>
> Working copies for specific projects are then clones of pub, so I can
> 'hg pull' to get public changes, and then 'hg merge' or 'hg update' as
> appropriate.
>
> To commit a change, I 'hg push', then cd to pub and 'cvs commit'.
>
> Mercurial has a feature called 'queues' which helps maintain patch
> series.

To conclude this email, if I may make a personal judgement on these tools,
I would say that I agree with Thiago who said that git is a great tool,
but has an interface that I don't like (at least not yet). The issue
might be that it's too different from svn, but I am thinking that the
real problem is that it simply is too powerful and requires some commitment
to learn it to a point where you it's no longer an obstacle in your
work-flow. On the other hand, mercurial has a much simpler interface,
and its simplicity has made it a real pleasure to use.

Looking back now, using an import of a CVS checkout into a local SVN
repository is, in terms of work-flow, a relatively practical solution.
Since I'm still on the road for the next 10 days, I will stay with
that solution for now. But the drawback is the extra complexity in
the initial setup, and of course the larger amount of disk space
occupied by the repository and the sandbox.

--
Joel
Reply | Threaded
Open this post in threaded view
|

Re: using git to track the GDB CVS: A summary

H.J. Lu-27
On Mon, Jan 14, 2008 at 07:29:20AM -0800, Joel Brobecker wrote:

> Following a message I sent on this mailing list a few weeks ago
> regarding the use of git to track the GDB CVS tree, I received
> a few answers.
>
> My question was about importing the GDB CVS into a git repository.
> My hope was that the git-cvs bridge was sufficiently powerful and
> efficient that I would be able to have a "git" mirror of the public
> CVS.
>
> Given the size (in terms of number of changes) of the GDB project,
> and the extreme slowness of importing a CVS project through the network,

Why not rsync a mirror of GDB CVS repository on your local
machine/network? That is what I did.


H.J.
Reply | Threaded
Open this post in threaded view
|

Re: using git to track the GDB CVS: A summary

Frank Ch. Eigler
In reply to this post by Joel Brobecker
Joel Brobecker <[hidden email]> writes:

> Following a message I sent on this mailing list a few weeks ago
> regarding the use of git to track the GDB CVS tree, I received
> a few answers.
>
> My question was about importing the GDB CVS into a git repository.
> [...]

Sourceware.org supplies git mirrors to a small number of CVS-based
projects.  If there is more than token interest in this, please make
the request on [hidden email].

(FWIW, your proposed workflow for a git mirror seems to me a bit
clumsy.  For our systemtap git/cvs mirror, there is no problem with
using native git for development (git pull/commit/branch/merge etc.)
and having a CVS working tree only for final cvs commit purposes.)

- FChE
Reply | Threaded
Open this post in threaded view
|

Re: using git to track the GDB CVS: A summary

Vladimir Prus
Frank Ch. Eigler wrote:

> Joel Brobecker <[hidden email]> writes:
>
>> Following a message I sent on this mailing list a few weeks ago
>> regarding the use of git to track the GDB CVS tree, I received
>> a few answers.
>>
>> My question was about importing the GDB CVS into a git repository.
>> [...]
>
> Sourceware.org supplies git mirrors to a small number of CVS-based
> projects.  If there is more than token interest in this, please make
> the request on [hidden email].

I'm not sure who is authorised to make such requests, but it would
nice if those authorised make it. Having git mirror of gdb CVS will
surely help me quite a bit.

- Volodya


Reply | Threaded
Open this post in threaded view
|

Re: using git to track the GDB CVS: A summary

Joel Brobecker
> I'm not sure who is authorised to make such requests, but it would
> nice if those authorised make it. Having git mirror of gdb CVS will
> surely help me quite a bit.

How about asking overseers how much interest would be needed for them
to set this up? You've been using git on GDB for a while, I believe.
Although I think I'm more interesting in mercury, I would still be
interested in checking out a git mirror.

--
Joel
Reply | Threaded
Open this post in threaded view
|

Re: using git to track the GDB CVS: A summary

Frank Ch. Eigler
In reply to this post by Joel Brobecker
Hi -

> > I'm not sure who is authorised to make such requests, but it would
> > nice if those authorised make it. Having git mirror of gdb CVS will
> > surely help me quite a bit.
>
> How about asking overseers how much interest would be needed for them
> to set this up? [...]

I'd like to hear a regular gdb maintainer offer support to the idea,
and to help scope whether the entire /cvs/src repo or just some
subsets should be included.  I can set up a one-time git mirror;
ongoing refreshing of the mirror would ideally be done by a cron job
running under that maintainer's sourceware account.

- FChE