[Savannah-hackers-public] Re: reliable, incremental git->cvs ?

[Sylvain Beucler]

On Tue, Nov 28, 2006 at 11:32:55AM +0100, Jim Meyering wrote:
> 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.

That sounds reasonable :)


> 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...

I created a 'gnulib' repository, with temporarily denyNonFastforwards
= false so you can perform multiple upload tests there.

(I say temporarily because since the option essentially allows
removing history (i.e. overwriting heads/master arbitrarily), it can't
be enabled for a real repository).


I haven't setup an auto-packing commit hook so may need to have me do
that. I'm planning to add something like in post-update:

  export GIT_DIR=coreutils.git
  git-count-objects
  # If > 5120k
  git repack
  git prune

-- 
Sylvain