bug-cvs
[Top][All Lists]
Advanced

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

Re: different CVS_SERVER for different hosts


From: Paul Edwards
Subject: Re: different CVS_SERVER for different hosts
Date: Thu, 30 Oct 2003 17:45:33 GMT

"Mark D. Baushke" <mdb@cvshome.org> wrote in message 
news:mailman.2832.1067533972.21628.bug-cvs@gnu.org...
>> > |E.g. fork() is provided?  And if it is, it will work on any
>> > |C89 compiler?  Borland C++ 3.1 for DOS is 100%
>> > |ISO-conforming.  So is SAS/C for MVS (OS/390).
>> >
>> > These compilers don't provide access to system functions?
>>
>> There is no such system function on DOS or MVS.

> MVS has POSIX and USS (Unix System Services).

Only very recent versions of OS/390, not MVS or MVS/XA.

And even then, it is not native support, it is a restrictive
emulator-like environment, similar to running a DOS
emulator on a Macintosh and then saying that the Macintosh
supports the DOS API.

> The cvs 1.11.9 sources already have a call to either vfork() or fork()
> in them (c.f., src/run.c). The solution in the past has been to provide
> a windows-NT/run.c file to implement the same behavior where possible. I
> do not see that particular API needing to change, but even if it does,
> it should be possible to still work on windows-NT for a while yet.

All the chmod() stuff is not-C89 and non-sensical on MVS too.

> In the worst case, folks could use a program to de-ansify the cvs 1.12.x
> sources such as the unprotoize program.

You don't need to de-ansify the code.  The environments I mentioned,
MVS(/XA) and DOS have compilers that conform 100% to
ISO/IEC 9899:1990.  And they don't have a fork or a chmod in
sight.

> That said, other folks out there are developing POSIX.3 support for
> windows boxen (cygwin is one such example).

> I believe I have even seen IBM mentioning OpenEdition MVS POSIX.1
> compliance in various press releases.

So don't say CVS is C89 compliant, it is Posix compliant,
thus only portable to Posix environments.

> For those systems that do not enjoy the ability to run a cvs client, I
> suppose they may have to fall back on sharing filesystems with systems
> that can do the checkout.

Not exactly sure what you mean here.

RCS and diff3 could be made C89 compliant, if they aren't
already.  Because CVS traverses directories, it would need
machine-specific code in order to do this, e.g. on MVS the
code to search a PDS.  Or have the ability to use a flat file to
specify all the files that comprise your project.  You could
come close.

But forget about this client/server stuff, it would all be local.
You could come close to making CVS portable to any C89
conforming platform.  Working locally, not this client/server
stuff, which is not portable to C89, the concept doesn't exist
in C89.  In C89, all I/O is done via files.  Opened with
fopen(), not open().

BFN.  Paul.




reply via email to

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