Mail Archives: cygwin/2007/01/06/01:09:32
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 DOT com AT cygwin DOT 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/
- Raw text -