Convertion to Git

Bron Gondwana brong at fastmail.fm
Thu Mar 26 00:21:22 EDT 2009


Wow - I'm getting pretty tired of dealing with the CVS/Git conversion,
I just noticed that git-cvsimport doesn't properly pick up multiple
tags on the same revision - and there was also a caching issue that
caused it not to pick up the 2.3.14 tag at all.  Obviously, that's
a pretty half-baked "solution".

There's a much more accurate tool cvs2git, but it doesn't support
incremental operation - it's a one-shot repository conversion tool.

So...

We've talked about converting to something other than CVS already,
and we have pretty strong support for git on the mailing list.
Nothing else even got a positive mention.

I've got a testing web interface to my current mirror-of-CVS
repositories here:

http://cyrus-devel.andrew.cmu.edu/cgit.cgi

But that's just running out of a directory on one machine.
It's not what I'd call "mature infrastructure".

Off the top of my head here's what would be needed for
a real conversion to using git:

1) Buy-in from everybody with commit rights.  Both to using git, and
   to some sort of usable workflow.  Git is significantly more
   flexible than CVS, and we all have to agree how to use it.

1a) this includes buy-in from CMU management and sysadmin.  Dave,
    I'll need your input on that!

2) Figure out how to deal with 'sieve' and 'cmulocal' being
   separate repositories (either merge into one git repository
   or keep separate with 'git submodule')

3) Convert from CVS to git and validate the conversion (at least
   HEAD & the tip of any still-active branches)

4) Infrastructure at CMU.  A build of git.  Somewhere reliable,
   backed up.  A copy of cgit.cgi or similar for web access.
   A monitored git server daemon.

5) Security setup to access the git repository somehow - either
   each having an individual repository with an automated merge
   daemon or another access mechanism.  Also, gitorious or
   similar so we can use keyed SSH (every other access method is
   a real pain to use)

6) Commit hooks to send emails to the cyrus-cvs mailing list on
   changes.  Maybe even something like:

   http://github.com/stephenh/git-central/

7) Release process changes, possibly.

----------

Have I missed anything?  If we can agree on the basic roadmap
then we can start setting timelines and tasks to get there.

My gut feeling is that we're looking at an absolute minimum
3 month timeframe for this if we push really hard, more
realistically perhaps 6 months.  Especially if I'm doing most
of the pushing, and in a rather incompatible timezone from
the infrastructure people!

But - I do think this is the way of the future[tm], and
choosing git is a good basis from which to build.

Some parts of the surrounding infrastructure (ticket
management, web interfaces, intregrated wikis, etc) aren't
complete yet, but they will stabilise eventually - and we
don't have that level of integration now anyway, so just
converting CVS => git and not touching anything else is
still a net win.

Regards,

Bron.


More information about the Cyrus-devel mailing list