cvs guidelines

rapple uses cvs to control versioning of code and other materials. if you are unfamilar with cvs then please take a moment to review the documentation on sourceforge.net or elsewhere on the web.

cvs has remained the versioning system of choice for a long time in the open source community but does suffer from a number of weaknesses. in order to address these a new system called subversion, currently under evaluation at sourceforge.net, has been proposed as the successor of cvs. once full support for subversion has been made available at sourceforge.net a decision will be taken by the rapple development team as to whether or not we should migrate.

the following guidelines govern the use of cvs within the rapple development team:

• top level directories in cvs are called modules and reflect the high level division of the project - never create a new module (it's a real pain getting rid of them!). within each module you can create (i.e., cvs add) new files and directories as you see fit ;)
• check-in your changes regularly (please do not delay checking in until you are working on a large number of files as this complicates rolling back changes if required)
• be sure to regularly update (with the -dP option!) your local working copy so as to incorporate changes from other developers as early as possible.
• wherever reasonable try to ensure that your code at least compiles cleanly (even if it is not completely functional) before commiting your changes (pls do listen to compiler warnings etc.) - this helps insulate other developers from your changes.
• check-in comments should be preceeded where applicable by a code (e.g., for the feature or bug that you are working on) e.g., "51620: fix for title digest of XML parser". this is really just a convention to help us find stuff later on.
• check-in comments should be succint, functional and professional - this is real important since your comments will be visible to everyone (e.g., via cvs2cl), so be gentle if you see something you do not like ;)
• sometimes you will encounter conflicts when checking in your changes. please take up such matters directly with the appropriate developer (or email me) and allow sufficient time for the developer to get back to you. if you see a way to fix it then try sending the patch to that developer.
• since your source files may contain tabs we ask that you run GNU indent on your sources so that the formatting is consistent with the rest of the project. this makes it less irritating for others to read your code and also avoids spurious cvs and diff feedback. see indent guidelines for further details.
• if applying changes to the website content please ensure that you are not commiting transformed material (changes to website material should always be applied to the source HTML and never to anything that has been transformed by the XSLT!) - i know it's easy to forget this one!
• cvswrappers are used for binaries (e.g., images) so you should be ok if you are checking in JPEGs or PNGs (i rather we did not use GIFs though).