using git to track the GDB CVS: A summary

[Joel Brobecker <brobecker at adacore dot com>]

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