GGI ResSources


This document contains information on how to obtain the latest GGI source tree ,how to become an active "registered" developer and some rules for developers.
last updated on $Date: 1998/02/26 00:52:38 $


How to obtain the latest source tree of GGI

The current source tree for GGI is made available via CVS - The Concurrent Versions System which is a system to maintain efforts of several developers. To be able to access the repository, you need version 1.8 of CVS (or any later version that supports the :pserver: access method) and the supporting packages installed as well as direct access to internet. However, note that the sources are currently about 2MB (uncompressed) in size, so the first download as well as the update may take some time (although it may be compressed). For further information on how to use CVS as well as for the sources we suggest you visit the CVS page at http://www.loria.fr/~molli/cvs-index.html .

To retrieve a new version of cvs, get an up-to-date *.rpm or *.deb if you are using RedHat, Caldera, or Debian; if you are not using these distributions or like compiling things yourself, a GNU mirror (such as ftp://prep.ai.mit.edu/pub/gnu) will have a current CVS source. For the 'latest and greatest' fans, ftp://download.cyclic.com/pub/ has the latest 'development' releases available for you.

The sources are available from the following repositories, however, only the first listed will allow you to commit changes. If you want to do active development, please see also the notes for developers. Please note that the other repositories are mirrors of the first one and may therefore be up to one day behind the master repository. Also, when you check out the latest source, do not expect it to be stable, compile, or do anything useful at all - well, just a disclaimer :-). So, the repositories for current development you may choose from currently are:

To 'checkout' the source tree as a guest, you will have to do the following steps:

  1. set the CVSROOT environment variable to the repository where you want to get the source from. For example, type

    export CVSROOT=repository

    at the bash-prompt if you are using bash or a similar shell or type

    setenv CVSROOT repository

    at the csh-prompt if you are using csh or a similar shell where repository is one of the repositories listed above.
  2. now that you have told CVS where to get thing from, type

    cvs login

    this will prompt you for a password, which is "guest".
  3. now you can checkout the sources the first time by telling CVS to do a checkout. Just type

    cvs checkout ggi

    and watch CVS loading the sources. For a slow network connection, you may give the option '-z level' to gzip data sent.

For example, if you can repeat the following on your machine, you are in business:

$ cd /tmp
$ export CVSROOT=:pserver:guest@mat.cythere.com:/usr/local/cvs/ggi
$ cvs login
(Logging in to guest@mat.cythere.com:/usr/local/cvs/ggi)
CVS password: (type in guest)
$ cvs -z9 checkout ggi
[...etc....]

We generally let the mailing list know when changes are made to the repository, so if you wish to be aware of ongoing developments, please consider subscribing to the mailing list.

To update your source tree with cvs, simply change to the ggi subdirectory, and type 'cvs update -PAd'. It should be noted that once the repository is checked out, CVS/Root in each subdirectory of the ggi tree points to the repository; since this is used in lieu of the CVSROOT variable,environment variables need not be set with each use of a checked out source tree. Note however, that you will probably need to do a full checkout again if you want to change the repository.

How to become a developer

You want to join GGI development? You are warmly welcome. It is suggeste you subscribe to our mailing and ask if there are already people working in the field where you want to contribute. To get 'developers access' to the main repository, please mail Steffen Seeger, seeger@physik.tu-chemnitz.de and give a short description of what you want to do.

Hopefully Useful Rules for Developers

These are some rules that should allow to maximize the outcome of the efforts of multiple developers and help to avoid 'bad interaction' of several people working on the same sources. They are suggestions, but I (Steffen Seeger) think they are reasonable to stick to.

  1. Run 'cvs -n update -PAd ggi' before you start commiting changes to the repository. Save the stderr and stdout output and study them carefully if you have told CVS about all files you want to add to or delete from the repository. This also lists the files that you have modified, so analyze carefully if you really want to commit changes to the main repository. For instance QuickHacks you made during tracing down a bug must not end up in the repository. This doesn't mean you should not add debugging code, this is actually strongly recommended, but you should care not to break other peoples work accidently.
  2. Think twice times twice times (no typo! Think four times!) before commiting directory structures and before placing new files anywhere in the repository. CVS is very unkind if you want to change the direcory structure lateron Even if it be moving a directory up one level in the tree. If this happens to be neccessary anyway, contact the repository maintainer.
  3. If you have fixed some obvious minor bugs such as typos etc., commit them and mail the maintainers of the files changed a short bugreport. This is just that the maintainer knows about the changes you made.
  4. Before commiting fixes for major bugs that require rewriting some functions or fundamental changes discuss this with the maintainer things you discovered as bugs actually might not be real bugs or require other things.
  5. CVS does not substitute communication between developers. Keep this always in mind!