diff options
author | Ludovic Courtès <ludo@gnu.org> | 2008-03-27 21:50:06 +0100 |
---|---|---|
committer | Ludovic Courtès <ludo@gnu.org> | 2008-04-08 00:08:27 +0200 |
commit | 4b824aae11e2dbb83c3ac13c18866c09c5939699 (patch) | |
tree | 9c8586d5dfe00175eb57bbc980178f87f35bf83d | |
parent | 5995c6d8013789b0d18ea0419e63c8377d01734b (diff) | |
download | guile-4b824aae11e2dbb83c3ac13c18866c09c5939699.tar.gz |
Update/remove references to the CVS repository.
-rw-r--r-- | HACKING | 204 | ||||
-rw-r--r-- | NEWS | 8 | ||||
-rw-r--r-- | README | 28 | ||||
-rw-r--r-- | README.CVS | 26 | ||||
-rwxr-xr-x | autogen.sh | 2 |
5 files changed, 28 insertions, 240 deletions
@@ -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 @@ -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) @@ -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>. diff --git a/README.CVS b/README.CVS deleted file mode 100644 index 93ccb0a61..000000000 --- a/README.CVS +++ /dev/null @@ -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/. diff --git a/autogen.sh b/autogen.sh index ac5f75b81..d125d9f48 100755 --- a/autogen.sh +++ b/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/ |