guile/ANON-CVS

Anonymous CVS access to Guile ========================================

We make the current Guile sources available via anonymous CVS.  Please
keep in mind that these sources are strictly experimental; they will
usually not be well-tested, and may not even compile on some systems.
They may contain interfaces which will change.  They will usually not
be of sufficient quality for use by people not comfortable hacking the
innards of Guile.  Caveat!

However, we're providing them anyway for several reasons.  We'd like
to encourage people to get involved in developing Guile.  People
willing to use the bleeding edge of development can get earlier access
to new, experimental features.  Patches submitted relative to recent
sources will be easier for us to evaluate and install, since the
patch's original sources will be closer to what we're working with.
And it allows us to start testing features earlier.

Since the CVS tree is arranged for the convenience of the developers,
it requires GCC and GNU Make, which together support automatic
dependency management.  You will also need to install autoconf,
automake, and libtool; the recommended versions are listed in HACKING.

To check out a CVS working directory:

1) Install CVS version 1.9 or later on your system.

2) Log into the CVS server:

    $ cvs -d :pserver:anoncvs@subversions.gnu.org:/cvs login

   At the prompt for `CVS password:', simply press the enter key.
   Once you have logged in, your password is saved in ~/.cvspass, and you
   will not need to enter it again.

3) Check out a module:

    $ cvs -z 9 -d :pserver:anoncvs@subversions.gnu.org:/cvs checkout guile-core

   This should create a new directory `guile-core' in your current
   directory, and populate it with the current Guile sources.

   To check out all modules use:

    $ cvs -z 9 -d :pserver:anoncvs@subversions.gnu.org:/cvs checkout guile

4) In the top directory of the source tree, run the command `./autogen.sh'.
   This builds the configure script, Makefile.in, and other derived files
   used by the build system.

The modules available for checkout include:

  guile-core --- The scheme interpreter itself.
  guile-tcltk --- An interface between Guile and Tcl/Tk.
  guile-scsh --- An incomplete port of scsh to Guile.
  guile-rgx-ctax --- This has been discontinued; use Andrew Archibald's
	  distribution instead:
    ftp://ftp.red-bean.com/pub/guile/contrib/misc/guile-lang-allover-0.1.tar.gz

Once you have a working directory, you can bring it up to date easily
and efficiently:

1) Go to the top directory of the source tree.  That is, your current
   directory should be the one containing `configure.in', `README',
   and so on.

2) Do the update:
     $ cvs update

This will incorporate any changes the developers have made to Guile
since your last update into your source tree.


Change Notification ==================================================

If you would like to receive mail when people commit changes to the
Guile CVS repository, you can subscribe to guile-cvs@gnu.org by using
the Mailman mailing list interface at

  <http://mail.gnu.org/mailman/listinfo/guile-cvs>


Questions ============================================================

- It takes forever to do an update; what can I do to speed it up?

  CVS tries to be smart about what it sends; it will transmit and
  install only those files that have changed, and will sometimes
  transmit and apply patches instead, to save transmission time.

  It is also possible to have CVS compress transmitted data, using zlib.
  Put the following line in your ~/.cvsrc file:

  cvs -z 9

  See the CVS documentation for more details.

- What happens if I've changed files in my working directory, and then
  I do an update?

  If you have made local changes to your sources, the `cvs update'
  command will not overwrite them; instead, CVS will try to merge its
  changes with your changes, as if you had applied a patch.  Rejects are
  marked in the sources.

- How can I avoid horrible confusion when dealing with branches?

  Because the auto* tools are version control system agnostic, there is
  no support for regenerating files based on which branch of the source
  tree you are "on".  This means that "cvs update -r BRANCH" will
  probably leave you w/ inconsistent configure, config.status, etc.,
  which cannot be brought back into sync w/o re-running autogen.sh.

  So, the best advice is to:
   (1) dedicate a directory per branch; and
   (2) always run "./autogen.sh && ./configure ..." after a
       "cvs update -r BRANCH"

  If you do (1), you only need to do (2) once, so this is Recommended.