Update/remove references to the CVS repository.

HACKING

@@ -164,210 +164,6 @@ aclocal.m4, or any Makefile.in.  Such patches are often large, and
 we're just going to regenerate those files anyway.
 
 
-CVS conventions ======================================================
-
-- We use CVS to manage the Guile sources.  The repository lives on
-subversions.gnu.org, in /cvs; you will need an
-account on that machine to access the repository.  Also, for security
-reasons, subversions presently only supports CVS connections via the SSH
-protocol, so you must first install the SSH client.  Then, you should
-set your CVS_RSH environment variable to ssh, and use the following as
-your CVS root:
-
-	:ext:USER@subversions.gnu.org:/cvs
-
-Either set your CVSROOT environment variable to that, or give it as
-the value of the global -d option to CVS when you check out a working
-directory.
-
-For more information on SSH, see http://www.openssh.com.
-
-The Guile sources live in several modules:
-
-  - guile-core --- the interpreter, QuickThreads, and ice-9
-  - guile-tcltk --- the Guile/Tk interface
-  - guile-tk --- the new Guile/Tk interface, based on STk's modified Tk
-  - guile-rgx-ctax --- the Guile/Rx interface, and the ctax implementation
-  - guile-scsh --- the port of SCSH to guile, talk to Gary Houston
-  - guile-www --- A Guile module for making HTTP requests.
-  - guile-statprof --- an experimental statistical profiler.
-
-There is a mailing list for CVS commit messages; see README for details.
-
-- The guile-core tree is now versioned similarly to the Linux kernel.
-Guile now always uses three numbers to represent the version,
-i.e. "1.6.5".  The first number, 1, is the major version number, the
-second number, 6, is the minor version number, and the third number,
-5, is the micro version number.  Changes in major version number
-indicate major changes in Guile.
-
-Minor version numbers that are even denote stable releases, and odd
-minor version numbers denote development versions (which may be
-unstable).  The micro version number indicates a minor sub-revision of
-a given MAJOR.MINOR release.
-
-- A default CVS checkout will get the current unstable development
-tree.  However, for each stable release, a CVS branch is created so
-that release (and ongoing maintenance) of the stable version can
-proceed independent of the development of the next unstable version.
-To check out a particular stable branch, you just need to specify "-r
-branch_release-X-Y" to your CVS checkout command (or to any update).
-For example, if you wanted to check out the 1.6 stable branch, you
-would specify "-r branch_release-1-6".
-
-So, for example, during a normal development cycle, work will proceed
-on an unstable version, say 1.5.X, until it is decided that it's time
-for a stable release.  At that point, a branch named
-branch_release-1-6 will be created, and the version numbers on the
-HEAD of the CVS tree (the trunk, i.e. what you get by default), will
-be changed to reflect the new unstable version 1.7.X.  Then unstable
-development will proceed on the unstable version, while the stable
-1.5.X branch is fixed up for the eventual 1.6.0 release.
-
-Anytime you want to yank an existing checked out tree to the stable
-branch, you can run a command like this:
-
-  cvs -z3 update -r branch_release-1-6 -Pd
-
-This will yank the working directory over on to the stable release
-branch.  Note that this directory will track that branch from then on
-unless you do something to yank it back to the main (unstable) trunk.
-
-To go back to the unstable branch, you can use
-
-  cvs -z3 update -A -Pd
-
-Note that in either case, you should probably make sure you've
-commited or removed all local changes before running the commands or
-you're likely to have some unexpected results.
-
-Finally note that one approach, should you need to work on both
-branches, is to keep two trees checked out, one stable, the other
-unstable and you can work in whichever is appropriate.
-
-To save some initial bandwidth, you can check out either the stable
-tree or the unstable tree, and then do something like this:
-
-  cp -a core-unstable core-1.5
-  cd core-1.5
-  cvs -z3 update -r branch_release-1-6 -Pd
-
-- The stable and unstable CVS trees are distinct, and no changes will
-automatically propagate between them.  If you make changes that need
-to show up both places, you'll need to apply the changes both places.
-You *might* be able to do this with a cvs command, but often you'll
-probably need to apply the changes by hand or risk migrating
-superfluous modifications between the two versions.  This is
-particularly important when moving a change from the unstable branch
-to the stable branch.
-
-- In general, please don't be adventurous with the stable branch.  We
-mostly want bugfixes, documentation improvements, build improvements,
-etc., though exceptions will doubtless exist.
-
-- There are a few CVS tagging conventions which follow the Scheme
-convention that dashes are used to separate words within a single
-symbol, and so dashes bind more tightly than underscores.  This means
-that foo-bar_baz-bax indicates that foo-bar is somehow separate from
-baz-bax.  The conventions are as follows:
-
-  Branch root tags:
-  -----------------
-  anytime just before you create a branch it's a good
-  idea to create a normal tag so that you can refer to the branch point
-  on the main trunk as well as on the branch.  So please use a tag of
-  the form
-
-    branch-root-release-1-X
-
-  or more generally, for other non-release branches:
-
-    branch-root_FOO
-
-  Branch tags:
-  ------------
-  for the branch tag itself please use
-
-   branch_release-1-6
-
-  or more generally, for other non-release branches:
-
-    branch_FOO
-
-  Merge tags:
-  -----------
-  Whenever you're merging a branch back into the trunk (or into another
-  branch repeatedly) you need to tag the branch each time you merge.  If
-  you don't do that, you won't be able to merge repeatedly without
-  possibly tedious conflicts.  For those tags, we suggest:
-
-    branch-merge_SOME-FOO_to_SOME-BAR_1
-    branch-merge_SOME-FOO_to_SOME-BAR_2
-    ..
-
-  As an example, SOME-BAR might be trunk, or even perhaps another branch
-  like branch-mvo-super-fixes :>
-
-  More mundanely, you might have
-
-    branch-merge_release-1-6_to_trunk_1
-
-  (Merging the stable branch to the trunk like this
-   will probably be much more common, when it happens, than the
-   reverse for the reasons mentioned above.
-
-  Release tags:
-  -------------
-  When releasing a new version of guile, please use:
-
-    release_X-Y-Z
-
-  i.e.
-
-    release_1-6-0
-
-- If you hack on a stable branch, please apply any relevant patches or
-fixes to the current unstable version (the main CVS trunk) as well.
-Similarly, please back-port any important fixes to the unstable CVS
-tree to the current stable branch.
-
-- We check Makefile.am and configure.in files into CVS, but the
-"autogen.sh" script must be run from the top-level to generate the
-actual "configure" script that then must be run to create the various
-Makefile-s to build guile. The general rule is that you should be able
-to check out a working directory of Guile from CVS, and then type
-"./autogen.sh", then "configure", and finally "make".  No
-automatically generated files should be checked into the CVS
-repository.
-
-- The .cvsignore file is contained in the repository, to provide a
-reasonable list of auto-generated files that should not be checked in.
-This, however, prohibits one from having local additions to the
-.cvsignore file (yes, you can modify it and never check it in, but
-that doesn't seem to be a good solution to me).  To get around this
-problem, you might want to patch your cvs program so that it uses a
-.cvsignore-local file (say) instead of the one from the repository.  A
-patch for this can be found at the very end of this file.
-
-- (Automake 1.4 only) Be sure to run automake at the top of the tree
-with no arguments.  Do not use `automake Makefile' to regenerate
-specific Makefile.in files, and do not trust the Makefile rules to
-rebuild them when they are out of date.  Automake 1.4 will add
-extraneous rules to the top-level Makefile if you specify specific
-Makefiles to rebuild on the command line.  Running the command
-`autoreconf --force' should take care of everything correctly.
-
-- Make sure your changes compile and work, at least on your own
-machine, before checking them into the main branch of the Guile
-repository.  A good way for testing this is to run "make distcheck".
-If you really need to check in untested changes, make a branch.
-
-- Include each log entry in both the ChangeLog and in the CVS logs.
-If you're using Emacs, the pcl-cvs interface to CVS has features to
-make this easier; it checks the ChangeLog, and generates good default
-CVS log entries from that.
-
-
 Coding standards =====================================================
 
 - Before contributing larger amounts of code to Guile, please read the

NEWS

@@ -38,6 +38,14 @@ indicating length of the `scm_t_option' array.
 
 Changes in 1.8.5 (since 1.8.4)
 
+* Infrastructure changes
+
+** Guile repository switched from CVS to Git
+
+The new repository can be accessed using
+"git-clone git://git.sv.gnu.org/guile.git", or can be browsed on-line at
+http://git.sv.gnu.org/gitweb/?p=guile.git .  See `README' for details.
+
 * Bugs fixed
 
 ** `scm_add_slot ()' no longer segfaults (fixes bug #22369)

README

@@ -1,5 +1,5 @@
 !!! This is not a Guile release; it is a source tree retrieved via
-anonymous CVS or as a nightly snapshot at some random time after the
+Git or as a nightly snapshot at some random time after the
 Guile 1.8 release.  If this were a Guile release, you would not see
 this message. !!!  [fixme: zonk on release]
 
@@ -364,14 +364,24 @@ guile-readline:
         library on your system.
 doc:	Documentation (see above).
 
-Anonymous CVS Access and FTP snapshots ===============================
+Git Repository Access ================================================
 
-We make the developers' working Guile sources available via anonymous
+Guile's source code is stored in a Git repository at Savannah.  Anyone
-CVS, and by nightly snapshots, accessible via FTP.  See the files
+can access it using `git-clone' from one of the following URLs:
-`ANON-CVS' and `SNAPSHOTS' for details.
 
-If you would like to receive mail when people commit changes to the
+  git://git.sv.gnu.org/guile.git
-Guile CVS repository, you can subscribe to guile-cvs@gnu.org by the
+  http://git.sv.gnu.org/r/guile.git
-Mailman mailing list interface at
 
-  <http://mail.gnu.org/mailman/listinfo/guile-cvs>
+Developers with a Savannah SSH account can also access it from:
+
+  ssh://git.sv.gnu.org/srv/git/guile.git
+
+The repository can also be browsed on-line at the following address:
+
+  http://git.sv.gnu.org/gitweb/?p=guile.git
+
+For more information on Git, please see:
+
+  http://git.or.cz/
+
+Please send problem reports to <bug-guile@gnu.org>.

README.CVS

@@ -1,26 +0,0 @@
-When Guile is obtained from CVS, a few extra steps must be taken
-before the usual configure, make, make install.  You will need to have
-up-to-date versions of the tools listed in HACKING (see below),
-correctly installed.  i.e., they must be found in the current PATH and
-not shadowed or otherwise broken by files left behind from other
-versions.
-
-"up-to-date" means the latest released versions at the time that Guile
-was obtained from CVS.  Sometimes older or newer versions will work.
-
-In addition to the guile/guile-core module that holds the main
-sources, you also need the two modules guile/guile-scripts and
-guile/workbook.  For example, you can use this command to check out
-all three modules:
-
-  $ cvs -d:ext:anoncvs@savannah.gnu.org:/cvsroot/guile \
-    co guile/guile-core guile/guile-scripts guile/workbook 
-
-Then you must run the autogen.sh script in guile/guile-core:
-
-  $ cd guile/guile-core
-  $ ./autogen.sh
-
-For more information about hacking Guile and some troubleshooting
-hints, see the file HACKING.  It can be found in guile/guile-core and
-guile/workbook/build/dist-files/.

autogen.sh

@@ -31,7 +31,7 @@ autoreconf -i --force --verbose
 echo "guile-readline..."
 (cd guile-readline && ./autogen.sh)
 
-# Copy versions of config.guess and config.sub from Guile CVS to
+# Copy versions of config.guess and config.sub from Guile's repository to
 # build-aux and guile-readline.
 cp -f config.guess config.sub build-aux/
 cp -f config.guess config.sub guile-readline/