delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/12/15/11:34:45

From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Subject: RE: MS-DOS path support in CVS
Date: Fri, 15 Dec 2000 17:37:52 +0100
Message-ID: <NBBBIOJKJBNCHJBEKHLOOEFHCCAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <200012141821.NAA24932@envy.delorie.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id LAA00359
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

> > I think CVS should use binary I/O by default and have an optional
> > switch to use text-mode I/O.  This will DTRT in most of the cases:
> 
> CVS files have a flag within them that says if the file should be
> binary or text.  If the flag says binary, the files must be checked in
> and out in binary.
That's not exactly true; the flag, like in RCS, only means no
expansion of keywords should take place. Since this is usually used
for binary file formats, binary mode should indeed be used.
There is no imperative why files without -kb HAVE to read/written
in text mode. Most non-Unix CVSes (or it it CVSen, like Emacs?)
will use text mode, since it is convenient for the user (i.e. their
favourite editor will grok the file, even if that editor is Notepad).

> [snip]
So basically 3 modes could be made available:
 - full binary: everything is read/written binary. This has maximum
   compatibility with Linux, so sandboxes can be shared (provided
   the CVSROOT can also be grokked by Linux CVS).
 - Full text mode: Files that haven't got -kb are read and written
   in text mode. Good for pure DOS users, bad for people who use
   remote repositories, as their diffs won't work for everyone (e.g.
   cvs has files for NT as well, which have CRLF. A diff will either
   be CRLF itself, resulting in failure for all files except the NT
   ones, or it will be LF, in which case patching the NT files will
   fail).
 - Semi-intelligent mode. Text files are written as binary, read as
   text. This fixes the diff/patch issue (povided the user doesn't
   use a CRLFifying editor), but is still broken for users needing
   to check files in to such a repository. Requiring -kb for DOS style
   text files is not really a viable solution. Firstly, it may not be
   up to you. Not all users have cvsadmin privileges. Secondly,
   there's no good reason why keyword substitution should be disabled
   for DOS style text files.

Of these, I would prefer the first to be the default, with the third
a viable alternative. I consider the second option to be too broken,
but am willing to include it if necessary.

> A "cvs diff" needs to deal with CRLF/NL conversions automatically for
> text files.
This is a difficult issue. You'd want the result of the diff to work
on all platforms. As such it should preserve EOL conventions, and be
written in binary mode. Only mode 1 handles this cleanly, as all files
use binary I/O anyway.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019