mirror of
https://git.savannah.gnu.org/git/guile.git
synced 2025-04-29 19:30:36 +02:00
Update/remove references to the CVS repository.
This commit is contained in:
Ludovic Courtès
parent
5995c6d801
commit
4b824aae11
5 changed files with 28 additions and 240 deletions
204
HACKING
204
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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue