Kieran, I haven't used that package, but I have used RCS and CVS in various combinations.
One tip is to think in advance very carefully about what you need to version. That may seem obvious, but remember that for most applications this does not just mean source code: it means dictionary entries, setup instructions, control items and many other bits and pieces. My approach is to always have a 'source' to go back to: this includes having scripts to generate files and dictionaries (similar to SQL CREATE TABLE commands, for example), installation scripts and the like that can be treated as source. Otherwise at the very best, the version control is going to be patchy. Another tip is to version stamp your source code in a way that can be saved into the object code, so you can always find out what version of a program is being run or cataloged (where that might differ from the source!). The best way I have found is to create and automatically maintain a variable that holds a version string, so it gets compiled into the object string table. All my installation and cataloging routines pick these up for safe installs, and I use front end commands to map the numbering between the source version string and the RCS entries to give a complete picture. Finally, are there other dependencies you need to consider - are you adding web pages, Windows or .Net front ends or other items that need to be controlled along with the source?. If so, you will need to ensure that you can package the two together for a full picture. Sorry if a lot of this is obvious, but having the change version management mid-stream is a real pain (bitter experience bites!). Brian -- Internal Virus Database is out-of-date. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.0 - Release Date: 31/03/2005 ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
