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. Please refer to the chapters 6 and 7 in SF's site documentation for the technical access details for your operating system. For historical reasons, the CVS server is called cvs.ijbswa.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://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ijbswa/, which might help with visualizing how these pieces fit together.
Branches are used to fork a sub-development path from the main trunk. Within the current module where the sources are, there is always at least one "branch" from the main trunk devoted to a stable release series. The main trunk is where active development takes place for the next stable series (e.g. 3.2.x). So just prior to each stable series (e.g. 3.0.x), a branch is created just for stable series releases (e.g. 3.0.0 -> 3.0.1 -> 3.0.2, etc). Once the initial stable release of any stable branch has taken place, this branch is only used for bugfixes, which have had prior testing before being committed to CVS. (See Version Numbers below for details on versioning.)
This will result in at least two active branches, which means there may be occasions that require the same (or similar) item to be checked into to two different places (assuming its a bugfix and needs fixing in both the stable and unstable trees). This also means that in order to have access to both trees, both will have to be checked out separately. Use the cvs -r flag to check out a branch, e.g: cvs co -r v_3_0_branch current.
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. There are differing guidelines for the stable branch and the main development trunk, and we ask anyone with CVS access to strictly adhere to the following guidelines:
Basic Guidelines, for all branches:
Never (read: never, ever) be tempted to commit that 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.
Stable branches are handled with more care, especially after the initial *.*.0 release, and we are just in bugfix mode. In addition to the above, the below applies only to the stable branch (currently the v_3_0_branch branch):
Do not commit anything unless your proposed changes have been well tested first, preferably by other members of the project, or have prior approval of the project leaders or consensus of the devel list.
Where possible, bugfixes and changes should be tested in the main development trunk first. There may be occasions where this is not feasible, though.
Alternately, proposed changes can be submitted as patches to the patch tracker on Sourceforge first: http://sourceforge.net/tracker/?group_id=11118&atid=311118. Then ask for peer review.
Do not even think about anything except bugfixes. No new features!