From: Charles Wilson <cwilson@ece.gatech.edu>
To: cygwin@cygwin.com
Subject: Re: [avail for test] cvs-1.11.5-1
Date: Sat, 26 Apr 2003 23:18:00 -0000 [thread overview]
Message-ID: <3EAAF450.4040505@ece.gatech.edu> (raw)
In-Reply-To: <006401c30c32$e5be54e0$78d96f83@pomello>
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/
next prev parent reply other threads:[~2003-04-26 21:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-25 10:42 Charles Wilson
2003-04-25 15:21 ` Max Bowsher
2003-04-26 2:02 ` Charles Wilson
2003-04-26 2:25 ` Max Bowsher
2003-04-26 9:25 ` Charles Wilson
2003-04-26 21:46 ` Charles Wilson
2003-04-26 22:01 ` Max Bowsher
2003-04-26 23:18 ` Charles Wilson [this message]
2003-04-27 0:01 ` Max Bowsher
2003-04-27 0:53 ` Igor Pechtchanski
2003-05-21 9:03 ` Charles Wilson
2003-05-21 17:40 ` Rick Rankin
2003-05-22 4:12 ` Charles Wilson
2003-04-25 13:40 Roland Schwingel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EAAF450.4040505@ece.gatech.edu \
--to=cwilson@ece.gatech.edu \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).