naked SCCS really SCCS!

[Greg Woods]

In article <1580 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
> > [Likely article <354 at greek.UUCP>, Author unknown]
> >
> > Bullshit.  It has done a damn good job for me, and front-end interfaces just
> > add more steps without adding appreciable functionality or ease of use.
>
> Bullshit.  I find "admin" a pain to use; the BSD "sccs" front-end
> program's "sccs create" and "sccs enter" programs make it much nicer -
> it takes *fewer* steps to use them than to use full-frontal "admin". 
> Perhaps you just didn't have the right front-ends?
>
> The "sccs" program also adds useful functionality, such as the "sccs
> info" function which tells you what modules are checked out for editing
> and who has them checked out.

Well, bullshit to you both :-)

I must agree, admin can be difficult, though I find it is only
ever used once per source module, or even once per directory full
of source modules.

I have had extensive experience with three different source
management tools: SCCS, RCS, and Polytron's VCS.

I have used SCCS in three ways: plain, with shell scripts, and
with sccs(1).  I prefer Allman's sccs, though primarily for one
reason alone: it does a much better job than the shell scripts I
wrote at hiding the {s,p}. files in a subdirectory.  Its added
functionality, including its ability to be made set-{u,g}id, and
its extensibility courtesy its availability in source form, are of
secondary importance to me.

If you don't mind having all those extra files in the working
directory, bare-bones SCCS will function quite well and provide a
powerful source management environment.  In fact, make(1) will like
this arrangement as well.

Now, if only SCCS (or sccs) supported symbolic version naming for
multiple modules.  This is RCS's (and VCS's) on redeeming feature.
-- 
						Greg A. Woods.

woods@{{tmsoft,utgpu,gate,ontmoh}.UUCP,utorgpu.BITNET,gpu.utcs.Toronto.EDU}
+1-416-443-1734 [h],	+1-416-595-5425 [w]		Toronto, Ontario, Canada