stever@tree.UUCP (Steve Rudek) (05/03/89)
"As it turns out, SCCS was designed to have a user interface wrapper put
around it, and would be FAIRLY PAINFUL to use without such an interface.
For the purposes of this discussion, we assume the presence of the
interface known simply as sccs, a public domain interface distributed
with SunOS and BSD systems."
--Eric Allman, UNIX_Review, March 1989, page 72
Few things in this world irritate me more than a good idea implemented in a
brain-dead fashion. SCCS, as distributed by AT&T with no front end, is
unfinished software which is generally more trouble to use than it is worth.
I see stupid syntax requirements like:
"admin -ilang s.lang
All SCCS files *must* have names that begin with 's.', hence, s.lang"
--AT&T Unix System V.2 manual
And I start thinking ugly thoughts like "maybe the author of sccs used LSD
on the job?" I mean, If all sccs files "*must*" start with "s." then why
*must* I type in "lang s.lang?" Is it unreasonable to expect admin to deduce
this?
I could rant about other stupid aspects of the implementation but what's
the point? I need to access the functionality of sccs without having
to deal with the ugliness of the implementation. This system has sh, ksh,
csh and perl. I'd greatly appreciate it if someone would send me a friendly
front end to sccs and save me the trouble of having to write my own from
scratch.
--
----------
Steve Rudek {ucbvax!ucdavis!csusac OR ames!pacbell!sactoh0} !tree!steverraulin@tdl.UUCP (Raulin Olivera) (05/04/89)
In article <297@tree.UUCP>, stever@tree.UUCP (Steve Rudek) writes: > > "As it turns out, SCCS was designed to have a user interface wrapper put > around it, and would be FAIRLY PAINFUL to use without such an interface. > For the purposes of this discussion, we assume the presence of the > interface known simply as sccs, a public domain interface distributed > with SunOS and BSD systems." > --Eric Allman, UNIX_Review, March 1989, page 72 > > Few things in this world irritate me more than a good idea implemented in a > brain-dead fashion. SCCS, as distributed by AT&T with no front end, is > unfinished software which is generally more trouble to use than it is worth. > I see stupid syntax requirements like: > > "admin -ilang s.lang > All SCCS files *must* have names that begin with 's.', hence, s.lang" > --AT&T Unix System V.2 manual > > And I start thinking ugly thoughts like "maybe the author of sccs used LSD > on the job?" I mean, If all sccs files "*must*" start with "s." then why > *must* I type in "lang s.lang?" Is it unreasonable to expect admin to deduce[ > this? > > I could rant about other stupid aspects of the implementation but what's > the point? I need to access the functionality of sccs without having > to deal with the ugliness of the implementation. This system has sh, ksh, > csh and perl. I'd greatly appreciate it if someone would send me a friendly > front end to sccs and save me the trouble of having to write my own from > scratch. How hard is it to use the 3 most routine commands of sccs which are admin (to create the archive), get (to extract versions from the archive), and delta (to return a version to the archive)? I must admit that I have not used sccs to its full capability but I have done some significant programming projects with it. It sure beats the heck out of making filename.old's and forgetting which version it was. Especially if you have many files in your application. As far as a front end goes it would be very simple to make a shell script to handle the basics. To use the example cited above with the admin command and the enforced "s.": # sccs.sh admin -i$1 s.$1 <EOF> Command line % sccs.sh lang You could even have the shell script remove the lang file if you felt that confident that the archive had been properly established. And you could add fancy prompts to ask you if you wanted to remove it etc. Many Unix commands seem to vary in their state of what I might consider to be completeness. However, I believe that this is a symptom of having many contributors to a robust operating system. I find the advantages far outweigh the disadvantages. =Ralo->
mark@motcsd.UUCP (Mark Jeghers) (05/06/89)
In article <123@tdl.UUCP> raulin@tdl.UUCP (Raulin Olivera) writes: >In article <297@tree.UUCP>, stever@tree.UUCP (Steve Rudek) writes: >> >> "As it turns out, SCCS was designed to have a user interface wrapper put >> around it, and would be FAIRLY PAINFUL to use without such an interface. Oh, well okay...*ahem*...ouch ouch ouch. Oh what pain. Oh what pain. I hope that was convincing... :-) >> Few things in this world irritate me more than a good idea implemented in a >> brain-dead fashion. SCCS, as distributed by AT&T with no front end, is >> unfinished software which is generally more trouble to use than it is worth. 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. >> I see stupid syntax requirements like: >> "admin -ilang s.lang [ delirium over admin(1) usage deleted ] >> I could rant about other stupid aspects of the implementation but what's >> the point? Indeed. >> I need to access the functionality of sccs without having >> to deal with the ugliness of the implementation. Poor baby. It is pretty hard to use without Bert and Ernie dancing on the screen. A few *tiny* scripts can cover whatever you don't like about the command usages. Really, now, isn't this whole thing being overblown just a *little* ?? >How hard is it to use the 3 most routine commands of sccs which are >admin (to create the archive), get (to extract versions from the >archive), and delta (to return a version to the archive)? Like I said above, "ouch ouch ouch. Oh what pain." :-) >I find the advantages far outweigh the disadvantages. Speaking of advantages: - it works - it is uniform over a lot of machines (i.e. a UNIX standard of sorts) - it works with make(1) nicely -- Mark Jeghers "I'm the King of Eight and I'm here to state Motorola Computer Systems that everything here has to total eight! ....uunet!apple!motcsd!greek!mark The gaurds, for instance, at my gate ...hplabs!hpda!/ must always total exactly eight!"
guy@auspex.auspex.com (Guy Harris) (05/06/89)
>How hard is it to use the 3 most routine commands of sccs which are >admin (to create the archive), get (to extract versions from the >archive), and delta (to return a version to the archive)? Harder than it is to use then with the "sccs" front end program from BSD, which has the Berkeley "certified 100% AT&T-free" copyright notice on it, and is thus freely distributable.... >I must admit that I have not used sccs to its full capability but I have >done some significant programming projects with it. It sure beats >the heck out of making filename.old's and forgetting which version >it was. He didn't say "SCCS is worse than having nothing"; we all realize that source control systems are helpful, it's just that the user interface to SCCS isn't as good as it could be.
guy@auspex.auspex.com (Guy Harris) (05/07/89)
>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.
woods@tmsoft.uucp (Greg Woods) (05/08/89)
In article <1580@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > > [Likely article <354@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
tjo@Fulcrum.BT.CO.UK (Tim Oldham) (05/12/89)
In article <1580@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>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". Hear hear. 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! Apart from anything else (directory clutter, making it harder to write shell scripts 'cos matching *.c doesn't work any more, etc.), SCCS ought to be transparent. And what's happened to fix? Wow, so I can cdc to change the delta commentary, but that's not a great deal of help. I always feel guilty using chmod, vi and admin -z around s-files, and quite right too. If anyone can tell me how to get sccs to use an SCCS directory, I'd be *extremely* grateful. Anyone have a fix program for sysV they can distribute? Tim. -- Tim Oldham ...!mcvax!ukc!axion!fulcrum!tjo or tjo@fulcrum.bt.co.uk #include <stdisclaim> Why have coffee, when caffeine tastes this good?
ka@june.cs.washington.edu (Kenneth Almquist) (05/14/89)
tjo@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! It keeps them where ever you put them. > If anyone can tell me how to get sccs to use an SCCS directory, I'd > be *extremely* grateful. 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 The s-file is in the sccs directory because in the UNIX file naming scheme, a name like "dir/file" means that the file "file" is in the directory "dir". The p-file is in the sccs directory because SCCS commands place the p-file in the same directory as the s-file. The g-file (file.c) is placed in the current directory because SCCS commands always place the g-file in the current directory. > And what's happened to fix? Wow, so I can cdc > to change the delta commentary, but that's not a great deal of help. > I always feel guilty using chmod, vi and admin -z around s-files, > and quite right too. You aren't supposed to make mistakes. :-) Seriously, SCCS is intended to keep a record of all the changes to a file. You aren't supposed to mess with this history. There are a few exceptions to this. You can remove the last delta created (with rmdel) if there is a mistake in it. This doesn't violate the SCCS philosophy because you can get the same effect by simply being less hasty in running "delta". (Personally, though, I wouldn't bother with rmdel. Just create a new delta on top of the old one.) The admin command allows you to change various attributes of SCCS files. Finally, if you want to save disk space you can use "comb" to really old versions which you are sure you will never want to return to. This violates the SCCS philosophy, and is a concession to the reality that disk space is not infinite. (My own view is that the price of disk space is likely to fall faster than your SCCS files grow, so I wouldn't bother with "comb".) The only things that I can think of that SCCS does not allow you to do without editing the SCCS files by hand are: 1) Changing the text of deltas. As I explained above, since the whole purpose of SCCS is to keep an unchanged record, you don't want to do this (except possibly for the most recent delta, and even then you can simply create another delta). 2) Change the release numbers. This *is* a valid reason for editing the SCCS files if you need to do it, but in general you can avoid the need for renumbering. In short, the four commands admin, get, delta, and prs (*without* the -z option to admin) let you do just about anything you need to. If you want to do something that these commands won't let you do, perhaps you should think a little more about what you are trying to accomplish. Kenneth Almquist
tjo@Fulcrum.BT.CO.UK (Tim Oldham) (05/16/89)
In article <8218@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: >tjo@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@fulcrum.bt.co.uk or ...!mcvax!ukc!axion!fulcrum!tjo #include <stdisclaim> Why have coffee, when caffeine tastes this good?
woods@eci386.uucp (Greg Woods) (05/21/89)
In article <167@cat.Fulcrum.BT.CO.UK> tjo@fulcrum.bt.co.uk (Tim Oldham) writes: > In article <8218@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: > >tjo@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. This is a non-issue. Eric Allman's SCCS front-end "sccs" is available on the BSD4.3-tahoe public tape (i.e. UUNET, etc.). This front-end not only hides your files, but adds other significant functionality. -- Greg A. Woods woods@{{utgpu,eci386,ontmoh,tmsoft}.UUCP,gpu.utcs.UToronto.CA,utorgpu.BITNET} +1-416-443-1734 [h] +1-416-595-5425 [w] Toronto, Ontario CANADA
mack@kurz-ai.UUCP (Ed Mackenty) (05/30/89)
In article <167@cat.Fulcrum.BT.CO.UK> tjo@fulcrum.bt.co.uk (Tim Oldham) writes: >In article <8218@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: >>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 >> ... > >Yuck. I prefer the idea of SCCS doing this stuff for you. ... I agree, the SCCS interface should hide as much as it can from the user. My model of a code control system is one in which the user knows nothing about how the system works. They use a few commands with almost no options, and always refer to g-file names (i.e., their own name for the file, not SCCS's name). At this site, we implemented a layer on top of SCCS that does this (and more). It also addresses the problems of many users working on the same set of sources without interfering with each other. While it works well for us, I would not wish it on anyone else. It has evolved over a period of years, depends heavily on our local environment, and seems to require at least one guru to administer it and help users understand it. Maybe if we wrote some documentation... :-). I haven't been following this discussion for very long (I just fixed our new link, again), but I'd like to change the direction of this duscussion from SCCS bashing (which is in itself a worthwhile pursuit) to the subject of source code control in general. I've talked to several local programmers from other companies to get ideas to put into our system and they all say the same thing: "Code control? Well, we have these diskettes with today's version of the product on them..." Does anyone out there uses a system like SCCS or RCS in a product development effort? What sorts of problems have you run into? What solutions do you have? I could write several pages about what we've encountered here, but this message is too long already. If there is any interest, I'll write another message. - MacK (developing programs for program development). -- - MacK Edmund R. MacKenty UUCP: ...{uunet,rutgers,ames}!harvard!talcott!kurz-ai!mack DISCLAIMER: But... I was off planet that week! DEAD QUOTE: "And the politicians Throwing Stones."
mack@kurz-ai.UUCP (Ed Mackenty) (05/30/89)
In article <167@cat.Fulcrum.BT.CO.UK> tjo@fulcrum.bt.co.uk (Tim Oldham) writes: >In article <8218@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: >>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 >> ... > >Yuck. I prefer the idea of SCCS doing this stuff for you. ... I agree, the SCCS interface should hide as much as it can from the user. My model of a code control system is one in which the user knows nothing about how the system works. They use a few commands with almost no options, and always refer to g-file names (i.e., their own name for the file, not SCCS's name). At this site, we implemented a layer on top of SCCS that does this (and more). It also addresses the problems of many users working on the same set of sources without interfering with each other. While it works well for us, I would not wish it on anyone else. It has evolved over a period of years, depends heavily on our local environment, and seems to require at least one guru to administer it and help users understand it. Maybe if we wrote some documentation... :-). I haven't been following this discussion for very long (I just fixed our news link, again), but I'd like to create a branch of this discussion on to the subject of source code control in general. I've talked to several local programmers from other companies to get ideas to put into our system and they all say the same thing: "Code control? Well, we have these diskettes with today's version of the product on them..." Does anyone out there use a system like SCCS or RCS in a product development effort? What sorts of problems have you run into? What solutions do you have? I could write several pages about what we've encountered here, but this message is too long already. If there is any interest, I'll write another message. - MacK (developing programs for program development). -- - MacK Edmund R. MacKenty UUCP: kurz-ai!mack@talcott.harvard.edu or: ...{uunet,rutgers,ames}!harvard!talcott!kurz-ai!mack DISCLAIMER: But... I was off planet that week! DEAD QUOTE: "And the politicians Throwing Stones."