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