info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What forum to propose new port?


From: Larry Jones
Subject: Re: What forum to propose new port?
Date: Mon, 11 Mar 2002 12:00:23 -0500 (EST)

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 <address@hidden>, 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]