This is the mail archive of the cygwin-announce 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]

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



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