Mail Archives: cygwin/2003/04/26/17:06:18
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/
- Raw text -