RE: forcing revision numbers

[Cameron, Steve]

> From: Stephen Rasku [mailto:stephen@tgivan.com]
[...]
> In other areas of CVS we enforce certain rules "that are not a good 
> idea".  
[...]
> I suggest we do the same for this revision setting "feature".  If 
> people want to use it, they can #define the appropriate macro.  
> However, it would be off by default.
> 

Just to play devil's advocate:

"commit -r" allows committing to a branch tag,
which seems somewhat reasonable, as well as to a fixed 
revision number (seems somewhat insane) so it's not 
as simple as ifdeffing out "commit -r" support.

One other problem with ifdeffing is the feature then fails to 
be widely tested and consequently breaks over time.  
Like the "notoriously buggy" preserve permissions code, 
(though I don't know if that ever worked.)

Or new features will fail to support the #ifdef'ed feature.
For example, my ".trunk" patch allows "cvs commit -r .trunk".
if "-r" were #ifdef'ed out, maybe I wouldn't have noticed
I needed that, or, at least testing would have been made tougher,
as I would have to compile 2 ways.  I sure didn't spend any time
worrying about any interaction with the "preserve permissions" code
though.  

Along the same lines, recently there was a patch to make
"cvs tag -F" by default refuse to move branch tags.  Arguably, 
moving a branch tag is _never_ the right thing to do,
so why should it be allowed at all?  Because it was allowed
before and maybe somebody else can think of a reason why
it's the right thing to do, so that's how the patch went 
in, still allowing the (mis)behavior, just making it 
a little harder to fall into that hole.  (No harder
than using "-r" though.)

(Hmm, wrote more words than I meant to, considering I never
actually use "commit -r")

-- steve