Mail Archives: djgpp-workers/2001/01/30/15:52:23
> 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).
- Raw text -