[ANNOUNCEMENT] Updated: cvs-1.11.22-1

Charles Wilson cygwin@cwilson.fastmail.fm
Sat Jan 6 06:09: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
      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.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list