Updated: cvs-1.11.22-1

Charles Wilson cygwin@cwilson.fastmail.fm
Sat Jan 6 06:08:00 GMT 2007

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

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

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


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


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:


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


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

More information about the Cygwin-announce mailing list