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
