RE: forcing revision numbers

[Stephen Rasku]

>From: "Cameron, Steve" <Steve.Cameron@COMPAQ.com>
>To: bug-cvs@gnu.org
>Subject: RE: forcing revision numbers
>List-Archive: <http://mail.gnu.org/pipermail/bug-cvs/>
>Date: Tue, 10 Jul 2001 11:27:54 -0500
>
>
>> 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.
>> 
>
>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.)

I don't see this as a problem.  If someone wants to use this 
unrecommended feature then they can fix the code so that it works.  
The code in question doesn't get tested that much anyways since you 
aren't supposed to use it. 

>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.
  
 Patches should be made against the recommended configuration.  If 
someone wants the patch to work with the unrecommended configuration, 
then its up to them to get it to work.
 
>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.)

Strangely enough, I have moved branch tags before.  If a certain file 
has been modified on the trunk but not on my branch I would move the 
branch tag to the head of the trunk and avoid having to check in 
changes to the branch as well as the trunk.  I haven't done this in a 
while though because it is a bit labour intensive and you have to be 
vewwy vewwy careful.

Back to the "forcing revision numbers" issue:  

Ultimately, it doesn't matter one way or another to me.  I already 
know not to do this.  

However, if I was a new user to CVS, I would find it very frustrating 
if I did this and it broke something.  If they asked for help on 
info-cvs this is the likely conversation:

Q: I forced revision numbers up to 2.0 and now I can't checkin
A: You shouldn't force version numbers.  Use tags instead.
Q: If I am not supposed to use it, why does it exist?
A: That's the Unix way...

Either the feature should be made stable enough for people to use it 
or it should be removed.  Isn't this logical?

-- 
Stephen Rasku                   E-mail: stephen@tgivan.com
Senior Software Engineer        Web:    http://www.pop-star.net/
TGI Technologies