This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[ANNOUNCEMENT] Updated: cvs-1.11.22-1

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

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]