Thanks Mike,
I see what you're saying. If I do a "cvs status dx/fonts/area.dx", I
see that the Sticky Options are set to -ko. And from what I read, -ko
will convert the line feeds from platform to platform (this is really
bad for binaries which may have \n in the binary portion and get
converted to \n\r when checked out on NT or vice-versa). So yes, it
seems the correct thing to do is change the options to -kb on all
binary dx files.
So Greg, I was looking through the CVS documentation and they have an
example how to fix this and it follows below:
EXAMPLE:
-----------------
# Add the file so its like our font files area.dx, etc.
$ echo '$Id$' > kotest
$ cvs add -m"A test file" kotest
$ cvs ci -m"First checkin; contains a keyword" kotest
# Now since the file kotest is already in CVS, it can be changed by
$ cvs admin -kb kotest
$ cvs update -A kotest
# Copy in a good copy of the file from outside CVS
$ cvs commit -m "make it binary" kotest
------------------
Since I believe we don't have admin access to the cvs, could you perform this?
Pete, what about the dxsamples tree? Shouldn't this be done as well
for some of the binary files?
David
For my binary data under CVS I use the 'kb' flag, as in:
cvs add -kb ...
cvs import -I ! -W "* -k 'b'" ...
The fonts are using 'ko' (from the sticky options). I would think 'kb' is
what we want for any binary data.
Mike
--
.............................................................................
David L. Thompson The University of Montana
mailto:[EMAIL PROTECTED] Computer Science Department
http://www.cs.umt.edu/u/dthompsn Missoula, MT 59812
Work Phone : (406)257-8530
