[cvsnt] Re: Again: Forcing revision numbers

[Tony Hoyle]

Werner Weiling wrote:
> foo.c (Revision 10.1)
> bar.c (Revision 10.1)

That is *not* a valid argument for not using tags.

> 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.

Source files interact.  It's just not that simple.

If foo.c is compatible with those product versions it should be tagged 
with those product version numbers.  There is no other sane way of doing 
it.  In fact from your example I can't see how the numbers are helping 
at all - you must be using tags and branches already to mark the 
individual releases.

If you're retroactively changing releases just checkout the revision 1 
branch, fix the bug, checkout the revision 2 branch, etc.

You can use bugid merges to merge individual bugs into branches if 
necessary.

> - Compatibility to UNIX CVS

It is compatible.  Compatibile does not mean identical.

Unix CVS defines revision numbers within certain constraints, and CVSNT 
sticks to those constraints (in fact slightly more rigidly than the 
cvshome cvs clients themselves do - they let you force completely 
invalid revision numbers into the file).

The actual meaning of the numbers themselves is *internal*.  Originally 
RCS generated them.  cvsnt is slowly moving to a database where they'll 
be generated by that - the format of the numbers won't change so clients 
can still make sense of them, but the meaning and values will change 
enormously..  there is no scope for letting users make them up.  There 
never should have been, and getting rid of that misfeature was a long 
time in coming (I've been saying I'd do it for 6 months or more).

TBH I'd rather the revision numbers weren't visible to clients at all - 
there were plans to do that but I didn't have time to do it properly.

Tony