7.4 CVS Etiquette Guidelines

Since Crystal Space has enough developers to warrant the use of CVS to manage its code base, there are some rules you need to keep in mind if you are going to be making changes of any sort to the CVS source tree.

First off, to access the CVS repository anonymously, use this CVSROOT setting:

:pserver:anonymous@cvs.sourceforge.net:/cvsroot/crystal

The password for the `anonymous' account is the empty string--that is, just press the RETURN key at the `Password:' prompt.

For further instructions, please refer to the following document:

http://sourceforge.net/cvs/?group_id=649

Once you've logged in, checkout the module `crystal' to download the source code to the `CS' directory. See the documentation for your CVS client on how to do this.

If you do not have a developer account, you will be able to check out files, but will not be able to commit any changes, so the rest of this document doesn't really apply to you.

If you do have developer account, you will have to access the CVS repository via SSH, the secure shell. Instructions can be found at this location:

http://sourceforge.net/cvs/?group_id=649

Having a developer account implies you will be able to make changes to the code. You should read the rest of this document before making any changes.

Below are some guidelines you should follow before committing files. Also be sure to read the important portability guidelines in the Portability section. See section Portability.

1. Always perform an `update' before committing new or changed files, and then rebuild everything from scratch after updating. Do not rely on dependencies! If there were any conflicts during the update, resolve them. If there were any merges, examine them to ensure that the merged code still accurately reflects your changes.
2. If you worked on the engine internals or on the renderers, run walktest using `flarge' and visit various locations which exercise the engine's features, such as the doughnut in the street and the foggy corridor.
3. If it works, commit everything you have modified, not just parts of your modifications. If you have created new files, please be certain that you have used the CVS `add' command before committing in order to ensure that the new files actually get added to the repository.
4. Do another `update' after committing everything. Take a look at the output to see if you really committed everything you intended to commit.
5. Do another rebuild to ensure your changes didn't collide with somebody else's recent changes.
6. For large and important modifications, post a description of your changes to the main mailing list, crystal-main@lists.sourceforge.net. This is especially important if your changes may have affected other ports which must be updated by other developers as a consequence.

This might look overdone to some people, but you should remember that we are all working together with the same source. A bug in your code can cripple the entire project.

One final thing to remember is that you should never commit files that you know will stop the progress of other developers. The CVS repository is the place to commit completed code, not code that needs debugging because you can't find a certain bug. Other developers should not have to stop and track down your bugs just so they can proceed with their own coding. When you've committed code, please monitor the mailing list regularly for any signs that you've caused a problem somewhere. This is part of the responsibility that goes with the ability to commit code.

This document was generated using texi2html 1.76.