At 12:00 PM 2002/03/11 -0500, you wrote:
>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.
Uh-oh. I'm gonna pack up my marbles and go back to coding <grin>. But
first ...
> I
>think you're going to have to educate us about the OS/400 environment
>before we can have an intelligent discussion.
Sad, but probably true. Well, not sad for me, as I really like using
OS/400 and talking about it. Stop me if I bore you too much.
OS/400 offers filesystems with a hierarchical directory structure. Mostly,
people used to *nix or Windows would feel quite at home there. In
particular, wherever you are in the hierarchy, cvs can create the cvs
subdirectoy that it wants to create. The small successful test from my
original post involved simply mapping a directory in the hierarchical
directory structure to a network drive on the machine running cvs.
OS/400 also offers one widely used filesystem, "/QSYS.LIB", which is much
more restrictive in many ways. Within this filesystem, source is stored in
"source physical file members". These are at the lowest level of the name
space, and cvs cannot create a subdirectory as a sibling to these members.
No way, No Such Thing, It ain't gonna happen.
("IFS", which stands for Integrated File System, is a naming scheme which
can address all of these things. However, it is the only naming scheme
offered which can address files outside the /QSYS.LIB filesytem, and people
quite often write IFS when they mean specifically the files which only IFS
can address. Let me try that again... People often write "IFS" when they
are talking about what I have called the "filesystems with a hierarchical
directory structure".)
I have tried to make cvs work by creating links in the hierarchical
directory structure to source physical file members. Little success, but I
still think it *should* have worked. Someday soon, I shall try again.
> 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.
Yes, I have noticed, and even contributed a bit to, that discussion. I did
not want to limit discussion prematurely, but using cvs for OS/400 objects
other than source code is a question for another decade.
>
>> (*) 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.)
What part of cvs knows that it is working in ASCII? So far, I have noticed
only a couple of places (and the dependency is implicit). OTOH, I have
only looked at code that the compiler complained about.
I think an OS/400 port would have to work with both ASCII and EBCDIC if we
want it to be widely accepted. That said, there are still design choices
open. For example,
(*) In the simplest way I can imagine working with both code sets, checkout
gives back whatever bit pattern was checked in. The user had better
interpret those bits the right way. This might even be more useful than it
sounds. Lots of installations have all source code in EBCDIC, and I can
imagine that whole projects would have all source code in ASCII. Even for
this simple-minded solution, diff requires work: maybe it even worked when
I used it on an EBCDIC file, but I was reading the output on an ASCII
terminal. So, for all I could tell, it might not even have been close to
working.
(*) With knowledge of code page of a file or member checked in, checkout
can ensure that its output file or member has the same code page. This is
most directly accomplished by storing the code page explicitly in the
repository. Will this be a big deal?
(*) I am tempted to not even think about anything further in this area
until there is demand for it.
>
>> 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
>
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
