rose@galtee.cs.wisc.edu (Scott M. Rose) (03/07/91)
Coherent Digest Vol. 91.1, No. 16 Tue Mar 5 13:32:31 CST 1991
Today's Topics:
ZOO
zip vs tar/compress
Re: ZOO
Here's what RCS is
dmake
RE: .ZIP and other nightmares
dmake and RCS
Traffic and PANIC
Terminal
Administrivia:
The Coherent Digest is a forum for discussion of the MWC Coherent 3.x
operating system. Send submissions to "coherent@cs.wisc.edu" and
administrivia to "coherent-reqeust@cs.wisc.edu". Previous issues are
archived for anonymous FTP access on piggy.ucsb.edu in the directory
"pub/coherent/mail-list".
[There is a call for votes for comp.os.coherent currently underway. Send
your votes to "lark@tivoli.com". -Ed.]
[Did you get two copies of this digest? Sorry, there is a problem with
SendMail at the originating site at the moment. -Ed.]
----------------------------------------------------------------------
Date: Mon, 04 Mar 91 11:20:21 CST
From: G-SKER@vm1.spcs.umn.edu
To: coherent
Subject: ZOO
Subject: ZOO
Lar,
If you have ZOO for Coherent, could you let the rest of us know?
Thanks,
Gerry
Gerald Skerbitz University of Minnesota
612/626-5379 g-sker@vm1.spcs.umn.edu g-sker.uminn1.bitnet
------------------------------
Date: Mon, 4 Mar 91 11:49:35 CST
From: rosevax.rosemount.com!grante%rutgers.UUCP@spool.cs.wisc.edu (Grant B. Edwards)
To: coherent@spool.cs.wisc.edu
Subject: zip vs tar/compress
I too prefer tar/compress over zip. The unzip I've got on my Coherent
system is intermittent, and I've never gotten unzip to build on my
other systems. I don't have any way to create zip archives on any
system.
I can tar and untar and compress and uncompress on all my systems with
no problems. The size advantage that zip has over tar and 12-bit
compress is not (in my opinion) worth the hassle of not being able to
access the archive reliably (or at all on some systems).
Grant Edwards
Rosemount Inc, CB7 He who dies with
12001 Technology Drive grante@hydro.rosemount.com the most manuals
Eden Prairie, MN 55344 uunet!rosevax!hydro!grante wins.
------------------------------
Date: Mon, 4 Mar 91 12:49:33 -0600
From: lark@greylock.tivoli.com (Lar Kaufman)
To: G-SKER@vm1.spcs.umn.edu, coherent
Subject: Re: ZOO
I don't have ZOO for Coherent, but I do have MS-DOS
binaries and source stashed away- I should add that
my version is about 2 years old, as I haven't been
doing much downloading for several years. I'm sure
that ZOO source is readily available on the net and
it should compile cleanly on Coherent -there's nothing
exotic in the code that I remember.
I know that Rahul Dhesi, the author of ZOO is still
active on the net, as I see his name appear from
time to time. Anyone got current ZOO sources, or
know a valid ftp site?
- -lar
------------------------------
Date: Mon, 4 Mar 91 12:01:08 CST
From: rosevax.rosemount.com!grante%rutgers.UUCP@spool.cs.wisc.edu (Grant B. Edwards)
To: coherent@spool.cs.wisc.edu
Subject: Here's what RCS is
RCSINTRO(1L) MISC. REFERENCE MANUAL PAGES RCSINTRO(1L)
NAME
rcsintro - introduction to RCS commands
DESCRIPTION
The Revision Control System (RCS) manages multiple revisions
of text files. RCS automates the storing, retrieval, log-
ging, identification, and merging of revisions. RCS is use-
ful for text that is revised frequently, for example pro-
grams, documentation, graphics, papers, form letters, etc.
The basic user interface is extremely simple. The novice
only needs to learn two commands: ci(1L) and co(1L). Ci,
short for "check in", deposits the contents of a text file
into an archival file called an RCS file. An RCS file con-
tains all revisions of a particular text file. Co, short
for "check out", retrieves revisions from an RCS file.
Functions of RCS
o Storage and retrieval of multiple revisions of text.
RCS saves all old revisions in a space efficient way.
Changes no longer destroy the original, because the
previous revisions remain accessible. Revisions can be
retrieved according to ranges of revision numbers, sym-
bolic names, dates, authors, and states.
o Maintenance of a complete history of changes. RCS logs
all changes automatically. Besides the text of each
revision, RCS stores the author, the date and time of
check-in, and a log message summarizing the change.
The logging makes it easy to find out what happened to
a module, without having to compare source listings or
having to track down colleagues.
o Resolution of access conflicts. When two or more pro-
grammers wish to modify the same revision, RCS alerts
the programmers and prevents one modification from cor-
rupting the other.
o Maintenance of a tree of Revisions. RCS can maintain
separate lines of development for each module. It
stores a tree structure that represents the ancestral
relationships among revisions.
o Merging of revisions and resolution of conflicts. Two
separate lines of development of a module can be
coalesced by merging. If the revisions to be merged
affect the same sections of code, RCS alerts the user
about the overlapping changes.
o Release and configuration control. Revisions can be
assigned symbolic names and marked as released, stable,
experimental, etc. With these facilities, configura-
tions of modules can be described simply and directly.
o Automatic identification of each revision with name,
revision number, creation time, author, etc. The iden-
tification is like a stamp that can be embedded at an
appropriate place in the text of a revision. The iden-
tification makes it simple to determine which revisions
of which modules make up a given configuration.
o Minimization of secondary storage. RCS needs little
extra space for the revisions (only the differences).
If intermediate revisions are deleted, the correspond-
ing deltas are compressed accordingly.
Getting Started with RCS
Suppose you have a file f.c that you wish to put under con-
trol of RCS. Invoke the check-in command
ci f.c
This command creates the RCS file f.c,v, stores f.c into it
as revision 1.1, and deletes f.c. It also asks you for a
description. The description should be a synopsis of the
contents of the file. All later check-in commands will ask
you for a log entry, which should summarize the changes that
you made.
Files ending in ,v are called RCS files (`v' stands for
`versions'), the others are called working files. To get
back the working file f.c in the previous example, use the
check-out command
co f.c
This command extracts the latest revision from f.c,v and
writes it into f.c. You can now edit f.c and check it back
in by invoking
ci f.c
Ci increments the revision number properly. If ci complains
with the message
ci error: no lock set by <your login>
then your system administrator has decided to create all RCS
files with the locking attribute set to `strict'. In this
case, you should have locked the revision during the previ-
ous check-out. Your last check-out should have been
co -l f.c
Of course, it is too late now to do the check-out with lock-
ing, because you probably modified f.c already, and a second
check-out would overwrite your modifications. Instead,
invoke
rcs -l f.c
This command will lock the latest revision for you, unless
somebody else got ahead of you already. In this case, you'll
have to negotiate with that person.
Locking assures that you, and only you, can check in the
next update, and avoids nasty problems if several people
work on the same file. Even if a revision is locked, it can
still be checked out for reading, compiling, etc. All that
locking prevents is a CHECK-IN by anybody but the locker.
If your RCS file is private, i.e., if you are the only per-
son who is going to deposit revisions into it, strict lock-
ing is not needed and you can turn it off. If strict lock-
ing is turned off, the owner of the RCS file need not have a
lock for check-in; all others still do. Turning strict lock-
ing off and on is done with the commands
rcs -U f.c and rcs -L f.c
If you don't want to clutter your working directory with RCS
files, create a subdirectory called RCS in your working
directory, and move all your RCS files there. RCS commands
will look first into that directory to find needed files.
All the commands discussed above will still work, without
any modification. (Actually, pairs of RCS and working files
can be specified in 3 ways: (a) both are given, (b) only the
working file is given, (c) only the RCS file is given. Both
RCS and working files may have arbitrary path prefixes; RCS
commands pair them up intelligently).
To avoid the deletion of the working file during check-in
(in case you want to continue editing), invoke
ci -l f.c or ci -u f.c
These commands check in f.c as usual, but perform an impli-
cit check-out. The first form also locks the checked in
revision, the second one doesn't. Thus, these options save
you one check-out operation. The first form is useful if
locking is strict, the second one if not strict. Both
update the identification markers in your working file (see
below).
You can give ci the number you want assigned to a checked in
revision. Assume all your revisions were numbered 1.1, 1.2,
1.3, etc., and you would like to start release 2. The com-
mand
ci -r2 f.c or ci -r2.1 f.c
assigns the number 2.1 to the new revision. From then on,
ci will number the subsequent revisions with 2.2, 2.3, etc.
The corresponding co commands
co -r2 f.c and co -r2.1 f.c
retrieve the latest revision numbered 2.x and the revision
2.1, respectively. Co without a revision number selects the
latest revision on the "trunk", i.e., the highest revision
with a number consisting of 2 fields. Numbers with more than
2 fields are needed for branches. For example, to start a
branch at revision 1.3, invoke
ci -r1.3.1 f.c
This command starts a branch numbered 1 at revision 1.3, and
assigns the number 1.3.1.1 to the new revision. For more
information about branches, see rcsfile(5L).
Automatic Identification
RCS can put special strings for identification into your
source and object code. To obtain such identification, place
the marker
$Header$
into your text, for instance inside a comment. RCS will
replace this marker with a string of the form
$Header: filename revision_number date time
author state $
With such a marker on the first page of each module, you can
always see with which revision you are working. RCS keeps
the markers up to date automatically. To propagate the
markers into your object code, simply put them into literal
character strings. In C, this is done as follows:
static char rcsid[] = "$Header$";
The command ident extracts such markers from any file, even
object code and dumps. Thus, ident lets you find out which
revisions of which modules were used in a given program.
You may also find it useful to put the marker $Log$ into
your text, inside a comment. This marker accumulates the log
messages that are requested during check-in. Thus, you can
maintain the complete history of your file directly inside
it. There are several additional identification markers;
see co(1L) for details.
IDENTIFICATION
Author: Walter F. Tichy, Purdue University, West Lafayette,
IN, 47907.
Revision Number: 1.2 ; Release Date: 89/05/02 .
Copyright (C) 1982, 1988, 1989 by Walter F. Tichy.
SEE ALSO
ci(1L), co(1L), ident(1L), merge(1L), rcs(1L), rcsdiff(1L),
rcsmerge(1L), rlog(1L), rcsfile(5L),
Walter F. Tichy, "Design, Implementation, and Evaluation of
a Revision Control System," in Proceedings of the 6th Inter-
national Conference on Software Engineering, IEEE, Tokyo,
Sept. 1982.
------------------------------
Date: Mon, 4 Mar 91 14:19:10 CST
From: rosevax.rosemount.com!grante%rutgers.UUCP@spool.cs.wisc.edu (Grant B. Edwards)
To: coherent@spool.cs.wisc.edu
Subject: dmake
I believe that the package referred to that requires dmake was the
port of RCS that I did.
You don't have to use dmake, but if you want to use Coherent's make
you will have to edit the makefiles to work around the
incompatibilities in Coherent make. Most of these problems should be
fixed in the next release of Coherent make. But, I will continue to
use dmake since it is the make that I use on other systems and I have
never seen it choke on a makefile that came off the network the way
that Coherent make does.
dmake is completely compatible with BSD make and System V augmake,
with some handy extensions to help users of brain-dead systems like
MS-DOS.
If you don't like dmake then just return the unused portion of the
archive, and I will happily refund triple the purchase price.
The Coherent port of dmake that is available on cs.umn.edu is a 12 bit
compressed tar archive of the standard source distribution of dmake,
with the Coherent additions. That archive will build dmake on System
3, System 5, SunOS, Coherent, BSD 2something and BSD 4.2 or 4.3. It
will also build on MS-DOS, OS/2, and TOS on Amiga systems. I suspect
it could be ported to VMS, but thinking aout that makes my teeth hurt.
If there is sufficient interest, I could delete the stuff that isn't
needed for Coherent. That would save some disk space, but probably
not too much. Dmake includes extensive documentation, including nroff
source for an excellent users manual.
Unfortunately, Coherent's nroff and man macros aren't too compatible,
so I included the formatted manual as well. I did the same for the
RCS distribution. If everybody out there has access to a system with
a real nroff -man, then I will discontinue the practice of including
formatted documentation in the packages I post.
Once dmake is built, the executable is only about 60K and you can take
the sources and documentation off the system.
If you don't have a couple of Meg of disk space to untar and build
something then you might as well just open up a vein. Better yet, you
could buy a Commodore VIC-20 and write BASIC programs that will run in
4K of RAM with a cassette deck for mass storage. If small is
beautiful, then uselessly microscopic must be even better.
In my opinion, dmake qualifies for small since it compiles and runs
under Coherent without any problems. Gnu-make on the other hand is so
big that some of the individual files are too big to compile, another
prime example of Gnu-bloat at its ugliest.
I know that some people prefer zip/zoo/dooda archive formats, but tar,
cpio, and compress are the only ones that are common to all of the
systems I use regularly (even MS-DOS), so everything I post will be in
compressed tar files.
One last flame:
If you have found bugs in something I have posted, or have some
constructive comments or suggestions on what needs to be ported next,
I'll be happy to listen. But if all you want to do is whine about how
you don't like something that has been offered to you for free, then
pi__ off, I've got work to do, and if you don't want me to share the
tools I've developed in that process then that's your problem.
Grant
------------------------------
Date: Tue, 05 Mar 91 14:34:20 +0100
From: Jean-Loup Gailly <jloup@chorus.fr>
To: coherent
Cc: jloup@chorus.fr
Subject: RE: .ZIP and other nightmares
Richard Nickle writes:
> This would not be such a big problem, but so far, about 1 out
> of every 2 of these .zips trashes my filesystem and
> forces a reboot, then I gotta spend 5 minutes or so clearing
> i-nodes. (Like month.zip just did about five minutes ago).
Which unzip are you using and on which system? The current
public version of portable unzip is 4.01, available on simtel
or its mirrors (wuarchive) in PD1:<MISC.UNIX>. If you have trouble
with it, please send a message to INFO-ZIP@WSMR-SIMTEL20.ARMY.MIL,
indicating where the .zip file causing trouble can be found.
> If there was an adequate, public-domain
> ZIP utility for Unix, I wouldn't see any problem at all, but
> there isn't, and since ZIP at its heart is proprietary, it just
> ain't going to happen within a convenient timeframe.
Well, there *is* an adequate public domain unzip for Unix, and also a
beta version of zip. This beta version is still slow but works very well
otherwise and is 100% compatible with pkzip. It will appear "within a
convenient timeframe" at the same place as unzip.
The zip *format* (not the code) has been put in the public domain by its
creator Phil Katz, so there is no problem here.
Jean-loup Gailly
jloup@chorus.fr
------------------------------
Date: Tue, 05 Mar 91 07:52:31 CST
From: G-SKER@vm1.spcs.umn.edu
To: coherent
Subject: dmake and RCS
Subject: dmake and RCS
Ouch!
I guess I owe you an apology, Grant. I'm sorry, and thanks for porting
RCS.
Thanks also to all the people who so patiently explained what RCS is.
{I get it I get it!!! I think I got about 5 copies of the manual entry :-) }
Gerry
Gerald Skerbitz University of Minnesota
612/626-5379 g-sker@vm1.spcs.umn.edu g-sker.uminn1.bitnet
------------------------------
Date: 05 Mar 91 12:08:14 EST
From: Stephane Doucet <73207.1247@CompuServe.COM>
To: <coherent>
Subject: Traffic and PANIC
HI,
I don't know if it is just me but I am getting doubles and triples
of all traffic. In the 15 messages I just had 10 of them were duplicates.
...and some of them big. Anyone else getting this type of traffic?
Also ... on a Coherent note. Has anyone had success doing logins
from a computer connected via a straight serial port (no modem)? I tried
using a null modem cable and get no where. I was having COM port problems
too at the same time so I am curious. Any people have done this
successfully?
And lastly....PANIC TRAPS? Why? Why? Why? I was told that it is
caused by bad memory problems on the board but now I am getting them
at boot time too. :(
- -Stephane
------------------------------
Date: Tue, 05 Mar 91 13:30:10 CST
From: G-SKER@vm1.spcs.umn.edu
To: coherent
Subject: Terminal
Subject: Terminal
Yes, Stephane, I run a terminal on my coherent system. It's on COM2. If there
is something specific, let me know.
I'm about ready to get a terminal running on my modem as a dial-in line. Can
someone tell me if modeminit is NECESSARY, and what the ttys entry should look
like. (1com1r?)
My though is that if it's truly remote, won't the operating system refuse
to send a login message to it until it has a CD? And if so, is it really
necessary for the modem to be silent? (Hayes AT Q1) Yes, I guess I would
have to turn autoanswer on (Hayes AT S0=1), but I can do that with hardware
if necessary.
Thanks,
Gerry
Gerald Skerbitz University of Minnesota
612/626-5379 g-sker@vm1.spcs.umn.edu g-sker.uminn1.bitnet
------------------------------
End of Coherent Digest Vol. 91.1, No. 16
****************************************
--
Scott Rose
rose@cs.wisc.edu
(608) 238-3801