Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm 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 Message-ID: <009301c2b4b0$c88d1c50$ba97883e@pomello> From: "Max Bowsher" To: "Charles Wilson" , References: <00df01c2b43e$774f6860$fc78883e AT pomello> <3E178348 DOT 1090805 AT ece DOT gatech DOT edu> Subject: Re: [Mostly to Charles Wilson] Upgrading Cygwin's CVS Date: Sun, 5 Jan 2003 11:47:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Charles Wilson wrote: > Max Bowsher wrote: >> In http://sources.redhat.com/ml/cygwin/2002-06/msg00754.html, Charles >> withdrew a test cvs-1.11.2 package, saying that some bugs had been >> found. I've recently compiled cvs 1.11.4 for myself, because I >> wanted the new rlog command. I was wondering what these bugs were, >> in case I might encounter them in my locally compiled version. > > Gosh, I don't remember the exact details, and can't seem to find it in > my TODO or NOTES files for cvs. Trolling thru my mail archives... > > It seems that the problems were the standard text/binary issues, on > reading .cvsignore, .cvsrc, .cvspass -- coupled with issues reading > the ENTRIES, REPOSITORY, and ROOT files in the CVS dirs. Something > like they tended to gain more and more ^M's at the end of each > line...which led to problems. These issues are NOT problems on > cvs-1.11.0, IIRC, and represent a regression for cvs-1.11.2. Plus, > there are the continuing problems of hosting a cvs repository on a > text mount. I think. > > Really, these issues are not too difficult to track down and fix, but > I decided to abandon the official cvs codebase at that point(see > below), and haven't worked up the gumption to re-do all of the > original cygwin-porting stuff with regards to the cvsnt codebase, so > we're still languishing at cvs-1.11.0. Data point: I'm running cvs-1.11.4 compiled OOTB. Admittedly thats in flatfile-dbm emulation mode (MY_NBDM), but I need that to work with repositories using that mode. Am I right in saying that your patches consist of cosmetically updating cygwin32 -> cygwin, and enabling the use of gdbm? > Anyway, I'm stunned to hear that the bozos running the cvs project > actually got around to releasing TWO new versions (1.11.3 and 1.11.4). Ah, you may be unsurprised to hear that 1.11.4 was simply fixing windows build regressions in 1.11.3, and was released the next day. On the other hand, you might be stunned by the release announcement, which says: thanks for the patches from X, Y and Z! > [No, I don't have a lot of respect for people who contemptuously > ignore patches without even the courtesy of a response...after a > couple of reminders over several weeks...] Yes, thats pathetic. > Because of all that, I'd pretty much decided that the next time I > update the 'cvs' package, I'm going to use the cvsnt codebase (which, > despite its name, does compile under unix: on "unixoid" platforms, it > is essentially regular cvs + bugfixes. Bugfixes the "real" cvs > maintainers seem to believe are beneath their dignity. No, I'm not > bitter.) But that's a lot of testing I'm not really ready for right > now. Extra bugfixes are always good. I just hope that cvsnt syncs with original cvs soon (still being based on 1.11.1). > So, in answer to your question, I'd make sure that the behavior and > contents of the .cvs* files, and the CVS/* files, make "sense" when > your home directory and working directories are on both binary and > text mounts -- and continue to make sense after a few rounds of > commits and checkouts. Fair enough. Thanks. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/