Sylvain Beucler <[EMAIL PROTECTED]> 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: > savannah-hackers-public@gnu.org 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 <[EMAIL PROTECTED]>" labels), so if there's a way to put up a trial git repository, let me know...