[cvsnt] Again: Forcing revision numbers

[Werner Weiling]

Hi Tony,

There have been different threads about forcing a revision number while 
committing the source.
I'm also a user of this feature and the absence of this option hinders me to 
upgrade to a newer version.
I'm using UNIX very often and I'm of course very interested to have a 
compatible version on Windows and UNIX.
I can't go back to 2.0.58 or 2.0.51 which is delivered by WinCVS because it 
does not descend into directories with a different CVSROOT
q.v. Thread "cvs update does not descend into subdirectories with different 
CVSROOT".

Therefore I would like to collect arguments for this option to request you to 
add it again.
First of all: Why I would like to use it?

Bo wrote this comment in an email:
 > Why do you want to do this at all?
 > The revision numbers are items used internally by CVS to keep track of
 > changes to the individual files themselves. There is no other meaning
 > attached to revision numbers and you should not interfere with the CVS
 > revisions.
 >
 > I suspect that somehow you are confusing product versions with the CVS
 > revision numbers, but they have nothing at all in common and could not
 > be used interchangeably.
 > Product versions are managed in CVS by using "tags", which can be applied
 > across many different files at different revisions to tie together all
 > files valid for a certain product version.
 >
 > Tags are what you should use!
I absolutely agree that a revision number is used mainly internally by CVS.
For a developer are tags the only way to determine which revision belongs to 
which product version.
However there is a use case where it makes sense (at least for me) to support 
forcing a revision.

We can determine with the revision whether a source file is upward compatible 
with a newer product.
Let's assume we have this configuration:
Product Version 1
foo.c (Revision 10.1)
bar.c (Revision 10.1)

Product Version 2
foo.c (Revision 10.1)
bar.c (Revision 11.1)
new.c (Revision 11.1)

Product Version 3
foo.c (Revision 10.1)
bar.c (Revision 11.1)
new.c (Revision 12.1)

A developer can recognize very easily that the file 'foo.c' is compatible with 
  Product Version 1+2+3 and he can apply a bug fix for all product versions.
In the case of file 'bar.c' he knows he has to do the bug fix twice and in the 
case of file new.c it is just Version 3.
Yes, you can do this also by checking the tags for the product version but you 
can use this mechanism after on also for a validation check of the release build!
If a Revision number higher than 10 would appear in the release build of 
Product Version 1 then we know that a developer made a mistake. We're checking 
this by issueing an 'ident' onto the binary libraries.

For supporting this validation we need this option -r in the commit command.

Other remarks:
- revision number with zeros
Bo:
 > Also note that revision numbers ending with a zero, like the one you
 > suggested, have special meanings to CVS and should not be used at all!
Yes, but this can handled by the application that only revision numbers 
without a '0' are accepted or that only branch numbers are accepted like '24' 
or '24.0.1'

- Compatibility to UNIX CVS
This is one of my major requests because I need to use both worlds.
Probably you have to give up this requirement at some time due to internal 
constraints but I would like to ask you at least for a '2.0.x' version which 
has a fix for recursive behaviour with different CVSROOTs and the 'commit -r' 
command.
Unfortuneately this would be the last version I can use :-(.

Thank you for your great work,
Werner