English

German

Japanese

America

Asia

Australia

Europe

Searching XEmacs Quick Links

About XEmacs

Getting XEmacs

Customizing XEmacs

Troubleshooting XEmacs

Developing XEmacs

XEmacs CVS Repository

The development mainline of XEmacs (currently version 21.5) and the stable version of XEmacs (version 21.4) reside in Mercurial repositories on hg.debian.org from which you may browse the latest checked-in code. Please see the introduction to the XEmacs Mercurial Repository for instructions on its use.

cvs.alioth.debian.org hosts two different CVS (Concurrent Versions System) trees for XEmacs. The primary CVS archive contains the XEmacs package sources. These sources provide a large number of customizable externally-provided packages for XEmacs. The other CVS archive contains the source for this website and all of its mirrors.

Quick start guide
What is CVS
Using the XEmacs CVS server
Info on Packages
Commit (R/W) access to the CVS trees
Recent news

Quick Start Guide

First, you need to do, just once:

    cvs -d :pserver:anonymous@cvs.alioth.debian.org:/cvsroot/xemacs login
There is no password, so press Enter when prompted for a password.

Retrieve a copy of the XEmacs packages like this:

    cvs -z3 -d :pserver:anonymous@cvs.alioth.debian.org:/cvsroot/xemacs \
      checkout packages

Retrieve a copy of the XEmacs website sources like this:

    cvs -z3 -d :pserver:anonymous@cvs.alioth.debian.org:/cvsroot/xemacs \
      checkout xemacsweb

What is CVS?

CVS is a hierarchical revision control system that not only keeps track of older versions (natch) but also allows spiffy things like separate branches for concurrent development and coordination services for large numbers of developers. CVS is currently the defacto industry standard source code control system for open source software projects. Knowledge of CVS and ssh are becoming required skills in the free software community. Regular contributors to XEmacs are strongly encouraged to get CVS write access to the source repository. This distributes most of the patch-tracking work to those most qualified to do it, namely the patch authors. XEmacs source code maintenance is basically organized on the bazaar model - we'd like to have as many people as possible, including you, making high quality contributions to the source code, in parallel. But even if you are just a lurker with no desire to make any modifications to the tree, CVS gives you a painless way to upgrade between versions.

Be warned that these trees are large! The lisp packages tree takes up > 120MB of disk space. (The core sources retrieved from the Mercurial archive also take up approximately 120MB.)

Using the XEmacs CVS server

If you're interested in using the XEmacs CVS trees directly using remote CVS, you'll need a version of CVS >= 1.9. This server uses the :pserver: protocol, with read-only access available for user anonymous, with a blank password. The process goes something like this:

First you need to log into the CVS server. You only need to do this once, as it will create a file in your home directory called .cvspass with the necessary data.

    cvs -d :pserver:anonymous@cvs.alioth.debian.org:/cvsroot/xemacs login
There is no password, so press Enter when prompted for a password.

Now go the the place you want to put the XEmacs package tree, and check out the packages.

    cvs -z3 -d :pserver:anonymous@cvs.alioth.debian.org:/cvsroot/xemacs \
      checkout packages

