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