If you become part of the active development team, you will eventually need write access to our holy grail, the CVS repository. One of the team members will need to set this up for you. Please read this chapter completely before accessing via CVS.
The project's CVS repository is hosted on SourceForge. For historical reasons, the CVS server is called ijbswa.cvs.sourceforge.net, the repository is called ijbswa, and the source tree module is called current.
Within the CVS repository, there are modules and branches. As mentioned, the sources are in the current "module". Other modules are present for platform specific issues. There is a webview of the CVS hierarchy at http://ijbswa.cvs.sourceforge.net/viewvc/ijbswa/, which might help with visualizing how these pieces fit together.
At one time there were two distinct branches: stable and unstable. The more drastic changes were to be in the unstable branch. These branches have now been merged to minimize time and effort of maintaining two branches.
The source tree is the heart of every software project. Every effort must be made to ensure that it is readable, compilable and consistent at all times. We expect anyone with CVS access to strictly adhere to the following guidelines:
Basic Guidelines, for all branches:
Please don't commit even a small change without testing it thoroughly first. When we're close to a public release, ask a fellow developer to review your changes.
Your commit message should give a concise overview of what you changed (no big details) and why you changed it Just check previous messages for good examples.
Don't use the same message on multiple files, unless it equally applies to all those files.
If your changes span multiple files, and the code won't recompile unless all changes are committed (e.g. when changing the signature of a function), then commit all files one after another, without long delays in between. If necessary, prepare the commit messages in advance.
Before changing things on CVS, make sure that your changes are in line with the team's general consensus on what should be done.
Note that near a major public release, we get more cautious. There is always the possibility to submit a patch to the patch tracker instead.