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
HCoop / bpt / guile.git / commitdiff