So far, no one has objected to my proposal to convert gnulib development from cvs to git. If there are any nay-sayers, it's time to speak up.
I've just gone through the conversion process once more, and pushed the result to the usual place: http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=summary As before, the conversion took about 20 min, but that doesn't matter because it's something that's done only once (or a few times), in the beginning. Once we switch, each change pushed to the master git repository will be mirrored individually to the CVS repository. That's what I do with coreutils, and so far, it's worked well. More on that below. ====================================================================== Compare repository sizes: $ du -sh .git /t/gnulib-rsync/gnulib/gnulib 14M .git 27M /t/gnulib-rsync/gnulib/gnulib ====================================================================== Ensure that a checkout gives the same bits: $ gitc-sync-check $cvs_repo/gnulib $PWD|diffstat COPYING | 2 +- config/srclist-update | 2 +- config/srclist.txt | 2 +- config/srclistvars.sh | 2 +- doc/Makefile | 2 +- doc/gnulib.texi | 4 ++-- gnulib-tool | 2 +- 7 files changed, 8 insertions(+), 8 deletions(-) All diffs look like this: --- git/doc/gnulib.texi 2006-11-24 11:33:58.841329625 +0100 +++ cvs/doc/gnulib.texi 2006-11-07 20:51:40.000000000 +0100 @@ -1,5 +1,5 @@ \input texinfo @c -*-texinfo-*- [EMAIL PROTECTED] $Id: gnulib.texi,v 1.30 2006/11/07 19:51:40 rwild Exp $ [EMAIL PROTECTED] $Id: gnulib.texi,v 1.30 2006-11-07 19:51:40 rwild Exp $ @comment %**start of header @setfilename gnulib.info @settitle GNU Gnulib @@ -7,7 +7,7 @@ @syncodeindex pg cp @comment %**end of header [EMAIL PROTECTED] UPDATED $Date: 2006/11/07 19:51:40 $ [EMAIL PROTECTED] UPDATED $Date: 2006-11-07 19:51:40 $ ====================================================================== Does anyone object to my removing the $Id...$ strings from those files? They will serve no purpose once we migrate. On the migration front, one minor snag was that executable scripts added to a git repository would not mirror correctly to a CVS repo. They'd end up getting added to the cvs repo without the execute bit. Since that hit me 2 or 3 times with coreutils, I finally fixed the offending script, git-cvsexportcommit, last night. Then, Junio Hamano (git maintainer) suggested an even better fix, which should be checked in shortly, so that's done. I expect to automate coreutils' git->cvs mirroring soon. Once I have a week or two worth of problem-free operation on that front, I'll see about getting something similar installed on savannah so that the coreutils git repository there is automatically sync'd to the cvs one.
