RE: Updating revision number on a branch.

[Jim.Hyslop]

Heather wrote:
> Okay, thanks for your quick repy!  We were aware that this was
> basically a 'cosmetic' fix.  We print the CVS log entries in 
> the header
> of the files to easily see our changes, so we're seeing the 1.7.2.XXX,
> etc and wanted to 'clean it up' a bit so it was easier to read.
If you mean you use the $Log$ keyword, then that's another practise I'd
discourage:
- It *really* clutters up the file
- it frequently causes conflicts when merging
- it's redundant information, that you can easily get using the 'cvs log'
command
- it is far too tempting for a developer to "fix" the log entry in the file
itself, thus making the entries contained in the file different from the
official log entry. Things can really go downhill from there.

> I take it we can still go ahead and do this on the main 
> trunk?  We have
> some files getting up to version 1.102 etc so it'd be nice to be able
> to start this latest version with the new revision number if 
> that makes
> sense.
1.102 - is that all?!? :=)

E:\cvs\pilot\windows\BrtWin>grep \$Id BrtView_t.cpp
// $Id: BrtView_t.cpp,v 1.364 2004/12/06 19:39:58 jhyslop Exp $

E:\cvs\pilot\ClientFramework\database\Distribution>cvs st PilotStatic.mdb
===================================================================
File: PilotStatic.mdb   Status: Up-to-date

   Working revision:    1.478
   Repository revision: 1.478


Seriously, though, as you say this is a cosmetic change, and as Alan's
pointed out, keeping these numbers up-to-date could cause more work than
it's worth. It's generally not worth the effort.

In the end, though, it's your repository and your project, so feel free to
do what you want.

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. ( http://www.leitch.com )
Columnist, C/C++ Users Journal ( http://www.cuj.com/experts )