few@gupta.portal.com (Frank Whaley) (03/15/91)
I've just finished porting RCS v5.5 to MS-DOS and OS/2, and I'm planning on sending binaries and manpages to the moderator of comp.sys.ibm.pc.binaries. I'll also send a source package that includes both new and original source, along with makefiles for Turbo C 2.0 and Microsoft C 5.1 and 6.0. This port also includes GNU diff v1.15 (required by this version of RCS). I've seen a few different methods of handling the RCS-file naming problem. Appending ",v" doesn't work for FAT filesystems, and we live with the 8+3 filename limitation. I want to describe the mechanism I chose, and why, so anyone with a *vastly* superior system can get back to me quickly before I mail off the files. I chose the backquote character (`) as RCSSEP because it is a legal filename character and unlikely to conflict with extensions used by common programming languages. Appending a single character instead of two means that filenames with 0, 1 or 2 character extensions cna be handled by simply appending the backquote. The naming rules are: filename -> filename.` filename.? -> filename.?` filename.?? -> filename.??` file.??? -> file`.??? filename.??? -> filenam`.??? (warning issued) Note that this scheme does not interfere with checking in or out full filenames, that is co somefile.asm will cause somefile.asm to be deposited in the current directory. However, co /some/other/place/RCS/somefil`.asm will leave somefil.asm in the current directory. This is vulgar, but is actually the lesser of many evils. Anyone suggesting that RCS files can be kept with their original names and forced into the .\RCS directory should download the source and examine the consequences :-) The following extensions are recognized, with the given default comment leader. "ada", "-- ", /* Ada */ "asm", ";; ", /* ASM */ "bat", ":: ", /* BAT */ "c", " * ", /* C */ "cpp", "// ", /* C++ */ "cmd", ":: ", /* CMD */ "def", ";; ", /* Windows */ "dlg", " * ", /* Windows */ "for", "c ", /* Fortran */ "h", " * ", /* C-header */ "inc", ";; ", /* ASM include */ "l", " * ", /* lex */ "lsp", ";; ", /* LISP */ "mac", ";; ", /* ASM macro */ "p", " * ", /* Prototype */ "pas", " * ", /* Pascal */ "pl", "% ", /* Prolog */ "rc", " * ", /* Windows */ "tex", "% ", /* TeX */ "y", " * ", /* yacc */ -- Frank Whaley Software Engineer Gupta Technologies few@gupta.com
swh@hpcupt1.cup.hp.com (Steve Harrold) (03/19/91)
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 ---------------------
rommel@Informatik.TU-Muenchen.DE (Kai-Uwe Rommel) (03/22/91)
In article <68410004@hpcupt1.cup.hp.com> swh@hpcupt1.cup.hp.com (Steve Harrold) writes in a followup to an announcement of RCS 5.5 for DOS and OS/2: >I'm glad you've done the RCS5.5 port to MSDOS as it will save me quite >a bit of time. Saves me the time to port to OS/2 too. I had modified a DOS port of 4.2 for 4.3 for OS/2 a while ago. >You asked for commentary on the ",v" problem, so here is my suggestion. ... >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). Problems arise when you want to specify both the source file name and the RCS file name on the command line. The RCS programs would then have difficultites to determine which of the files the RCS file is and which the source file. Some programs that work on top of RCS use this. >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. There are lots of tools to convert between DOS and Unix text file formats. FTP even does this automatically in ASCII mode. >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. No need, I think. Can only cause problems. >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. Maybe diffs could be sent to comp.sources.misc? The original sources can be found in many archives ... But anon. FTP location would be fine of course. Kai Uwe Rommel
alexande@borland.com (Mark Alexander) (03/26/91)
In article <1991Mar22.080547.5576@Informatik.TU-Muenchen.DE> rommel@Informatik.TU-Muenchen.DE (Kai-Uwe Rommel) writes: >Problems arise when you want to specify both the source file name and >the RCS file name on the command line. The RCS programs would then have >difficultites to determine which of the files the RCS file is and which >the source file. Some programs that work on top of RCS use this. One possibility is that RCS could read the first four bytes of the file in question. If they are "head" the file is probably an RCS file. It sounds terrible, but I had to do this in an MS-DOS port of RCS 4 to allow users to keep their RCS files in arbitrary directories. It's pretty unlikely for an ordinary text file to start with "head".