The -z3 option enables compression during transit, and speeds things along tremendously. (Some places recommend a setting of -z9, but it places a much greater CPU load on the CVS server, so we ask you to use -z3.

As it is ignored if not used on a network connection, you might want to add it to your ~/.cvsrc file for future use. You could use a line like this:

  cvs -z3

Another useful option to put in your ~/.cvsrc is

  diff -u

which will make sure all diffs are generated as unified diffs, and

  checkout -P
  update -Pd

which will make update get rid of empty directories and create any new ones in the tree. There have also been reports that some files are not created unless -Pd is used with cvs update.

When there is an upstream update, you can get the whole skinny quick, fast and relatively painlessly with the following command (executed from the directory created by cvs checkout).

  cvs update

Again, you probably will want to add the -P switch (after the word update!) to properly track any changes to the directory structure if you do not have that in your ~/.cvsrc file.

Info on Packages

For those of you wishing to work with XEmacs, you should probably know about the packaging system. All the details are available here, but for those of you impatient to jump right in, here's the deal with the CVS trees related to packages.

Each individual package can be grabbed from this CVS server via the same process described above, with the replacement of <PACKAGE-NAME> for the module name. For example:

    cvs -z3 -d :pserver:anonymous@cvs.alioth.debian.org:/cvsroot/xemacs \
      checkout gnus

will get you a copy of the most recent gnus sources.

There is also an 'uber-package' that will grab all of the packages at once, and even set them up for easy compilation and installation. To use that, simple grab the module packages.

Commit (R/W) access to the CVS trees

A number of people are able to commit directly to the CVS tree using CVS commands. We are trying to increase this number, which has the following advantages:

The CVS history will contain the true author of a change, which makes tracking changes easier, and gives credit where credit is due.
Committers are more likely to take responsibility for their changes when they are directly modifying the CVS repository themselves.

To qualify to be a committer, you should have one of the following qualifications:

A history of submitting successful patches to xemacs-patches
A maintainer of a lisp package gets automatic CVS commit access to the portion of the CVS repository that contains the package.

Currently we are adding new committers using the following method (which may change):

Make sure ssh version 2 is installed on your computer.
Create a ssh public key. Here is some unsolicited advice on maintaining your ssh key:

In general, you should only have ONE identity that you expose to the outside world. Create only ONE key pair using ssh-keygen specifying RSA encryption. This will create 2 files: ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub.

After you have created your keys, copy the ~/.ssh/id_rsa file to all the machines you run ssh from.

Also, append your public key file ~/.ssh/id_rsa.pub to ~/.ssh/authorized_keys2 on all the machines you run ssh to.

When people ask you for your public ssh key, just send them the contents of ~/.ssh/id_rsa.pub.
Create an account on alioth.debian.org and send the CVS Administrator your user name and your public ssh key. The CVS administrator will take care of the administrivia to give you access.
Add this stanza to your ~/.ssh/config file (create it if necessary):
```
host cvs.alioth.debian.org
        Compression       yes
        CompressionLevel  3
        KeepAlive         yes
        Protocol          2
        ForwardX11        no
        ForwardAgent      no
      
```
You can debug your ssh connection by doing something like ssh -v cvs.alioth.debian.org, and on connecting (there will be no prompt) entering the command noop, and if ssh is working, getting the response ok. You can use command version to determine the CVS server version.
For convenience create a shell script, perhaps named `cvs-rw', that looks like this:
```
#!/bin/sh
exec env CVS_RSH=ssh cvs -w -z3 \
-d:ext:your-username@cvs.alioth.debian.org:/cvsroot/xemacs ${1+"$@"}
      
```
You can test this by running a harmless CVS command, like cvs-rw diff version.sh.
When you want to do a commit, do
```
cvs-rw commit [commit-args ...]
      
```
There is an important bug even in the latest versions of CVS. For most operations, CVS will automatically recurse into subdirectories, and execute the operation in each subdirectory. For example, in the top-level directory .../packages, executing cvs update . will update the top-level directory, as well as mule-packages, mule-packages/edict and so on.

The bug occurs only for the commit operation. If (1) you do a recursive commit, and (2) there are changes to commit in both the top level and lower level directories, the changes in the top level directory will not get committed. For example, as a new developer you wish to add your photo to ./etc/photos. So you copy newface.png and newfacem.png to ./etc/photos, and use cvs add to inform the CVS server of their existence. Since the lowest ChangeLog on that path is in the top directory, you note "* newface*.png: New file" in ./ChangeLog. If you now execute cvs-rw commit ., cvs will report "Committing newface.png ... Committing newfacem.png." ./ChangeLog has not been committed, and your change will not be visible to other developers!

Nor does it help to give an explicit list like
```
cvs-rw commit ./ChangeLog ./INSTALL ./Local.rules.mk
      
```
./ChangeLog will still be omitted. The fix is simple: just repeat the commit. Since all lower-level files have been committed, only ./ChangeLog remains. Condition (2) is not satisfied (there is no work in subdirectories), so ./ChangeLog is committed to the repository.

It is rumored that if you are using PCL-CVS or patcher.el you are far less likely to be bitten by this bug.

News and changes

2009-11-25

Changes by Vin:

Since only the packages and the website are now maintained in CVS, I removed much of the material from this page (including the 7 year-old News items).

Conform with <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Automatically validated by PSGML