Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpda!hpcupt1!swh
From: swh@hpcupt1.cup.hp.com (Steve Harrold)
Newsgroups: comp.os.msdos.programmer
Subject: Re: RCS 5.5 for MS-DOS and OS/2
Message-ID: <68410004@hpcupt1.cup.hp.com>
Date: 18 Mar 91 19:44:11 GMT
References: <1991Mar15.075234.17433@gupta.portal.com>
Organization: Hewlett Packard, Cupertino
Lines: 81

To Frank Whaley (email to you bonced):

I'm glad you've done the RCS5.5 port to MSDOS as it will save me quite
a bit of time.

You asked for commentary on the ",v" problem, so here is my suggestion.

I've worked with a variant of RCS that extended the notion of the RCS
sub-directory.  If the RCS file was present in the working directory, this
variant RCS determined whether the RCS file was a directory or was a normal
file.  If the former, the standard behaviour was executed.  

On the other hand, if RCS was a normal file, it examined the first line of 
the file, and used THAT as the name of the directory where to place the 
",v" files.  In this way, the user could structure and locate his RCS 
archive anywhere he wanted simply by leaving a "pointer file" to it in the 
working directory.  The system allowed these indirect files to point to yet 
further indirect directories.

If you were to provide such an extension, you could allow users to use
your RCS in three ways:

	1) place archive in current directory
	2) place archive in RCS sub-directory
	3) place archive anywhere they want

In the latter 2 cases, you could drop the ",v" suffix, and store the archive
files with their unaltered original names.  To support all OS flavors,
you could provide a #define variable to control the form of the suffix 
(Unix would probably still want the ",v" suffix).

The ability to "place archive anywhere" could be enhanced further by using
an environment variable as the pointer to the "root" of the archive.  For 
example,

	SET RCSARCH=d:\archives\project1
	SET RCSROOT=e:\jobs\contract

This would mean that the sub-directory tree beneath the MSDOS work area 
e:\jobs\contract would be replicated beneath the archive d:\archives\project1.
Then when an RCS command was executed, if it found the environment variables
RCSROOT and RECSARCH, it would work out where working file's directory was
beneath the named "root", and use the parallel location under the RCSARCH 
directory as the archive location, creating intermediate sub-directories 
as required.

Naturally, to support UNIX-like environments, the backslashes would be
handled as fore-slashes interchangeably, so that an RCS pointer file on
MSDOS could be shuttled back and forth to Unix with zero change.

To change the subject, how are you handling the end-of-line delimiters under
MSDOS?  If you save the newlines as CRLF (0x0d0h) in the archive, then the
archive cannot be copied to a Unix platform and then be decoded correctly.  
A checkout under Unix of the DOS archive will place an 0x0d at the end
of each text line.  Conversely, a checkout under DOS of a Unix archive
(say, via PC/NFS) will not have properly delimited lines in the DOS
environment.

If you have not already done so, I strongly urge you to store the archive
with Unix linends, and let the DOS version of the program strip/restore
the extra character as needed.  This will provide much more interchangeability
and interoperability of RCS archives.

I hope I've been able to give you some food for thought.  Is it possible to
obtain a ZIP or ARC file of your sources before the cbip distribution?
If you can place the material on an anonftp machine somewhere, I could do
the download.  Email seems impractical given the size of the code.

Thanks for letting me air my views.  Hope it was helpful.

Regards,

Steve Harrold

--
---------------------
Steve Harrold			swh@hpda.hp.com
				...hplabs!hpda!swh
				HPG200/11
				(408) 447-5580
---------------------