cvs doesn't work, people do. Assumptions become invalid. The concept 'DOS text files' is a stale leftover from CP/M. Who cares if there's a ^Z to mark the end of a 'text' file? I don't see any hands up. There's no end to the amount of grief those pesky ^Z have caused. Anyway, most work on a Win2K box can be done with either CR/LF or LF. MacOS-style can be a problem though. I have not tried VMS-style yet ;) and probably never will. But you have got a point there.
In my philosophy, I need to save a bit more information about each text file. E.g., the record format and the encoding; just a minimal amount of information about inherent properties of each text file (what makes it a text file). Unless I use and expect UTF-8 by default, there's no way to be sure that I don't munge text files with characters outside the ASCII repertoire. This isn't that much different from the question about what record format you want for each file in you sandbox. Basically, the distinction 'text' vs. 'binary' is too simplistic. You cannot infer what encoding I want, why should you be able to infer what record format I want? I'm just lucky that XML files by default are UTF-8 or else declare their encoding explicitly; this takes care of the encoding problem for me. Of course I like the abstraction of 'variable-length-record files' that cvs provides. I just don't like cvs to second-guess me when I know better. At the very least, keyword expansion and record format translation could have been different options. Kind regards, Peter Ring -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Larry Jones Sent: 9. oktober 2001 17:05 To: Peter Ring Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Checkout text files with the Unix LF (Oxa) - from command line Peter Ring writes: > > The host may or may not be part of the use, and the > end-of-record format may or may not be important for the > host. For example, I might need to manage configuration > files for a multi-OS product. While I have both CR (MacOS), > LF (*nix), and CR/LF (CPM/MS-DOS) end-of-record files, > my editor (emacs) deals with this transparently, and the > OS that holds the sandbox have no use for 2/3 of the files. > Why should I need to check out files on a Mac just to do > something that might as well be done on Windows or Linux? You're missing the whole point on the way CVS works. You don't have files with specific line endings, you just have text files. When you check them out on DOS, they have DOS line endings and you can edit them or whatever with your DOS tools. When you check them out on Unix, they have Unix line endings and you can edit them or whatever with your Unix tools. When you check them out on Mac, they have Mac line endings and you can edit them or whatever with your Mac tools. When you go to deploy them, you check them out on the platform you're going to deploy them on and they get the correct line ending for that platform. In your philosophy, what would you do with VMS files that have a two byte binary line length followed by the bytes of the line with a NUL pad byte if required to make the number of bytes even and no line ending characters at all?!? In CVS's philosophy, it just works. -Larry Jones Fortunately, that was our plan from the start. -- Calvin _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
