CMU Common Lisp developer resources

This page is intended for active developers of CMUCL, those who will modify wthe working sources.

Our public resources (they include delay-free access to the current working sources of CMUCL) are listed at http://www.cons.org/cmucl/.

Basic places

The machine that holds the CVS tree is named cvs2.cons.org.

The CVS tree for CMUCL is cvs2.cons.org:/home/CVS-cmucl

You can use the ftp space on this machine to put up project-related files. Directory /a/ftp/lisp is writeable by the whole group and reflects to http://www2.cons.org:8000/ftp-area. It is mirrored (daily or so) to ftp://ftp2.cons.org/pub/languages/lisp/cmucl/.

http://www2.cons.org:8000/CVS-cmucl/ access the CVS repository directly (individual files).

http://www2.cons.org:8000/ftp-area/cmucl/ is our ftp stuff, accessed without mirror delay.

http://www2.cons.org:8000/ftp-area/cmucl/cmucl-cvs-<date>.tar.gz is a tarfile of the contents of the CVS tree (daily).

http://www2.cons.org:8000/ftp-area/cmucl/cmucl-src-<date>.tar.gz is a tarfile of outchecked sources files from the CVS tree (daily).

http://www2.cons.org:8000/ftp-area/cmucl/src/ are the outchecked sources from the CVS tree, as individual files.

http://www2.cons.org:8000/cgi-bin/cvsweb-cmucl.cgi is an interacting browsing tools for CVS files. You can step trough the source tree interactivly and see histories and diffs between versions.

CMU Common Lisp CVS tree usage

Thanks to Jordan Hubbard of the FreeBSD project and Walnut Creek CDROM we have machine to use for our central CVS repository.

The CVS tree for CMUCL is located at

cvs2.cons.org:/home/CVS-cmucl

and the main source tree is

cvs2.cons.org:/home/CVS-cmucl/src

There are several alternatives to use it. Basically, you need an account on this machine and then check out files by setting the environment variable $CVSROOT to "cvs2.cons.org:/home/CVS-cmucl" when using from remote or to "/home/CVS-cmucl" for local checkout. Then, do a "cvs checkout src".

There are a number of alternatives to work with the tree, here are some:

Check out sources into your home directory on cvs2. Edit then there or carry them to your home machine with a transport of your choice. After editing them, transfer them back to the repository machine and commit them.
Remote CVS. You check out directly from the central repository directly to your home machine, change the files there and a commit will change the central repository. There are some protocols restrictions for this machine, see below.
Transfer a copy of the whole CVS repository (that is, the version control files, not outchecked files) to your home machine. You can checkout and change as you like, but to commit to the central repository, you need to adjust the file CVS/Root (every directory has one), which stores the name of the repository to commit to.

We are guests on this machine and several security restrictions apply. If you can, avoid using login protocols that transfer clear text passwords. Using ssh instead is the best choice.

Normally, remote CVS uses a protocol that is based on top of rsh and .rhosts. This isn't available here. I'm sorry to add some work here, but to use remote CVS, it is best to get ssh in addition to CVS. Set the environment variable CVS_RSH to "ssh".

There is also a standalone CVS server mode (which transfers clear text passwords) and Kerberos authentication (I'm unsure about possible usage on this machine). I hope we can agree of ssh for "real" remote CVS checkout. Transferring plains files to your machines is another issue, let me know what you need.

Locking, Updates, Synchronisation and such

If you're used to RCS and not to CVS, be warned that CVS does no locking. It tries to merge concurrent changes and is usually quite successful in doing so. But it is a good idea to "cvs update" your checked-out sources regularly. It tells about the files that someone else changed and are updated in your copy.

But, be carefule with "cvs update" when you transferred the outchecked files to your home machine manually. CVS remembers which version number your outchecked source has. An example:

You check out version 1.14 into your homedir on cvs2
You transfer version 1.14 to your home machine
Someone else changes the file to version 1.15
You make "cvs update" and your homedir copy on cvs2 is version 1.15 and CVS knows it was updated to 1.15
Then you transfer back the 1.14 file with your local changes from home and replace the 1.15 file. CVS then thinks your work is based on the 1.15 but in fact it is based on 1.14.

When you commit at this point, you will revert the changes someone else did between 1.14 and 1.15, because CVS thinks the file you edited was up-to-date, contained these changes and you removed the previous changes by purpose. If you didn't made a "cvs update" in between, CVS would know it should first tell you about the 1.15 changes and merge these into your working file, so everything is fine.

In a word, do a "cvs update" only when you can update all the files you're really working on. "cvs update" tells you which files were changed by someone else.

Transferring the whole CVS tree to your home

I found the best method to keep a local mirror of a CVS repository is using rsync over ssh. rsync transferrs only changes bits and uses ssh in compression mode. It is very efficient.

If you can't have a ssh connection

Use a ftp mirror. Ask me to copy the CVS tree into ftp space so you can use annonymous ftp. If you use a HTTP mirros, we can just add a symbolic link.
I could set up CTM, which transfers deltas by mail and works good for FreeBSD, but I need some time to set it up.

When you do a checkout to get plain files to work with, CVS remembers where the CVS repository was. If this is your local one, changed things will be commit to your local tree and won't end up in the central one.

You'll either have to transfer your changed files manually to a checkout-out tree that was checked out from the central CVS tree (i.e. in your homedir on the cvs machine).

Another situation is when you have an IP connection to the central repository that is capable of remote CVS, but you maintain a local copy for speed.

You can change the files where CVS remembers what repository it got things from. This is a file "CVS/repository" in every subdirctory of your checked-out files. jordans-hacks-for-remote-cvs.txt is a message of Jordan Hubbard how he commits to a local and the central repository at once. Note while people talked about CVSup in this message, this way doesn't have anything to do with CVSup.

Other things to point out:

This is a small and slow machine, but we are allowed to use CPU and disk space to rebuild CMUCL.
If you're using emacs with a recent version of VC, you can use a CVS repository, even a remote one, just as you used RCS files. VC will recognize which system controls the file you edit.
If you can't stop ssh from asking for a password, ask me for help, it's a bit tricky.
"cvs commit" commits all changed files in the current directory and all subdirs at once with the same log message. If you don't want this, you can start it on individual files. If you use emacs with VC, you commit individual files anyway.
"cvs commit" is supposed to give you a list of changed and added files in the editor buffer it prepares for your log message. You need cvs-1.8 or cvs-1.9 (I'm not sure) to have this when using a remote repository. Alternatively, "cvs update" always informs you about your local modifications, as does "cvs diff".

Backups

The machine is backup up regulary by the site it belongs to, but I have no prove or control. I mirror the src/ subdir to another machine under my control using a cronjob.

Some of you might want to keep a copy of the whole CVS repository at home also. If you do so, please drop me a note.