[comp.unix.misc] ancient RCS [bug|feature]?

tomm@voodoo.boeing.com (Tom Mackey) (02/02/91)

I've used RCS now for about 6 years, and for the last 4 years
we have managed a large software project (~250 files) under
RCS.  So far, so good.  We can go back all the way to the first
release of the system (not that we want to) and it is nice to
trace the evolution of certain modules through the rlog entries.

We thought we had it all nailed until last week.  One of the
files we track is our ongoing bug list.  Now either we have
more bugs than normal, or a larger system than normal, as it
gets revised quite frequently (at least twice a week).  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.  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.

So how about it.... anyone else find this, how did you cope with
it (we obviously have to split the ,v files, but what's the most
nifty way), and have any other computer vendors enhanced RCS to
deal with this?  We use Silicon Graphics equipment.

So far, no critical files have been affected, but several of them
currently have 200 or so revisions.

eggert@twinsun.com (Paul Eggert) (02/02/91)

tomm@voodoo.boeing.com (Tom Mackey) writes:

>    RCS/bugs,v  -->  bugs
>    co error, line 1201: Hashtable overflow
>    co aborted

>So how about it.... anyone else find this, how did you cope with
>it (we obviously have to split the ,v files, but what's the most
>nifty way), and have any other computer vendors enhanced RCS to
>deal with this?  We use Silicon Graphics equipment.

If you have the source code to your old version of RCS, you can increase the
hash table size and recompile.  But perhaps you should upgrade to RCS 5.5,
which is limited only by the amount of virtual memory available.  You can ftp
RCS 5.5's source code from cs.purdue.edu in pub/RCS/rcs.5_5.tar.Z; I built and
used it under IRIX 3.3 without a hitch.

pj@giraffe.asd.sgi.com (Paul Jackson) (02/02/91)

In article <866@voodoo.UUCP>, tomm@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@asd.sgi.com), x1373

dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (02/05/91)

In <866@voodoo.UUCP> tomm@voodoo.boeing.com (Tom Mackey) writes:

>    co error, line 1201: Hashtable overflow
>    co aborted

>So how about it.... anyone else find this, how did you cope with
>it (we obviously have to split the ,v files, but what's the most
>nifty way)..

I came upon the hashtable limit a few months ago, when checking out a
very large file.  The solution was simple and quick:  I changed the
value of hshsize in rcsbase.h and recompiled the RCS stuff.  The RCS
source is freely distributable and available from the Free Software
Foundation.

===================================================================
RCS file: RCS/rcsbase.h,v
retrieving revision 1.1
diff -r1.1 rcsbase.h
5c5
< #define RCSBASE "$Id: rcsbase.h,v 1.1 90/11/28 18:24:18 dhesi Exp $"
---
> #define RCSBASE "$Id: rcsbase.h,v 1.2 90/11/28 18:29:49 dhesi Exp $"
54a55,58
>  * Revision 1.2  90/11/28  18:29:49  dhesi
>  * We were seeing hash table overflow when looking at /stride/changes.
>  * Increased size of hash table to 547 (was 239).
>  * 
167,168c171,172
< #define hshsize           239 /* hashtable size; MUST be prime and -1 mod 4 */
<                               /* other choices: 547 or 719                  */
---
> #define hshsize           547 /* hashtable size; MUST be prime and -1 mod 4 */
>                               /* choices: 239, 547, or 719                  */
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP:  oliveb!cirrusl!dhesi

rob@array.UUCP (Rob Marchand) (02/19/91)

In article <2926@cirrusl.UUCP> Rahul Dhesi writes:
>In <866@voodoo.UUCP> tomm@voodoo.boeing.com (Tom Mackey) writes:
>
>>    co error, line 1201: Hashtable overflow
>>    co aborted
>
>>So how about it.... anyone else find this, how did you cope with
>>it (we obviously have to split the ,v files, but what's the most
>>nifty way)..
>
>	(Rahul's solution to the problem for RCS 4.4 or whatever)
>
	Alternatively, you might be interested in RCS v5.5, which, I think,
	is the latest version.  I've just had a look in rcsbase.h, and as
	of version 5.0, the log claims that all compile time limits have 
	been removed, and data structures such as the hash table are 
	allocated dynamically.  Certainly the fixed stuff pertaining to
	the hash table is gone; I can't speak for the rest.  5.5 claims
	to have a number of other features which might be of interest.  
	If it is not available via ftp to the author (from, hmmm, osu-cis,
	the `definitive' source at MIT prep.mit.edu or whatever, or uunet),
	I can forward the source to the latest version.

				Cheers!
				Rob Marchand
				rob@array.UUCP
-- 
Rob Marchand                   UUCP  : uunet!attcan!lsuc!array!rob
Array Systems Computing        ARPA  : rob%array.UUCP@uunet.UU.NET
401 Magnetic Drive, Unit 24    Phone : +1(416)736-0900   Fax: (416)736-4715
Downsview, Ont CANADA M3J 3H9  Telex : 063666 (CNCP EOS TOR) .TO 21:ARY001