eggert@twinsun.com (Paul Eggert) (02/11/91)
shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes:
rcsdiff error, line 2: Missing access list
This occurs when RCS version 3 (supplied in IRIX 3.2.1) tries to read RCS files
generated by RCS version 4.
What can I do to make these newer RCS files compatible with SGI's RCS?
You can work around the problem by deleting each RCS file's second line, which
should start with the word "branch".
If you often exchange RCS files with other software developers, you might
consider switching to RCS version 5, which not only reads the older file
formats, but also normally writes RCS files in a format that older RCS versions
can read. RCS 5 is available via anonymous FTP from prep.ai.mit.edu in
pub/gnu/rcs-5.5.tar.Z and pub/gnu/diff-1.15.tar.Z.
I think SGI is now upgrading to RCS version 4 and will eventually upgrade to
RCS version 5.pj@giraffe.sgi.com (Paul Jackson) (02/14/91)
shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes: > rcsdiff error, line 2: Missing access list > rcsdiff aborted >I believe this is an RCS version incompatibility ... srp@babar.mmwb.ucsf.edu (Scott R. Presnell) writes: >Yes, I understand that to be correct. Yes, there is an RCS incompatibility. SGI ships a version 3.x RCS. Versions 4.x of RCS are common in some other environments, and have an incompatibility with 3.x versions - a default branch feature was added, including a "branch X.X;" line. The "access" list that used to be on line 2 of the ,v file was pushed down to line 3, causing the above error message. You can "fix" 4.x created ,v files to be read by 3.x based RCS commands by removing this "branch ..." line (it's line 2 of the ,v file). SGI's present plans are to support 4.3 RCS in some future major software release. There are no plans at present for versions 5.5 or higher of RCS, but hopefully, someday, that too will happen. I won't rest till it's the best ... Software Production Engineer Paul Jackson (pj@asd.sgi.com), x1373
pj@giraffe.sgi.com (Paul Jackson) (02/15/91)
mogenix@tdisys.UUCP (MOGENET) writes: >From: "Emmanuel Mogenet" <mogenix%tdisys@inria.inria.fr> >I'd like to add a few questions [about RCS]: > > 1. What exact version of RCS is SGI supplying ? The version of RCS currently supplied by SGI is derived from RCS 3.?, which Walter Tichy, while at Purdue, supplied to Berkeley for free distribution in BSD, circa 1983-4. > 2. As RCS is a GNU software, what juridical maze allowed > SGI not to provide the sources ? Sometime later, Walter coordinated the distribution of RCS with the Free Software Foundation for more recent (than version 3) versions of RCS. Versions 4.x and 5.x are subject to GNU style licensing, not version 3.x When SGI delivers versions of RCS derived from 4.x or 5.x we will make source available, in accordance with the GNU license terms > 3. I met the same problems when jointly using the SGI version of > RCS, and the V4.5 obtained from GNUU, on an IBM RS/6000.The question > is: what am I supposed to do ? Individual ,v files produced by V4.x RCS can be made readable by V3.x by deleting line 2 "branch ..." SGI intends to continue supplying more current versions of RCS is future major software releases. If the RCS folks had not introduced the "branch" incompatibility between V3.x and V4.x (which error is corrected as best it can be in V5.x), then these sorts of incompatibilities wouldn't have been. I won't rest till it's the best ... Software Production Engineer Paul Jackson (pj@asd.sgi.com), x1373
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (02/15/91)
In article <9102110954.AA05236@tdisys.uucp>, mogenix@tdisys.UUCP (MOGENET) writes: > From: "Emmanuel Mogenet" <mogenix%tdisys@inria.inria.fr> > Subject: > > I'd like to add a few questions: > ... > 2. As RCS is a GNU software, what juridical maze allowed > SGI not to provide the sources ? > ... The RCS in IRIX 3.3.2 predates the GNU involvement with people at Purdue. It predates the source on the 4.3BSD tapes. It many even predate the founding of Stallman's FSF--I don't remember the important dates. SGI is not violating the copyleft, and in fact one of the difficulties that Paul is working on is how to comply with the copyleft when his new version is shipped. The easy issues already solved include releasing source for our enhancements of the old RCS to support symbolic links for archives. The hard issues including finding space on some tape for the new RCS source. Vernon Schryver, vjs@sgi.com
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (02/16/91)
Concerning my note about solving FSF source release issues for RCS, someone wrote me: > I've read the copyleft very carefully, and I believe you could > satisfy the copyleft by simply putting the source code for RCS (or any > other FSF software) on a separate tape, and charging your customers for > the full cost of making and shipping the tapes. It would also be appropriate > to deposit a copy with the FSF for their dissemination over the network. That is consistent with my understanding. Unfortunately, building and shipping tapes is not so simple. It is relatively simple to build the masters for such a tape, even after you handle the paper work that must accompany them to the release group, and from the release group to those who manufacture tapes, keep the vault copies, and so on. It is not too bad to get the right entries into the price book. It is not too hard to prepare the various kinds of documentation describing the contents of the tape for the sales force, customers, field service, and the software support organization. One should have little trouble getting the master past the quality assurance organization, but you will need instructions for them to determine if the manufactured tapes contain the right stuff. There must be enough documentation, even if only a README somewhere so that the next time someone works on RCS they'll be able to figure out which of the hoops must be modified and leaped thru again. And so on seemingly forever. From interviewing many people from and at other companies since I went professional in the late 60's, I must note that SGI has so little bureaucracy that many with different histories are horrified. Commercial computer hardware or software developlment is a lot more work and less fun than in the academic world. Maybe that's why there is more money involved. Vernon Schryver, vjs@sgi.com