This is the mail archive of the
mailing list for the Cygwin project.
[ANNOUNCEMENT] Updated: cvs-1.11.22-1
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin at cygwin dot com
- Date: Sat, 06 Jan 2007 01:08:14 -0500
- Subject: [ANNOUNCEMENT] Updated: cvs-1.11.22-1
- Reply-to: cygwin at cygwin dot com
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 
* 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) 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. 
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 
 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.
 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).
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:
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: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html