Date:	Tue, 30 Jan 2001 11:57:45 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Test build of cvs available
In-Reply-To:	<NEBBIOJNGMKPNOBKHCGHOEEOCBAA.tim.van.holder@pandora.be>
Message-ID:	<Pine.SUN.3.91.1010130115709.16223O-100000@is>
MIME-Version:	1.0
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

On Mon, 29 Jan 2001, Tim Van Holder wrote:

> I've patched CVS to (hopefully) handle CRLF issues better (as
> discussed a while back).

Thanks!

> 1) Diffs. By default, binary i/o is used, so if the sandbox file has
> CRLF, cvs diff will consider ALL lines to be different.

Hmm... perhaps "cvs diff" should use text I/O by default, as it does
from the command line.  Users could use "cvs diff --binary" to reverse
that, as they do from the command line.

>    As a workaround, 'cvs --text diff' will show the actually different
>    lines.

Why do you need a special option?  "cvs diff" already accepts --binary
and --text, doesn't it?

Perhaps I don't understand how does "cvs diff" work, internally.  Are
the diffs computed on the server or on the client?  If the the latter,
does it write the version from the repository to a temporary file and
then diffs it against the sandbox, or does it do it entirely in
memory?

> 2) If you check in a tree using the default mode, CRLFs are
> preserved. This means that if you checjout such a tree in --text
> mode, you get CRCRLF line endings on those files

I think this is okay, since the default is no --text.

> Anyway, you can get the file at http://users.pandora.be/vanholder/testcvs.exe

Sorry for asking the obvious: does this support remote repositories
via the net?

- Raw text -