ancient RCS [bug|feature]?

[Paul Jackson]

In article <866 at voodoo.UUCP>, tomm at voodoo.boeing.com (Tom Mackey) writes:
|> Last week one of the developers went to check out "bugs" and got
|> the message:
|> 
|>     RCS/bugs,v  -->  bugs
|>     co error, line 1201: Hashtable overflow
|>     co aborted
|> 
|> To make a long story short, there is an internal limit in the
|> hashtable set to 240.

SGI's RCS commands are based on one of the 3.x versions from Purdue.
All 3.x and 4.x RCS versions, to my knowledge, have this limit.
The recent 5.5 version of RCS, released through the Free Software
Foundation, uses malloc to eliminate this limit.

We are considering upping this limit in some subsequent major
SGI release, but plans are not finalized.  The 5.5 RCS version
is not yet planned into any releases - but SGI will want to
pick it up sometime this decade, since 5.5 also has handling for
dates past 1999.

|> The thing that bothers me is that RCS
|> lets you check in the 240th revision with no warning of the
|> impending doom, just slams the door shut AFTER you have done
|> the damage.

Good point - it would be nice if the checkin of rev 240 had been
refused, to avoid damaging the ,v file.

|> So how about it... anyone else find this, how did you cope with it?

One of our folks internally gets around this by marking old and musty
revisions obsolete (rcs -o) but this really does completely eliminate
that old rev, so don't do this to some revision that you want to keep.

-- 

				I won't rest till it's the best ...
				Software Production Engineer
				Paul Jackson (pj at asd.sgi.com), x1373