Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tony Hoyle wrote: > Revision numbers are for the internal use of RCS. The only reason they're > useful at all is for pinpointing individual revisions of a file. And that is perfectly acceptable. Under Perl, the module version in the Makefile.PL typically comes from a specific file. The $Revision: $ of that one file can quite successfully be used as the entire package version (I know because I do so). The RCS Revision number has all of the elements necessary for use as a version number: monotonically increasing subversions; branches automatically sort in ascending order with their original branch point. Tags are a comment only and have have no defined syntax, and hence can be easily messed up by the sloppy programmer. > should emphatically *never* be changed by an end user - if you don't know > what you're doing you can create a situation where there are orphan > branches which can't be retrieved using normal means. Just for my amusement, could you describe in detail how this can be done. I always merge branches before changing the $Revision: $ to the next whole number on all files in the module. I have not in practice been required to maintain both a current and previous release, so I may not be aware that I am cutting off earlier revisions by my actions. > > There is no practical use of changing them, unless you're trying to give > them some kind of significance they don't have. Use tags - that's what > they're there for. Except that tags are not available as a keyword macro are they? Without a way to programmatically access that information (say as part of a release script), tags are less than useless. The other obvious disadvantage is that tags are slow to create in large projects, by the very nature of the RCS file format. I have the skeleton of a release script for use with Subversion where the package version is stored as a custom attribute and incremented/tagged by the script. Subversion does not maintain a Revision on each file, but rather globally on the repository itself.