Date: Wed, 31 Jan 2001 10:12:03 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Tim Van Holder cc: djgpp-workers AT delorie DOT com Subject: Re: Test build of cvs available In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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...