Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Re: using git to track the GDB CVS: A summary
@ 2008-03-06 20:49 Frank Ch. Eigler
  0 siblings, 0 replies; 6+ messages in thread
From: Frank Ch. Eigler @ 2008-03-06 20:49 UTC (permalink / raw)
  To: gdb

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


^ permalink raw reply	[flat|nested] 6+ messages in thread
* using git to track the GDB CVS: A summary
@ 2008-01-14 15:30 Joel Brobecker
  2008-01-14 15:47 ` H.J. Lu
  2008-02-20  8:59 ` Frank Ch. Eigler
  0 siblings, 2 replies; 6+ messages in thread
From: Joel Brobecker @ 2008-01-14 15:30 UTC (permalink / raw)
  To: gdb

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:jimb@sourceware.org:/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


^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-03-06 20:37 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-03-06 20:49 using git to track the GDB CVS: A summary Frank Ch. Eigler
  -- strict thread matches above, loose matches on Subject: below --
2008-01-14 15:30 Joel Brobecker
2008-01-14 15:47 ` H.J. Lu
2008-02-20  8:59 ` Frank Ch. Eigler
2008-03-06  8:01   ` Vladimir Prus
2008-03-06 19:17     ` Joel Brobecker

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox