The full documentation for CVS is online, in info format (use 'info
cvs' or run emacs and type C-h i). A good source of tips is the CVS
-FAQ, in /local/doc/gnu/CVS.FAQ.
+FAQ, in /local/doc/gnu/CVS.FAQ. Bradley C. Kuszmaul provides a "to
+the point" introduction to CVS at
+
+ http://arch.cs.yale.edu:8080/~bradley/cvs-instructions
This note is supposed to be a set of guidelines for how to use CVS at
Glasgow, and will probably evolve in time. The main thing to remember
The following guidelines should mean we don't step on each other's
toes too much. Ok, here's what you do:
-* Firstly, identify which areas of the source tree you'll be working
- on. The directory structure looks like this:
+
+Using Remote CVS
+----------------
+
+* (only if using CVS remotely, i.e. not at Glasgow):
+
+ To use remote CVS, you need to supply me with a username and
+ encrypted password. Once you've done that and the account has been
+ set up, you need to do:
+
+ cvs -d <username>@solander.dcs.gla.ac.uk:/local/fp/src/cvsroot login
+
+ CVS will ask for a password. You only need to enter the password once,
+ it will be recorded in .cvspass in your home directory.
+
+ setenv CVSROOT :pserver:<username>@solander.dcs.gla.ac.uk:/local/fp/src/cvsroot
+
+ The CVSROOT environment variable will be recorded in the checked-out
+ tree, so you don't need to set this every time either. Ignore the
+ instructions for setting CVSROOT below.
+
+
+Using CVS for the First Time
+----------------------------
+
+* (ok, everybody now...) Firstly, identify which areas of the source
+ tree you'll be working on. The directory structure looks like this:
fptools/ghc GHC
fptools/hslibs Haskell Libraries
the -P flag to 'checkout' says prune empty directories, which is
normally what you want.
+
+Checking Out a Source Tree
+--------------------------
+
* Check out your sources. The Approved Way (at least by me) to do
this is as follows:
work on. For a GHC build, for instance, you need at least ghc and
hslibs.
+
+Committing Your Changes
+-----------------------
+
* Build the software, if necessary. Unless you're just working on
documentation, you'll probably want to build the software in order
to test any changes you make. For GHC, instructions can be found
list saying which files changed, and giving the commit message.
For a multiple-file change, you should still get only *one* message.
+
+General Hints
+-------------
+
* As a general rule: commit changes in small units, preferably
addressing one issue or implementing a single feature. Provide a
descriptive log message so that the repository records exactly which
each day and how we're doing in relation to previous verions. This
idea is truely wrecked if the compiler won't build in the first place!
-Ok, that'll do for now.
+* To check out extra bits into an already-checked-out tree, use the
+ following procedure. Suppose you have a checked-out fptools tree containing
+ just ghc and hslibs, and you want to add nofib to it:
+
+ cd fptools
+ cvs checkout nofib
+
+ or:
+
+ cd fptools
+ cvs update -d nofib
+
+ (the -d flag tells update to create a new directory). If you just want
+ part of the nofib suite, you can do
+
+ cd fptools
+ cvs checkout nofib/spectral
+
+ This works because 'nofib' is a module in its own right, and spectral
+ is a subdirectory of the nofib module. The path argument to checkout
+ must always start with a module name. There's no equivalent form of
+ this command using update.
+
+Ok, that'll do for now. If there's anything else you'd like to see in
+this file, just let me know.
Simon Marlow <simonm@dcs.gla.ac.uk>
projects / ghc-hetmet.git / blobdiff