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
|
