Date:	Wed, 31 Jan 2001 10:12:03 +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:	<NEBBIOJNGMKPNOBKHCGHAEFJCBAA.tim.van.holder@pandora.be>
Message-ID:	<Pine.SUN.3.91.1010131101148.29266M-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 Tue, 30 Jan 2001, Tim Van Holder wrote:

> > 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.
> The diff library itself would be able to handle this fine (din't even
> know it supported --binary); however, CVS is responsible for creating a
> temporary file to diff the workfile against. And deciding what mode to
> use for that temp file is a bit hairy.

Why not make it use the same mode consistently?  Thus, a command such
as "cvs diff foo.c --binary" will use binary I/O both for the
temporary files and in computing the diffs.

> I could try fiddling with the diff library, but I'm hesitant
> to do so; there's too much scope for breaking it.

I don't think you need to fiddle with the diff code: it already does
The Right Thing (has been doing that for a long time).  What you need
is make the diff library's mode consistent with the mode used by CVS
elsewhere.  Then it will DTRT in general, I think.

> In any case, I believe the current way does the right thing. Seeing as
> how cvs is supposed to be able to handle (and preserve) different styles
> of line endings when not using --text, it seems logical for the diff
> subcommand to see them as different.

I'm not sure.  "cvs diff" is mostly used locally, to see how is the
workfile different from the repository.  Therefore, it won't do any
harm to make it default to text I/O: it will work for Unix-style
files, and will allow users who keep their local files with DOS-style
EOLs to not bother with --text unless they want to.

> > Sorry for asking the obvious: does this support remote repositories
> > via the net?
> Nope - I disabled client/server functionality for this build. I could
> easily provide a build that has them enabled (using libsocket; not
> entirely sure which version I have installed - either 0.7.4 or 0.8.0).
> But since libsocket does not have proper winsock2 support, it would only
> be of any use on a system with winsock1 (the 32K transfer limit makes
> CVS pretty useless on winsock2).

Too bad.  WinCVS is just too much of a PITA, but I guess I'll have to
continue living with it...

- Raw text -