mirror/guile
mirror/guile
1
Fork 0
mirror of https://git.savannah.gnu.org/git/guile.git synced 2025-04-29 19:30:36 +02:00
Code Activity

Update/remove references to the CVS repository.

Browse source
This commit is contained in:
Ludovic Courtès 2008-03-27 21:50:06 +01:00
parent 5995c6d801
commit 4b824aae11
5 changed files with 28 additions and 240 deletions
Download patch file Download diff file Expand all files Collapse all files

204
HACKING
View file

@ -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

8
NEWS
View file

@ -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)

28
README
View file

@ -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
CVS, and by nightly snapshots, accessible via FTP. See the files
`ANON-CVS' and `SNAPSHOTS' for details.
Guile's source code is stored in a Git repository at Savannah. Anyone
can access it using `git-clone' from one of the following URLs:
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 the
Mailman mailing list interface at
git://git.sv.gnu.org/guile.git
http://git.sv.gnu.org/r/guile.git
<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>.

26
README.CVS
View file

@ -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/.

2
autogen.sh
View file

@ -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/