bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] Advertise for the Git server instead of the CVS server.


From: Benoit Sigoure
Subject: [PATCH] Advertise for the Git server instead of the CVS server.
Date: Thu, 4 Oct 2007 18:47:44 +0200

        * doc/gnulib-intro.texi (Steady Development): Mention the Git
        repository instead of the CVS one.
        * doc/gnulib-tool.texi (CVS Issues): Rename as `VCS Issues' and
        adjust accordingly.
        * doc/gnulib.texi (Introduction): Capitalize `Git'.
        * doc/maintain.texi: Mention Git were relevant.  Update the email
        address of the savannah hackers.
        * doc/standards.texi (Change Log Concepts): Mention Git.
---
 ChangeLog             |   12 ++++++++++++
 doc/gnulib-intro.texi |    3 ++-
 doc/gnulib-tool.texi  |   18 +++++++++---------
 doc/gnulib.texi       |    2 +-
 doc/maintain.texi     |   10 +++++-----
 doc/standards.texi    |    2 +-
 6 files changed, 30 insertions(+), 17 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index eb7de88..a0d6e30 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2007-10-03  Benoit Sigoure  <address@hidden>
+
+       Advertise for the Git server instead of the CVS server.
+       * doc/gnulib-intro.texi (Steady Development): Mention the Git
+       repository instead of the CVS one.
+       * doc/gnulib-tool.texi (CVS Issues): Rename as `VCS Issues' and
+       adjust accordingly.
+       * doc/gnulib.texi (Introduction): Capitalize `Git'.
+       * doc/maintain.texi: Mention Git were relevant.  Update the email
+       address of the savannah hackers.
+       * doc/standards.texi (Change Log Concepts): Mention Git.
+
 2007-10-03  Bruno Haible  <address@hidden>
 
        Port the stdio extensions to QNX (untested).
diff --git a/doc/gnulib-intro.texi b/doc/gnulib-intro.texi
index 00f5003..5661b44 100644
--- a/doc/gnulib-intro.texi
+++ b/doc/gnulib-intro.texi
@@ -276,7 +276,8 @@ information in the corresponding module description.
 Gnulib modules are continually adapted, to match new practices, to be
 consistent with newly added modules, or simply as a response to build
 failure reports.  We don't make releases, but instead recommend to use the
-newest version of Gnulib from the CVS, except in periods of major changes.
+newest version of Gnulib from the Git repository, except in periods of major
+changes.  The source tree can also be fetched via a read-only CVS repository.
 
 @node Openness
 @section Openness
diff --git a/doc/gnulib-tool.texi b/doc/gnulib-tool.texi
index f97c741..af46611 100644
--- a/doc/gnulib-tool.texi
+++ b/doc/gnulib-tool.texi
@@ -31,7 +31,7 @@ a real run without changing anything.
 * Initial import::              First import of Gnulib modules.
 * Modified imports::            Changing the import specification.
 * Simple update::               Tracking Gnulib development.
-* CVS Issues::                  Integration with CVS.
+* VCS Issues::                  Integration with Version Control Systems.
 @end menu
 
 
@@ -336,8 +336,8 @@ $ gnulib-tool --import
 
 This will create, update or remove files, as needed.
 
address@hidden CVS Issues
address@hidden CVS Issues
address@hidden VCS Issues
address@hidden VCS Issues
 
 All files created by @code{gnulib-tool}, except @file{gnulib-cache.m4},
 should be treated like generated source files, like for example a
@@ -347,20 +347,20 @@ should be treated like generated source files, like for 
example a
 
 @item
 In projects which commit all source files, whether generated or not, into
-CVS, the @code{gnulib-tool} generated files should all be committed.
+their VCS, the @code{gnulib-tool} generated files should all be committed.
 
 Gnulib also contains files generated by @command{make} (and removed by
 @code{make clean}), using information determined by @command{configure}
-They should not be checked into CVS, but instead added to
+They should not be checked into their VCS, but instead added to
 @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
+In projects which customarily omit from their VCS all files that generated
 from other source files, all these files and directories would not be
-added into CVS.  The only file that must be added to CVS is
+added into their VCS.  The only file that must be added to it is
 @file{gnulib-cache.m4} in the M4 macros directory.  Also, the script for
