Environment:
Client: Windows NT 4.0, CVS 1.10.7
Server: Linux, CVS 1.10.7
Problem:
If the log message is taken from the text file and it has more than one
line, the "cvs commit -F file" operation generates an extra CR into $Log$
keyword section into the source file creating a line, which ends with
CR-CR-LF combination.
This makes the Visual Studio 6.0 editor to give a warning "Lines ending with
only a carriage return have been detected. These will be modified to include
a line feed" when the source file is opened. This is a real problem,
because the debugger's line count gets mixed up and the line being debugged
is not shown on correct line, which makes debugging almost impossible.
Note that if the multiline log message is given with the notepad (using just
"cvs commit" command), this problem doesn't exist. So it's only the -F
option which has this problem.
Fix:
In src/commit.c there are lines
/* FIXME: Why is this binary? Needs more investigation. */
if ((logfd = CVS_OPEN (logfile, O_RDONLY | OPEN_BINARY)) < 0)
The comment is right - this line shouldn't use binary mode. With binary
mode, the CRLF goes as it is to the CVS server. But when the files are
checked out, the LF is expanded to CRLF thus causing CRCRLF combination.
If the logfile is opened with just O_RDONLY, the multiline log message is
stored correcly (I tested this with CVS 1.10.7):
/* Handle logfile as normal text file without binary mode ... */
if ((logfd = CVS_OPEN (logfile, O_RDONLY)) < 0)
Removing the binary mode shouldn't affect any other areas of the code, since
this part is clearly isolated to the log message file handling. So in my
mind it should be rather safe to fix this without any side effects to other
operating system versions ...
Those lines are the same in CVS 1.10.8 release, so this fix is also valid
for 1.10.8.
Best Regards,
Jari Salminen
