naked SCCS really SCCS!

[Tim Oldham]

In article <8218 at june.cs.washington.edu> ka at june.cs.washington.edu (Kenneth Almquist) writes:
>tjo at Fulcrum.BT.CO.UK (Tim Oldham) writes:
>> But the trouble with sysV sccs is the brain-damaged way it
>> keeps all the s- and p-files in the directory you're working in. Crazy!

>OK, let's say you want to keep all your "s." and "p." files in a
>subdirectory named sccs.  Say
>	mkdir sccs		# create the directory
>	admin -n sccs/s.file.c	# create an SCCS file
>	get -e sccs/s.file.c	# get the file for editing
>	emacs file.c		# edit the file
>	delta sccs/s.file.c	# install changes

Yuck. I prefer the idea of SCCS doing this stuff for you. As far as I'm
concerned, I shouldn't have to worry about how to store the previous
versions - all this kind of stuff should be transparent in any UI worth
its salt. I shouldn't have to think about how SCCS actually goes about
its business, where things are kept, or even what an s- or p-file is.
The SCCS commands should do this for me. It's the ends I'm interested in,
not the means.  Abstraction and transparency and all that good stuff,
which sysV SCCS doesn't seem to have heard of.

>> And what's happened to fix? 
>
>You aren't supposed to make mistakes. :-)  Seriously, SCCS is intended
>to keep a record of all the changes to a file. 

Hmm, yes, but pragmatically you do make incomplete deltas, which then
just confuse the picture later on if you make a new delta on top. fix
can be useful when you just do something plain stupid (what, me? :-),
I maintain.  But agreed, this is a slightly more dicey point than
the UI one.

>	Kenneth Almquist

	Tim.

-- 
Tim Oldham      tjo at fulcrum.bt.co.uk  or  ...!mcvax!ukc!axion!fulcrum!tjo
#include	<stdisclaim>
Why have coffee, when caffeine tastes this good?