Terrence Enger writes: > > (*) What does it mean? Using an existing distribution of cvs > executing on Win95, I have had some success (very small test, no > observed problems) controlling ASCII source in the hierarchichal > part of the IFS of OS/400. But I can see value in using cvs to > control a wider variety of stuff on the 400, ordered by what I > would deem to be descending value: source physical file members > (there are *lots* of those in the world), EBCDIC files, database > files. Others with better imaginations than I can extend the > list.
That looks like English, but I can't understand a word you said. I think you're going to have to educate us about the OS/400 environment before we can have an intelligent discussion. I feel obliged to note, however, that CVS was designed to version programming *source* files, not arbitrary files. As is frequently discussed here, unless the files are divided into lines that can be meaningfully processed with something like the Unix 'diff' command, CVS really isn't a very effective tool. > (*) How much of this change can the main line of development tolerate? > I note for example, your discussion "multiplatform sofware desing > problem" on bug-cvs with Dimitry Naldaev <[EMAIL PROTECTED]>, where > you take a position against having cvs do code conversions. I can > imagine that much--but not all--of the necessary code would be > segreated into a platform-specific subdirectory. CVS was really designed to work in an ASCII environment. The only solution I can imagine for Dimitry's problem would be to rewrite CVS to use some universal character set (say, ISO 10646) internally (i.e., in the code, in the repository, in the client/server protocol, etc.) and convert between that and the system character set on I/O. That would be an enourmous amount of work, I suspect it would be difficult to do it in an upward compatible form, it would probably make the repository files incompatible with RCS, it would significantly increase the size of most people's repositories, it would undoubtedly slow down CVS operations, and it would probably be a portability problem. Changing CVS to work in an EBCDIC-only enviroment should be much less work and have much less impact. Even if you do have to interoperate between EBCDIC and ASCII, that shouldn't be too much more difficult since it is easy to define a useful, invertable mapping between ASCII and EBCDIC. (Unfortunately, it is so easy that there are lots of them, which could present a problem if all your users can't agree on a single one.) > In my limited study of the code, I see platform-specific files > mapping one function to different facilities of the platform but > no example of one platform providing more functionality than > another. Is there any case where you would like to exploit the > particular demands or capabilities of a particular platform? Two > special cases could make a pattern; one special case would likely > just make a mess. I can't think of any. The general philosophy is that CVS should work the same way everywhere. -Larry Jones Aw Mom, you act like I'm not even wearing a bungee cord! -- Calvin _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
