X-Spam-Check-By: sourceware.org Message-ID: <457A5867.3000409@cwilson.fastmail.fm> Date: Sat, 09 Dec 2006 01:32:07 -0500 From: Charles Wilson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: [Avail for test] cvs-1.11.22-1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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/