Re: reliable, incremental git->cvs ?

[Jim Meyering]

Sylvain Beucler <address@hidden> wrote:
> On Mon, Nov 27, 2006 at 10:41:49PM +0100, Jim Meyering wrote:
>> Hi Sylvain,
>>
>> Do you know of a good way to sync a git repository to cvs?
>> Ideally, it'd happen upon each commit or push, via a hook.
>>
>> Currently I'm manually invoking a tiny script based on
>> git-cvsexportcommit.  I think it's based om an example I saw in git's
>> Documentation dir or in a man page.
>>
>> Sylvain, in case you haven't been following bug-gnulib, we're planning to
>> convert gnulib development from CVS to git.  But it doesn't always work.
>> For example, it doesn't preserve executable bits on new files.  Yep,
>> I need to fix and/or report that bug.  This is particularly relevant,
>> because one of the conditions of switching gnulib, IMHO, must be to
>> retain an automatically-up-to-date CVS repository.  That way, only
>> developers who contribute regularly have to learn/use git.
>> Everyone else can stick with CVS.
>
> Hi,
>
> Thanks for keeping me updated about this. Feel free to Cc:
> address@hidden about this anytime.

Thanks for Cc'ing them.
I've Cc'd bug-gnulib, too.

> I haven't investigated git<->cvs pipelines, so I don't have much to
> say about it (do you mean uni- or bi-directional, btw?).

One-way: git->cvs.  At least, that's my plan:
to make the cvs repository read-only, except
when being updated to reflect a git commit.

FYI, here's my git->cvs script.
(theoretically, a git commit hook would run this)

#!/bin/sh
# Push git changes (that are in the master repo) into the CVS repository.
export GIT_DIR=/cu.git # git repo
set -e
cd /cu-cvs             # checked out cvs working directory
for sha1 in $(git-cherry cvs-head | sed -n 's/^+ //p'); do
  git-cvsexportcommit -c -p -v $sha1
  git-tag -f -m "most recent version that has been sync'd to cvs" cvs-head $sha1
done

> I saw this though:
> http://www.kernel.org/pub/software/scm/git/docs/git-cvsserver.html

Yes, I've read about that.
It may be an option if/when we're willing to dump the CVS
repository altogether.  At least for now, I'd prefer to
have the option to switch back to using good-ol' CVS if
by some fluke, a problem arises.

On the other hand, if it's stable enough, it'd sure be simpler
than having to hassle with sync'ing via commit hooks...

> Apparently this gives
> - a way to stick to the 'cvs' command-line when accessing a git repo
>   (export CVS_SERVER=git-cvsserver)
> - a way to access a git repo through the CVS pserver protocol
>   (I'd need to attach that daemon to another IP because Savannah's git
>   and cvs are on the same machine)
>
> Could that help?
>
> I can't guarantee I can set that up securely at Savannah but I can
> investigate the tools some more if that can help.

That'd be great.
If you could hook one up to coreutils, that might be a good test case...

BTW, I've converted gnulib's (as of a day or two ago) CVS repo into a
git repository (with proper "User Name <address@hidden>" labels), so if
there's a way to put up a trial git repository, let me know...