Updated: cvs-1.11.22-1

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

CVS is the 'Concurrent Versioning System', a widely-used package for 
maintianing revision histories of source code.  This port is based on 
the official cvs-1.11.22 release.

CHANGES: (since cvs-1.11.17-1)
 * Updated to latest upstream release
   + see /usr/share/doc/cvs-1.11.22/NEWS for upstream fixes
     There were numerous bug fixes since the previous 1.11.21-1 test
     release, and especially so since our most recent official current
     cvs-1.11.17-1.
 * Removed gdbm use.
   This is HUGE, but should have zero impact on end users.
   See comments below.
 * "disappearing conflicts" problem observed in test release
   cvs-1.11.21-1 has been corrected upstream [1]
 * switch to cygport build framework
 * patch from Jay Abel to fix CRLF problem when
   (1) server running on cygwin
   (2) remote users' login shell on the server machine is tcsh
   http://www.cygwin.com/ml/cygwin/2006-04/msg00226.html

This version has been in test since 2006-12-09, and I've been using it 
exclusively since then, with no reported errors.

***************************************************
*               REMOVING GDBM USE                 *
***************************************************

why?  Because I'm tired of maintaining an out-of-tree, hugely  invasive 
patch that has been rejected upstream (twice, because:). It provides no 
real benefit -- and causes a number of not-really failures in the test 
suite.  Who *cares* if the val-tags cache is stored using a "real" 
database, or is simply a flat-file.  Who *cares* if the modules 
information is read from a database instead of a flat file, for 
microsecond faster parse times?


  This change should have only minimal impact on end users.  gdbm
  is used by cvs to maintain the modules.db and val-tags.db databases
  in the CVSROOT directory, and are only used in :local: or server
  modes.


  Using the cvs client with remotely-hosted repositories is NOT
  affected by this change.


  The impact for :local: and server modes...

    (1) modules.db : cvs will now use the `modules' flat-file
        directly, instead of updating the `modules.db' file
        each time `modules' is checked in.  This may be slightly
        slower, but probably immeasurably so. [2]

    (2) val-tags.db : cvs will now use a `val-tags' flat-file
        instead of the `val-tags.db' gdbm database.  Information
        presently stored in the `val-tags.db' file will be lost --
        but this is not a disaster.  cvs knows how to, and will
        automatically, regenerate all the necessary information
        on demand, by parsing the rcs ,v files directly.  Then
        it will record this tag information in the `val-tags'
        flat-file, where it will be available for future use.
        This may cause some temporary slow-downs for repositories
        with lots of tags and/or files.  You can even switch back
        and forth between cvs-1.11.17-1(+GDBM) and
        cvs-1.11.22-1(NO-gdbm) without trouble, as far as val-tags
        is concerned. [1]

Basically, val-tags is just a cache, so it can be deleted entirely with 
no ill effects -- which, by switching from `val-tags.db' to `val-tags' 
(or vice versa), is effectively what this change does.

Thus, a one-time upgrade from cvs-1.11.17-1 to cvs-1.11.22-1 (e.g. 
with-gdbm to without-gdbm) requires NO action by any user, regardless 
whether using local repository, remote repository, in client mode, or in 
server mode.  Everything happens behind the scenes, automatically.

Switching BACK from cvs-1.11.22-1 to cvs-1.11.17-1 is almost as easy [2]


---------------------------------------
[1] The "disappearing 'C'onflicts" problem that popped up in the 
cvs-1.11.21 test release, described here:
    http://cygwin.com/ml/cygwin/2006-01/msg01385.html
has been corrected upstream in this release, reported here:

* classify.c (Classify_File): If a file had a conflict and the
timestamp hasn't changed, it still has a conflict.  Add comment about
how T_MODIFIED could later turn out to have conflict markers and why
it should not be checked in this function.

http://cvs.savannah.gnu.org/viewcvs/cvs/ccvs/src/classify.c?only_with_tag=cvs1-11-x-branch&r2=1.25.4.3&r1=1.25.4.2
---------------------------------------

---------------------------------------
[2] Switching back-and-forth between cvs-1.11.17-1(+gdbm) and 
cvs-1.11.22-1(NO-gdbm) requires a little care, with regards to the 
modules information.  If you've been using cvs-1.11.22-1(NO-gdbm) and 
have modified the `modules' file, and then switch back to 
cvs-1.11.17-1(+GDBM), those changes will not be reflected in the 
`modules.db' database -- you'll need to checkout/checkin the `modules' 
file ** USING cvs-1.11.17-1(+GDBM) ** to trigger updating the 
`modules.db' database.  No such shenanigans are necessary when switching 
from cvs-1.11.17-1(+GDBM) to cvs-1.11.22-1(NO-gdbm).
---------------------------------------


--
Charles Wilson
cvs volunteer maintainer for cygwin

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

              *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at the above URL.