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: <3EAAF450.4040505@ece.gatech.edu>
Date: Sat, 26 Apr 2003 17:04:16 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [avail for test] cvs-1.11.5-1
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>
In-Reply-To: <006401c30c32$e5be54e0$78d96f83@pomello>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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$").

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

(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!)

Anyway, there's lots of places to screw up, so testing is a must -- and 
I haven't even attempted to suss out the code to see if it is behaving 
-- on cygwin -- as advertised in the table above.

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