[Avail for test] cvs-1.11.22-1

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

A new test version of cvs should hit the mirrors soon.  I believe that 
the "disappearing 'C'onflicts" problem described here:
    http://cygwin.com/ml/cygwin/2006-01/msg01385.html
has been corrected upstream in this release.  Also, numerous bug fixes 
since 1.11.21-1 (and especially so compared to our curr: cvs-1.11.17-1).

However, there is one big...make that HUGE...change in this release:

- Removed 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. [1]

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

[1] 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).

Other changes:
- 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



Please test this as best you can on non-production data (or at least, 
back up your repositories).  I hope to promote this version to curr: 
within a week or two, freeing up test: for a 1.12.x version.

--
Chuck


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