(no subject)

[crh]

>Submitter-Id:   net
>Originator:     Christopher R. Hertel
>Organization:   Unorganized
net
>Confidential:  no
>Synopsis:      Revisions with leading zero display varied behavior.
>Severity:      non-critical
>Priority:      low
>Category:      cvs
>Class:         change-request
>Release:       1.11.1p1
>Environment:   i686, Linux 2.4.18, client/server, CVS_RSH=`which ssh`
System: Linux RoadKill 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686 unknown
Architecture: i686

>Description:
        CVS permits files to be added and checked in with revision numbers 
        beginning with zero, eg. "0.1".  When CVS is used on a local 
        machine, there are no problems handling files with zero as the 
        major revision number.  When the repository is accessed from a 
        remote machine, however, the zero major number is seen as a flag 
        indicating that the file is not in sync with the repository.

        See also:
        http://mail.gnu.org/pipermail/bug-cvs/2000-October/005000.html

        I did try digging around on the 'net to find out if this behavior
        was by-design, a known problem, etc.  If I missed the answer, my 
        apologies.  I *did* find the above e'mail (from two years ago...),
        but the follow-ups were not conclusive.

>How-To-Repeat:
        

        export CVS_RSH=`which ssh`
        cvs -d user@remotehost:/data/cvs add new.file
        cvs -d user@remotehost:/data/cvs commit -r0.1 new.file

        The commits that follow will see the 0.x rev files as having
        changed--even though they have not changed--and will try to check
        in the update.  No check-in will actually occur, of course, 
        because cvs on the server side will recognize that the files are
        the same.  Thus, there is no actuall problem caused.  It's just an
        annoyance.

        Note that the CVS/Entries file will have a "dummy timestamp" for 
        all 0.x revision files.

>Fix:
        
        It seems that in some parts of the CVS source there is an
        assumption that a zero major rev indicates an out-of-sync file.  
        Other parts of the code do not seem to make that assumption.  I 
        found it suggested, but not stated, that CVS wants all projects to 
        start at 1.  (I did not read *all* of the available CVS
        documentation, so I may have missed it.  I did check the FAQ at 
        Cederqvist...)

        Personally, I like to start at zero when I am working with very 
        new code.  As a result, I get bit by this a lot.

        In any case, the "bug" (if there is one here) is that the behavior 
        is inconsistent, differing between local and client/server cvs
        access.