Instructions for use of Yale CVS Repository

The SML/NJ CVS repository has moved to SourceForge. Please see Accessing the CVS repository.

Mailing list

Since Yale's CVS repository is not used any more, the old mailing list, smlnj-cvs@rum.cs.yale.edu has also become useless. It has been replaced by smlnj-commits.

CVS Hints

  1. It is recommended to have a ~/.cvsrc file containing 
    	% cat ~/.cvsrc
	update -P -d
	checkout -P
	%
    The -P tells CVS to prune empty directories. The -d tells CVS to add new directories that have been created in the repository since the last update.

  2. When using `cvs import' it's useful to first try a dry run `cvs -n import' so you can fix the -I options (i.e. what files to ignore) or any other problems. Note that symbolic links are ignored by import. The global -n option for cvs suppresses any action and only generates reports of what the command would do.

Advice on Managing Branches

See Matthias's page with notes on managing private development branches.

Also, see this follow-up advice on branching from Stefan.

Reminder: Tag all of smlnj module when committing

Matthias Blume, 31 Mar 2000

This is a reminder to everybody who is checking stuff into the CVS repository that they should tag the _entire_ repository (actually -- the entiry "smlnj" module if what you are doing is compiler-related). Otherwise tags are much less useful.

In this case I wanted to compare my "blume_main_v110p26p2_0" with the version _before_ that. For this, I tried to use the previous tag -- which was created by Alan. However, as it turns out, Alan tagged only those files he actually changed. As a result, CVS gave me only those files.

In other words, if a file does not have a certain tag, then it is considered non-existent. There is a flag to "cvs update" that lets one change this behavior to "use the most recent version", but this is also not what I wanted.

The other "solution" would be to really always tag "before" and "after" a commit. My point is that "before" tags are completely redundant if "after" tags are properly applied to the entire repository.

My current workaround is to use dates. (This proved a bit tricky because it wasn't obvious from the outset relative to which timezone the date would be interpreted... :)

Dave MacQueen
Last modified: Fri Apr 21 16:33:41 EDT 2000