Actually, there is more to the issue than just capabilities. I personally like RCS and think it is much more capable than SCCS, so it is my first choice. However, for really large projects with lots of people, you usually have about a man year's worth of shell or perl scripts that actually drives your library and build system. The developers often rarely touch the real RCS or SCCS interface, but instead interact through these scripts. Usually, when a sysdmin has to make a choice about moving their library sytem, it's not a question of which archive is better, but what are they going to do with all those custom scripts they built up over the years to drive things. That's usually the most painful part. However, for anyone just starting a new project, save a little headache and go RCS from the start. In answer to the SCCS question, do a search for CSSC. This is a free replacement that I've seen floating around that appears to be mostly compatible with things like SCCS on Solaris/SunOS. On Thu, Mar 16, 2000 at 10:54:49AM -0500, Steven W. Orr wrote: > The only advantage that SCCS has is that it allows concurrent locking > of the same revision of the file. RCS does not support > this. Personally, in a project small enough to use RCS or SCCS, I > claim you don't *want* cuncurrent locking. SCCS does? I've never seen a version that supported that. What platfrom were you using it on? Sun Workshop has some tools that fake out the system to make it look like it can do that, but SCCS on Solaris does not actually have that feature built in. The Workshop tool plays some renameing games with the SCCS temp and lock files and has a merge tool to piece it all togeather when you're done. You could do the equivalent thing with RCS though. > =>On Mar 16, [EMAIL PROTECTED] wrote: > =>> Is SCCS available on Red Hat Linux 6.1 ? > =>> If not, is there any other alternative utility available for configuration > =>> management? > => > =>Check out RCS. I don't think it's as powerful as SCCS, but I hear it's easier > =>to use. It is in its own package: rcs-5.7-10 > => > =>-Michael > => > => > > > -- > To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" > as the Subject. > -- J. Scott Kasten jsk AT tetracon-eng DOT net "That wasn't an attack. It was preemptive retaliation!" -- To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject.