public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
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/

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