Mail Archives: cygwin/2006/12/09/01:35:26
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/
- Raw text -