Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
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: <00a301c30c3a$ec1c4ce0$78d96f83@pomello>
From: "Max Bowsher" <maxb AT ukf DOT net>
To: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>, <cygwin AT cygwin DOT com>
References: <3EA8B56A DOT 9060307 AT ece DOT gatech DOT edu> <009301c30b32$3bec5440$78d96f83 AT pomello> <3EAAE4DC DOT 6090200 AT ece DOT gatech DOT edu> <006401c30c32$e5be54e0$78d96f83 AT pomello> <3EAAF450 DOT 4040505 AT ece DOT gatech DOT edu>
Subject: Re: [avail for test] cvs-1.11.5-1
Date: Sat, 26 Apr 2003 22:29:30 +0100
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.1165

Charles Wilson wrote:
> Max Bowsher wrote:
>> Only tested binary/binary, I'm afraid.
>>
>> I've never liked the idea of using 2 characters where 1 will do. I even
use
>> Unix line endings in non-Cygwin text files.
>>
>> One possible idea: Link it with binmode.o until someone contributes a
patch
>> to apply correct binary/text/default opens in the source.
>
> Well, the problem is that's not how cvs is supposed to work.  As I
> understand it, files in the repository should ALWAYS be stored with unix
> line-endings (the term "binary" is slightly misleading in this context,
> as -kb "store in binary form" means to cvs "don't replace $foo$ tokens
> like $Id$ and $Revision$").

Um, no -ko means that. -kb DOES mean store in binary form.

> And files in the local working directory should follow "the system
> convention" -- which I take to mean "use the mount mode" -- but only
> when the files contain text.  Fortunately, cvs assumes that all files
> contain text unless explicitly informed that they are binary data, via
> the -kb flag.  Thus,
>
>              repository          working dir
>               access               access
> ---------------------------------------------
> read:        unix         use mount mode unless -kb
> write:       unix         use mount mode unless -kb

Well, yeah, my suggestion was to use binmode.o *until* someone actually does
a patch to do the above.

> (fortunately, the "should I interpret/replace $foo$" stuff is handled in
> a separate codepath from the "should I use O_BINARY to fopen this file")
>
> Now IF existing repositories do NOT follow this convention (e.g.
> somebody has \r\n in text files in their repository) then upgrading to a
> cvs that DOES follow the convention will lead to all manner of FAQs
> ("cvs diff says every line has changed! cvs sucks!)

Lets hope that no one is trying to use -kb in such a situation.
But yes, status quo is probably better, since there don't seem to be any
complaints about the current behaviour.

Max.


--
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/