-restoring files not in CVS, customarily called @file{autogen.sh} or
+restoring files not in the VCS, customarily called @file{autogen.sh} or
 @file{bootstrap.sh}, will typically contain the statement for restoring
 the omitted files:
 
@@ -375,5 +375,5 @@ because they were missing.
 
 @end itemize
 
-The same holds for other version control systems than CVS, such as @samp{git}
+The same holds for all version control systems such as CVS, @samp{git}
 or @samp{svn}.
diff --git a/doc/gnulib.texi b/doc/gnulib.texi
index ebd1e5b..60ce018 100644
--- a/doc/gnulib.texi
+++ b/doc/gnulib.texi
@@ -71,7 +71,7 @@ Resources:
 @itemize
 @item Gnulib is hosted at Savannah:
       @url{http://savannah.gnu.org/projects/gnulib}.  Get the sources
-      through git or CVS from there.
+      through Git or CVS from there.
 @item The Gnulib home page:
       @url{http://www.gnu.org/software/gnulib/}.
 @end itemize
diff --git a/doc/maintain.texi b/doc/maintain.texi
index 6619d68..1829e88 100644
--- a/doc/maintain.texi
+++ b/doc/maintain.texi
@@ -129,7 +129,7 @@ a person is capable of doing the job will carry a lot of 
weight.
 As your final act as maintainer, it would be helpful to set up the
 package under @code{savannah.gnu.org} (@pxref{Old Versions}).  This will
 make it much easier for the new maintainer to pick up where you left off
-and will ensure that the CVS tree is not misplaced if it takes us a
+and will ensure that the Git tree is not misplaced if it takes us a
 while to find a new maintainer.
 
 @node Recruiting Developers
@@ -615,7 +615,7 @@ You can use whichever is the most convenient for you.
 
 @item
 The @code{gnulib} project on @code{savannah.gnu.org}, which you
-can access via anonymous CVS.  See
+can access via anonymous Git and CVS.  See
 @uref{http://savannah.gnu.org/projects/gnulib}.
 
 @end itemize
@@ -946,7 +946,7 @@ be a very useful thing to do.
 @cindex version control
 
 It is very important to keep backup files of all source files of GNU.
-You can do this using RCS, CVS or PRCS if you like.  The easiest way to
+You can do this using RCS, CVS, Git or PRCS if you like.  The easiest way to
 use RCS or CVS is via the Version Control library in Emacs;
 @ref{VC Concepts,, Concepts of Version Control, emacs, The GNU Emacs
 Manual}.
@@ -957,13 +957,13 @@ publicly accessible, be careful not to put anything in 
the repository or
 change log that you would not want to hand over to another maintainer
 some day.
 
-The GNU Project provides a CVS server that GNU software packages can
+The GNU Project provides a CVS or Git server that GNU software packages can
 use: @code{subversions.gnu.org}.  (The name refers to the multiple
 versions and their subversions that are stored in a CVS repository.)
 You don't have to use this repository, but if you plan to allow public
 read-only access to your development sources, it is convenient for
 people to be able to find various GNU packages in a central place.  The
-CVS Server is managed by @email{cvs-hackers@@gnu.org}.
+Git and CVS Servers are managed by @email{savannah-hackers@@gnu.org}.
 
 The GNU project also provides additional developer resources on
 @code{subversions.gnu.org} through its @code{savannah.gnu.org}
diff --git a/doc/standards.texi b/doc/standards.texi
index 46e6d0f..112def9 100644
--- a/doc/standards.texi
+++ b/doc/standards.texi
@@ -3496,7 +3496,7 @@ directory can use the change log of its parent 
directory--it's up to
 you.
 
 Another alternative is to record change log information with a version
-control system such as RCS or CVS.  This can be converted automatically
+control system such as RCS, CVS or Git.  This can be converted automatically
 to a @file{ChangeLog} file using @code{rcs2log}; in Emacs, the command
 @kbd{C-x v a} (@code{vc-update-change-log}) does the job.
 
-- 
1.5.3.4.209.g9e417





reply via email to

[Prev in Thread] Current Thread [Next in Thread]