On Tue, 29 Jan 2002, Larry Jones wrote: > Bob Kline writes: > > > > When the history file has lines with mixed line-endings (some \r\n, some > > \n, presumably resulting from the use of different versions of cvs), the > > history command is unable to match O and F records reliably. This > > happens because the history file is opened in binary mode, and the > > read_hrecs() function is testing explicitly for '\n' as the record > > terminator. This results in the software thinking that the '\r' > > preceding the '\n' is part of the data for the last field in the record > > (hr->mod). > > If the history file is opened in binary mode, using different > verisons of CVS wouldn't make any difference -- the line terminator > would always be \n. I think
Looking at the source for the history_write() function I can see that this is true, as long as cvs is the only software which writes to the file. I can only assume, then, that someone opened the file in an editor which "fixed" the line endings when the file was written back to disk, because when I went snooping to find out why the history command sometimes thought that a module was checked out when it wasn't, I discovered that some of the lines had CR+LF endings. We could take the approach that this shouldn't ever happen. Or we could apply the patch anyway to make the software a little more robust. Absent the claim that '\r' is a legitimate data character for the last argument (module or filename) field, the patch is benign, as far as I can tell. -- Bob Kline mailto:[EMAIL PROTECTED] http://www.rksystems.com _______________________________________________ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
