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 Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3C7E666B.9080403@ece.gatech.edu> Date: Thu, 28 Feb 2002 12:18:35 -0500 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Schaible, =?ISO-8859-1?Q?J=F6rg?=" CC: cygwin-list Subject: Re: CVS Problems: Updated: gdbm-1.8.0-4 References: <1264BCF4F426D611B0B00050DA782A50110E30 AT mail DOT gft DOT com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Schaible, Jörg wrote: > Hi Charles, > > >>Note that merely updating cyggdbm to this new version will NOT >>magically enable CVS to host repositories on text mounts; nor will >>it magically fix CVS's existing problems with CR/LF. This gdbm >>update may fix the gdbm database files within the CVSROOT repository, >>but CVS itself is still not text/binary clean. Workin' on it... >> > > can you give me a hint, where CVS with a repository on a binary mount Correct, with repository on *binary* mounts cvs will work fine -- with one caveat. > will > have CR/LF problems? I am using it since more than a year and I had never > detected any problems independently wether I check out to bin or text > mounted directories (on NTFS). Correct, checkouts to bin or text -- from a binmount repository -- work fine -- with one caveat. > I did not have problems also working with > repositories of the the net. True. > for Your comment seems to indicate some > malfunction you're able to reproduce. Yes. > I would not like to detect anything > major problems managing my sources if I can avoid it. Understandable. --------------------- Here's the deal: (a) currently, you can't host repositories on text mounts. (b) the caveat for binmount-hosted repositories: the CVS spec says that all 'normal' files in the repository should be stored *without* ^M (that is, in what we in the cygwin world call "bin" mode or sometimes "unix" mode -- but to avoid confusion, when refering to an actual FILE, I will call it 'LF' mode (I will call "dos" or "text" files by this name: "LF/CR" mode). When referring to a mount point and the cygwin default behavior with respect to files written under that mount point, I will call THAT "bin" mode or "text" mode, respectively. Well, the current cygwin port of CVS seems to store all 'normal' files in the repository in LF/CR mode. On checkout (from a local repository) all 'normal' files are created in LF/CR mode. This is *regardless* of whether the local working directory is on a binmount or textmount. (Of course, the repository is on a binmount; see (a) above). If a given file is checked in or tagged with cvs's '-kb' flag, then it is stored without LF->LF/CR translation (and without LF/CR->LF translation) -- but there are SERIOUS drawbacks to marking ordinary text files as '-kb': like, you can't do 'cvs diff'. Multiple revisions are stored _in toto_ in the repository. No keyword translation is done ("$Id$", etc). Bad. Strangely, none of these problems seem to occur when using a remote (unix-based) :pserver: repository. Therefore, I believe the "write data file into repository file 'foo/bar,v'" code is explicitly, and erroneously, setting the fopen mode to "wt"/"rt". Writes (and reads) to/from files in the local repository are obviously done "correctly" -- without any explicit 't' or 'b' modifiers (because we know that local dirs can be on textmounts or binmounts, and stuff 'just works'). What *should* happen is that repository writes need to manually translate "LF/CR" into "LF", and write with "wb". (!!--!!) -------------- Now, (a) is probably pretty easy to fix. The sentence marked (!!--!!) should take care of that. However, (b) is a bigger problem -- because of the existing infrastructure that many people already have. I don't want to break the 2000 personal/local repositories out there that already have a bunch of "LF/CR"-ized ,v files. So, I'm somewhat at a loss right now as to the "right thing to do". Perhaps if all repository reads were also done by reading with "rb" and then manually translating "LF/CR" into "LF" (this insures that previously created repositories with the erroneous LF/CR endings are handled gracefully) But then diffs against local working dirs on binmounts -- where the checked-out copies already have "LF/CR"-terminations will break... "Please run dos2unix on all text files in your working dir, IF your working dir is on a binmount"...bleah "For every working dir that is a checkout from a locally-hosted repository, please commit all changes back to that repository before upgrading CVS. Then, do a 'cvs release' on all working dirs. Remove them. Upgrade CVS. Then check them back out using the new cvs.exe." Double bleah.... Somebody has mentioned that because of the WinCVS port, cvs already has some code in it to manually do LF/CR->LF (and reverse) conversions...I haven't looked yet. Perhaps all that's missing is for that code to get "turned on" in the cygwin port. However, that still leaves the sociological issues w.r.t. the already extant local repositories out there... Anyway, I have over 300 messages relating to cvs sitting in a folder, and I've got to got thru all of them, fix the problems reported (most seem to be either this LF/CR thing, "I want to host a repo on a textmount" or "I want to run cygwin-cvs in :pserver: daemon mode"...) I think what I may do is merely port my existing cygwin-cvs stuff from cvs-1.11.0 to cvs-1.11.1p1, with NO further changes. Release that as a test release, and then solicit help fixing (a) and (b)... --Chuck -- 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/