From: "Tim Van Holder" To: Subject: Re: Test build of cvs available Date: Tue, 30 Jan 2001 21:54:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id PAA19768 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 > 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. This causes # cvs --text diff foo.c --binary to NOT yield the same result as # cvs diff foo.c though logic would suggest it should. Similary 'cvs --text diff' and 'cvs diff --text' also do not yield the same results. In both cases, the option given to cvs, not the diff subcommand, decides how the diff happens. I could try fiddling with the diff library, but I'm hesitant to do so; there's too much scope for breaking it. 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. If you want to store text as text, use --text in your .cvsrc and diff will handle DOS and Unix text files as equals. > > 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? It does, but as stated above, there's some breakage there. > 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? The server computes the diffs, I believe. But client-server interaction is not tested in this test build yet (see below). For local repositories, client and server are one, obviously. > > [blah] CRCRLF [blah] > I think this is okay, since the default is no --text. OK. > > 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? 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). Also, Richard Dawe has abandoned libsocket due to lack of time, so it seems unlikely full winsock2 will be added anytime soon. If I had more time available, I'd volunteer to maintain it, but as it stands most of my spare time is taken up with patching up autotools (version 2.50 of autoconf is shaping up to be very DJGPP-friendly out-of-the-box, by the way) and occasionally dabbling in other packages (cvs, smalltalk, python).