Jim Meyering wrote:
> A good argument for upgrading any cvs servers you control.
Unfortunately, it's the clients that you would need to upgrade - it's the
GPLed 'cvs' client which pushes the load to the cvs server. And the client
that has this behaviour fixed is not free software.
> If no one objects to dropping CVS support, I'll be happy to switch now.
Yes, please. Doing this will help
- people with a modem or DSL connection,
- doing renames,
- keeping the ChangeLog a single piece,
- maintaining forked copies of gnulib,
- determining the checkout identification (requested by Eric a few days ago).
> But that would require a certain amount of hand-holding and updating
> FAQ/etc. telling people how to use git enough to "pull" (aka update),
> and how to prepare patches properly (which means explaining the basics of
> git topic branches), etc.
Yes, and I'm willing to help on it. Find attached already the doc patches.
It's a time well invested, since the design of cvs is based on network/disk
tradeoffs that are not correct any more with today's hardware.
> The desire to retain CVS access (e.g., for Karl :-), and the fact that it
> will have to be via git-cvsserver to provide at least read-only pserver
> access, means I'll have to exercise a certain amount of due diligence,
> too. I'll have to set up something separate, test it, and then, once
> confident everything works the way we want, choose a nonstandard port
> on sv.gnu.org for use as the git-pserver port and set it up there.
> (the pserver port is already in use, of course).
Yes, please!! I can help updating the docs afterwards.
Bruno
2007-03-31 Bruno Haible <[EMAIL PROTECTED]>
* README: Talk primarily about git.
(git and CVS): Renamed from CVS.
* doc/gnulib.texi (Introduction, Build robot for gnulib): Mention that
gnulib is available through git.
* doc/gnulib-tool.texi (CVS Issues): Mention git and svn as well.
--- README 26 Feb 2007 07:43:43 -0000 1.19
+++ README 31 Mar 2007 12:33:04 -0000
@@ -202,21 +202,40 @@
We will be developing a testsuite for these applications. The goal is
to have a 100% firm interface so that maintainers can feel free to
-update to the code in CVS at *any* time and know that their
+update to the code in git at *any* time and know that their
application will not break. This means that before any change can be
committed to the repository, a test suite program must be produced
that exposes the bug for regression testing. All experimental work
should be done on branches to help promote this.
-CVS
-===
+git and CVS
+===========
Gnulib is available for anonymous checkout. In any Bourne-shell the
following should work:
-
-$ cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/gnulib login
-(Just hit Enter or Return when prompted for a password)
-$ cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/gnulib checkout gnulib
+ $ git clone git://git.sv.gnu.org/gnulib
+Or, if you prefer the CVS-like 'cogito' frontend to plain 'git':
+ $ cg clone git://git.sv.gnu.org/gnulib
+
+git resources:
+ Overview: http://en.wikipedia.org/wiki/Git_(software)
+ Homepage: http://git.or.cz/
+ Download: http://www.kernel.org/pub/software/scm/git/
+ Tutorial: http://git.or.cz/course/
+ http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
+ FAQ: http://git.or.cz/gitwiki/GitFaq
+
+cogito resources:
+ Overview: http://en.wikipedia.org/wiki/Cogito_(software)
+ Homepage: http://git.or.cz/cogito/
+ Download: http://kernel.org/pub/software/scm/cogito/
+ Tutorial: http://git.or.cz/course/
+
+For those among us who have tightly limited disk space and a fast network
+connection, CVS checkouts are also supported:
+ $ cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/gnulib login
+ (Just hit Enter or Return when prompted for a password)
+ $ cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/gnulib checkout gnulib
Gnulib is hosted on savannah.gnu.org. The project page is
http://savannah.gnu.org/projects/gnulib.
@@ -224,11 +243,11 @@
Keeping Up-to-date
==================
-The best way to work with Gnulib is to check it out of CVS.
+The best way to work with Gnulib is to check it out of git.
Subscribing to the bug-gnulib@gnu.org mailing list will help you to
plan when to update your local copy of Gnulib (which you use to
-maintain your software) from CVS. You can use "cvs update -dP" to
-synchronize.
+maintain your software) from git. To synchronize, you can use "git pull"
+or "cg update", or "cvs update -dP" if you are still using CVS.
Sometimes, using an updated version of Gnulib will require you to use
newer versions of GNU Automake or Autoconf. You may find it helpful
@@ -237,7 +256,7 @@
-----
-Copyright (C) 2001, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
+Copyright (C) 2001, 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
--- doc/gnulib.texi 19 Mar 2007 20:30:25 -0000 1.34
+++ doc/gnulib.texi 31 Mar 2007 12:00:11 -0000
@@ -68,7 +68,7 @@
@itemize
@item Gnulib is hosted at Savannah:
@url{http://savannah.gnu.org/projects/gnulib}. Get the sources
- through CVS from there.
+ through git or CVS from there.
@item The Gnulib home page:
@url{http://www.gnu.org/software/gnulib/}.
@end itemize
@@ -371,7 +371,7 @@
@item Create gnulib directory
On a machine with recent automake, autoconf, m4 installed and with a
-gnulib cvs checkout (typically a Linux machine), use
+gnulib git or cvs checkout (typically a Linux machine), use
@example
gnulib-tool --create-megatestdir --with-tests --dir=..."
--- doc/gnulib-tool.texi 2 Mar 2007 21:30:00 -0000 1.13
+++ doc/gnulib-tool.texi 31 Mar 2007 12:00:11 -0000
@@ -355,7 +355,6 @@
@file{.cvsignore}. When you have a Gnulib source file of the form
@file{lib/foo_.h}, the corresponding @file{lib/foo.h} is such a file.
-
@item
In projects which customarily omit from the CVS all files that generated
from other source files, all these files and directories would not be
@@ -375,3 +374,6 @@
because they were missing.
@end itemize
+
+The same holds for other version control systems than CVS, such as @samp{git}
+or @samp{svn}.
