SCCS vs RCS
Matt
My question is what's the difference between SCCS and RCS. I'm the manager of a group project that our course is running and I need to figure out which is the best one to use.
Thanks in advance for any help/replies.
Regards
Matthew Aldridge
Glen Wiley
: Being a lowely student at a British University trying to figure out version control software.
: My question is what's the difference between SCCS and RCS. I'm the manager of a group project that our course is running and I need to figure out which is the best one to use.
As a full-time user of both SCCS and RCS I can give you my opinion. SCCS
is a bottom line approach to version control, and RCS without enhancements
isn't much better from a useability perspective. I find that SCCS as it
ships with the Sparworks compiler coupled with Teamware (code manager)
is barely adequate. Without Teamware to coordinate project wide source
control it would be a disaster.
RCS is more powerful than SCCS, but can be difficult to use - however
when used via CVS as a front-end it is one of the best version control
solutions you will find.
I have worked with MKS Source Integrity (an RCS derivative) and
Clear Case (monstrously expensive) and I find that CVS is probably
the easiest to get going in the shortest amount of time. I recommend
that you read the thorough documentation that accompanies the
CVS distribution - and make your team members read it as well.
The fact is that most of the large scale development efforts in the
open source community are using CVS to manage their products (this
is an ounofficial observation :)
--
Glen Wiley
Senior Software Engineer gwi...@wwa.com
3Com - Carrier Systems R&D
"UNIX _IS_ user friendly, its just picky about who its friends are."
*******************************************************************
* Any statements or opinions expressed by me are mine exclusively *
* and have nothing whatsoever to do with my employer... *
*******************************************************************
Jeremy Isserlis
the latest version of your source, with the diff instructions to reconstruct earlier versions. SCCS files hold the first version, with the diff instructions to construct the later
versions. This suggests that RCS "co" should be quicker than "sccs get" for the current file version; but I doubt that you would notice. RCS does allow the symbolic naming of a
"frozen"
version level as well as the numeric version e.g. call your release "BL2" instead of "2.1".
SCCS tends to assume that large projects will use script or programme wrappers; but using some of the features under " sccs admin" it can provide very sophisticated change control.
You should know SCCS: in my experience it comes as standard on every commercial UNIX, so it is always there. RCS is excellent and free; some commercial UNIX include it (e.g.
HP-UX), lots of others have it as free, additionally installable software. For the rest, it's on the net somewhere. Check your version carefully. At one time SCCS did sensible
things if you tried to handle a binary file whereas RCS resulted in an empty file! RCS has been mended in later versions. Also, older RCS versions used a lock in the user's
working directory, so if two users were working from the same RCS directory, checking out files (locked) into different directories (e.g. each had a symbolic link to the RCS
directory), the two users would not know of each other's locks. Again, this has probably been fixed by putting the locks in the RCS directory. I got caught, as did others, by both
of these some years ago.
Some equivalents at normal command line level:
RCS SCCS
co [-u] sccs get
co -l sccs edit
ci sccs delta
ci -u sccs delget
ci -l sccs deledit
rlog sccs prs
rcsdiff sccsdiffs (I may have got the commands wrong
for these: they compare vesions).
Both expand key words in source files to embed change dates, authors, module names
etc.. RCS includes the extra one, $Log$, to embed a string (as in a change history); the value of this depends upon your local documentation conventions.
Personally, I always use version control, SCCS or RCS for every document, shell script or programme that I write unless it really is a one off, throw-away test. Because both keep
only one full version of the source plus the instructions to restore each version, they are both more economical of space than multiple copies of source versions.
There are X versions of SCCS, probably of RCS too, showing pretty trees etc.. I have not used CVS; I used to hear good things about it; more recently I read some tirade
against it.
Whatever you do, use a source code control system, preferably a widely available and simple one. Both RCS and SCCS allow version locking, branches and user access control.
Finally, RCS is perhaps the more widely used e.g. the X project. Either way, you will probably want to wrap some functions in shell script, e.g. an RCS command to create
something like RCSfreeze to lock a set of code under a symbolic release name.
Remember that users can have individual build environments while sharing RCS sources by creating "shadow" build trees in which each directory contains a symbolic link to the
appropriate project RCS/SCCS directory. Checking files out will then put them in the user's own directory, checking them in puts them back into the project source code control and
so makes the changed (one hopes, tested and good) source available to all and enables a global build by the project build manager.
Jeremy Isserlis
Jeremy Isserlis
Your RCS should include a couple of papers by Walter Tichy and others. For both
SCCS and RCS starting is very simple:
cd <working directory>
mkdir SCCS or mkdir RCS
for SCCS, the easiest way is "sccs create *.[ch]" or "sccs create myfile.txt" etc..
Alternatively, using sccs admin and assuming you have got several files,
for i in <file list>; do
sccs admin -i$i $i
done
For RCS, just "ci -u <file>"
To get your working copies, co -l <file> or sccs edit <file> for RCS and SCCS
respectively. See the man pages. It really is that easy.
Oh, to get back an old version: sccs get -r<rev. no.> <filename> or
co -r<rev. no.> <filename> for SCCS and RCS respectively.
Did I say it? Read the man pages, man rcs, man sccs ....
Matt wrote:
> In article <71n0qp$jvh$1...@hirame.wwa.com>,
> Glen Wiley <gwi...@tako.wwa.com> writes:
>
> > As a full-time user of both SCCS and RCS I can give you my opinion. SCCS
> > is a bottom line approach to version control, and RCS without enhancements
> > isn't much better from a useability perspective. I find that SCCS as it
> > ships with the Sparworks compiler coupled with Teamware (code manager)
> > is barely adequate. Without Teamware to coordinate project wide source
> > control it would be a disaster.
>
> Being a student we are provided with Solaris 5.5 on Unix IPX's or Sparc5's. Therefore we're stuck with a basic install which only seems to have RCS and SCCS. During my research SCCS is by way the most documented of the two.
>
> To clarify things my group consists of 5 other people including myself. The group project will involve a fair bit of source code and I just want to have a bit of version control to avoid problems during development. We a going to be developing our code in Ada95 and editing using Emacs or Xemacs.
>
> Can you suggest where I could get hold of documentation covering RCS as I've found loads on SCCS. When I say documentation I mean information that is readable and understandable to a student thats fairly new to the Unix OS (i.e only have 2-3 years experience with it at a low level).
>
> Regards
>
> Matthew Aldridge
> --The eternally grateful for help
Jeremy Isserlis
Your RCS should include a couple of papers by Walter Tichy and others. For both
SCCS and RCS starting is very simple:
cd <working directory>
mkdir SCCS or mkdir RCS
Note, this is at its most basic; think about symbolic links to communal RCS/SCCS directories so that developers have copies in private development directories to avoid tripping over each other while keeping a common source pool.
For SCCS, the easiest way to put files under SCCS control is "sccs create *.[ch]" or "sccs create myfile.txt" etc..
Alternatively, using sccs admin and assuming you have got several files,
for i in <file list>; do
sccs admin -i$i $i
done
Then, sccs get or sccs edit fetch read-only or locked for writing copies. sccs delta
puts a copy back (also, sccs delget, sccs deledit to do the delta and get or edit in one go).
Jeremy Isserlis
Jeremy Isserlis
Matt
Glen Wiley
<snip>
: Can you suggest where I could get hold of documentation covering RCS as I've found loads on SCCS. When I say documentation I mean information that is readable and understandable to a student thats fairly new to the Unix OS (i.e only have 2-3 years experience with it at a low level).
http://sunsite.unc.edu/LDP/HOWTO/mini/RCS.html
The Linux Documentation Project covers a lot of ground for just about
every facet of introductory UNIX development. Most of the docs are
available in HTML, text, ps, dvi...
Marcus Thiessel
> Can you suggest where I could get hold of documentation covering RCS
> as I've found loads on SCCS. When I say documentation I mean
> information that is readable and understandable to a student thats
> fairly new to the Unix OS (i.e only have 2-3 years experience with
> it at a low level).
There's a book from O'Reilly covering SCCS and RCS and you find some
docs within the distribution of RCS (or even pointer to).
http://www.loria.fr/~molli/cvs-index.html will cover CVS.
--Marcus
Matt
<Jeremy....@compaq.com> wrote:
(major snip)
> Whatever you do, use a source code control system, preferably a widely available and simple one.
(other major snip)
Could you expand on your reasons for this? I'd like to hear your
point of view.
On the project I'm currently working on, the general consensus (not
necessarily my opinion) is that a full-featured, complex, and
expensive source code control system that is not necessarily
mainstream nor easy to come by is the way to go. RCS is the one that
I have experience with but I'm being told that we want to use this
other product (one that will remain unnamed herein). So I'm wondering
what your reasons are for saying that it is better to use a widely
available and simple source code control system.
------
Remove "anti.spam" to respond via email.
Matt
matt...@anti.spam.us.ibm.com
------
- These views are my own, not necessarily those of my company.
Paul D. Smith
m> Being a student we are provided with Solaris 5.5 on Unix IPX's or
m> Sparc5's. Therefore we're stuck with a basic install which only
m> seems to have RCS and SCCS.
Why?
RCS and the more complete SCM system CVS which is built on top of it is
free software; you can get the source and compile it yourself quite
easily.
No need to be "stuck with a basic install" in this day and age.
--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
Paul D. Smith
ji> I've used both extensively. RCS and SCCS are very similar. The
ji> RCS files consist of the latest version of your source, with the
ji> diff instructions to reconstruct earlier versions. SCCS files
ji> hold the first version, with the diff instructions to construct
ji> the later versions.
This is a myth. Yes, RCS uses reverse-deltas, but SCCS _doesn't_ use
forward deltas; it uses something called "interleaved deltas".
Essentially, RCS files are faster to check out on the leaves but get
slower as you go further back in history, while SCCS checkouts take
more-or-less uniform time regardless of how old the version is.
However, as you point out, the time differences are so small I can't
imagine anyone picking one or the other based on this. One possible
feature of RCS is that the latest version of the file is always
available as plaintext in the RCS master file... surrounded by lots of
goop, but completely available. This makes it possible to recover from
some kind of devastating corruption of the history or something much
more easily and at least get the latest version out. In SCCS this is
much, much harder or even impossible since there's no one complete
copy.
Again, I can't imagine someone choosing one over the other based on
this, though... you are all careful to make backups of your master
files, right? Right!!!!
Some things you _should_ consider: SCCS is proprietary code and so won't
appear on "free" systems like Linux or FreeBSD or whatever. And I don't
think there's a port to Windows. Also, you're stuck with whatever
version of SCCS your vendor provides; you can't update to a newer
version.
RCS (and CVS) is free software and ported to every version of UNIX under
the sun, plus DOS, Windows, VMS, and Mac (I think), and maybe others.
ji> RCS is excellent and free; some commercial UNIX include it (e.g.
ji> HP-UX), lots of others have it as free, additionally installable
ji> software.
Note that almost all vendor-shipped versions are _so_ old you shouldn't
even bother. Go get the latest from ftp://ftp.gnu.org/pub/gnu/ or its
mirrors.
In particular, much older versions of RCS are _known_ to not be Y2K
compliant!!
Rest assured that you can use older RCS master files even with the new
versions of RCS, though.
ji> For the rest, it's on the net somewhere. Check your version
ji> carefully. At one time SCCS did sensible things if you tried to
ji> handle a binary file whereas RCS resulted in an empty file!
AFAIK only pretty recent SCCS versions do anything with binary files.
And while older RCS files didn't like binary files, all the versions
I've used warned you about them, rather than deleting your files.
Really, binary file support in RCS is a function of the diff you're
using, since that's what RCS uses to implement versioning. Most vendor
diff's don't handle binary files. You should get GNU diff, which does,
and use that with RCS.
ji> Also, older RCS versions used a lock in the user's working
ji> directory, so if two users were working from the same RCS
ji> directory, checking out files (locked) into different directories
ji> (e.g. each had a symbolic link to the RCS directory), the two
ji> users would not know of each other's locks. Again, this has
ji> probably been fixed by putting the locks in the RCS directory.
Are you sure you're not thinking of SCCS? Every version of RCS I've
ever heard of, all the way back to 1.0 I think, stored lock information
in the master file itself. It's always been a hallmark of RCS that the
master file was complete in itself; for example you can rename or move a
file around in the source code version by merely renaming or moving the
master file (the name of the file isn't stored anywhere inside the
master file itself, so there's no need to for other processing).
It's SCCS, I think, that creates a separate "lock file".
ji> There are X versions of SCCS, probably of RCS too, showing
ji> pretty trees etc.. I have not used CVS; I used to hear good
ji> things about it; more recently I read some tirade against it.
CVS is great. And it now has some incredible features such as remote
servers so you can checkout, etc. over the network, there's a webcvs so
you can browse your source tree via the web, etc. etc.
T.E.Dickey
> Essentially, RCS files are faster to check out on the leaves but get
> slower as you go further back in history, while SCCS checkouts take
> more-or-less uniform time regardless of how old the version is.
maybe (I did some timing tests back in 1988, and did have to agree with Tichy)
> However, as you point out, the time differences are so small I can't
> imagine anyone picking one or the other based on this. One possible
> feature of RCS is that the latest version of the file is always
> available as plaintext in the RCS master file... surrounded by lots of
> goop, but completely available. This makes it possible to recover from
> some kind of devastating corruption of the history or something much
> more easily and at least get the latest version out. In SCCS this is
> much, much harder or even impossible since there's no one complete
> copy.
On the other hand, SCCS files are pretty readable, if you choose, to see
when a change was made. For RCS files, I have to do a lot of diffs.
(I use both, of course).
> Again, I can't imagine someone choosing one over the other based on
> this, though... you are all careful to make backups of your master
> files, right? Right!!!!
> Some things you _should_ consider: SCCS is proprietary code and so won't
> appear on "free" systems like Linux or FreeBSD or whatever. And I don't
> think there's a port to Windows. Also, you're stuck with whatever
> version of SCCS your vendor provides; you can't update to a newer
> version.
there's a couple of free clones of SCCS.
there's also a couple of proprietary clones of RCS.
(use whichever tool makes sense)
--
Thomas E. Dickey
dic...@clark.net
http://www.clark.net/pub/dickey
Glen Wiley
<snip>
: On the project I'm currently working on, the general consensus (not
: necessarily my opinion) is that a full-featured, complex, and
: expensive source code control system that is not necessarily
: mainstream nor easy to come by is the way to go. RCS is the one that
: I have experience with but I'm being told that we want to use this
: other product (one that will remain unnamed herein). So I'm wondering
: what your reasons are for saying that it is better to use a widely
: available and simple source code control system.
<snip>
As far as widely available goes..
When new peple are added to your team they can be more easily
assimilated if they are already familiar with the tools.
As far as simple goes, consider: how much time do you want to fool
around with source control when your purpose for existence is to
produce software? In my experience, when it comes to version
control engineers will learn what is minimally necessary to get
the job done (if even that much) and then stop trying to learn
anything further about the tool. They will appreciate as short
alearning curve as possible.
Paul D. Smith
ted> On the other hand, SCCS files are pretty readable, if you choose,
ted> to see when a change was made. For RCS files, I have to do a lot
ted> of diffs.
True. Actually, doesn't SCCS provide a command to do this?
ted> there's a couple of free clones of SCCS.
These are all fairly recent and, in my (limited) experience, not very
full-featured. In fact, I believe the help for one of them said the
best thing you can do with it is to use it with sccs2rcs :)
Philip Brown
>If RCS and SCCS are installed, read the man pages e.g."man rcs" and go from there.
>Your RCS should include a couple of papers by Walter Tichy and others. For both
>SCCS and RCS starting is very simple:
>cd <working directory>
>mkdir SCCS or mkdir RCS
you don't have to do
"mkdir SCCS"
sccs create filename.whatever
will do it for you.
--
[trim the no-bots from my address to reply to me by email!]
--------------------------------------------------
"initiating.. 'getting the hell out of here' maneouver" - Lennier, babylon5
Christopher Green
>
> Being a lowely student at a British University trying to figure out version control software.
>
> My question is what's the difference between SCCS and RCS. I'm the manager of a group project that our course is running and I need to figure out which is the best one to use.
>
>
> Regards
>
> Matthew Aldridge
One point I haven't seen mentioned in the other replies is that
RCS is easier to use with Make (the reason being that RCS file
names use a suffix convention, while SCCS file names use a pre-
fix). This makes it much easier to write suffix rules for Make
when RCS, rather than SCCS, is used.
--
Chris Green
Advanced Technology Center
Laguna Hills, California
Philip Brown
>
>One point I haven't seen mentioned in the other replies is that
>RCS is easier to use with Make (the reason being that RCS file
>names use a suffix convention, while SCCS file names use a pre-
>fix). This makes it much easier to write suffix rules for Make
>when RCS, rather than SCCS, is used.
On the other hand, under Solaris [and presumably some other UNIXen], you don't
have to write rules, because it automatically understands SCCS, and tries to
pull your source out of the SCCS directory, if the source doesn't exist, but
SCCS dir does exist.
But if you really cared, you could look at the rules solaris uses, and learn
from them. If you have access to a solaris box, they are in
/usr/share/lib/make/
T.E.Dickey
> ted> On the other hand, SCCS files are pretty readable, if you choose,
> ted> to see when a change was made. For RCS files, I have to do a lot
> ted> of diffs.
> True. Actually, doesn't SCCS provide a command to do this?
doing diffs one-by-one is very cumbersome.
I have frequent need to research _when_ a change was made; for this purpose
I use a script that checks out all of the versions (many of the files go
back for hundreds of deltas) so that I can grep for the change and
determine when it was made. With SCCS I can simply read the change in
context (the system we use at work is SCCS-based, while most of my own
projects are RCS-based).
The SCCS wrapper has a diff command, true. but I'm not talking about that.
> ted> there's a couple of free clones of SCCS.
> These are all fairly recent and, in my (limited) experience, not very
> full-featured. In fact, I believe the help for one of them said the
> best thing you can do with it is to use it with sccs2rcs :)
sccs2rcs isn't full-featured either.
T.E.Dickey
> One point I haven't seen mentioned in the other replies is that
> RCS is easier to use with Make (the reason being that RCS file
> names use a suffix convention, while SCCS file names use a pre-
> fix). This makes it much easier to write suffix rules for Make
> when RCS, rather than SCCS, is used.
That's because it's not true. There are a number of implementations
of 'make', both ways that special-case the RCS and SCCS files.
anyway, I wouldn't use it (it creates more problems than it ever solves).
Klaus-Georg Adams
> To clarify things my group consists of 5 other people including
> myself. The group project will involve a fair bit of source code
> and I just want to have a bit of version control to avoid problems
> during development. We a going to be developing our code in Ada95
> and editing using Emacs or Xemacs.
IMO you will be well advised to take a look at CVS. It solves a lot of
problems which are not solved in RCS (deleting files, renaming files,
etc.) As an extra bonus you get remote access to the repository.
And if you use emacs, the difference in handling CVS, RCS or SCCS are
moot, because there is vc.el in emacs (a frontend which unifies the
handling of the Version control systems). Search vor `Version Control'
in Emacs Info, and you'll see.
-- kga
-------------------------------------------------------------------------
Klaus-Georg Adams Email: Klaus-Ge...@chemie.uni-karlsruhe.de
Institut f. Anorg. Chemie, Lehrstuhl II Tel: 49(0)721 608 3485
Universität Karlsruhe, D-76128 Karlsruhe
-------------------------------------------------------------------------
Paul D. Smith
ted> Paul D. Smith <psm...@baynetworks.com> wrote:
>> %% "T.E.Dickey" <dic...@shell.clark.net> writes:
ted> On the other hand, SCCS files are pretty readable, if you choose,
ted> to see when a change was made.
>> True. Actually, doesn't SCCS provide a command to do this?
ted> The SCCS wrapper has a diff command, true. but I'm not talking
ted> about that.
No, I know, I wasn't either. I thought there was some SCCS command that
would show you what version (last?) changed one/each line of the file.
Maybe I'm imagining it.
Dave Mikesell
I just built a system on top of RCS. I chose RCS over SCCS mainly because RCS allows for the tagging of a group of files with a symbolic name, which I use to represent a "release"
of a product. BTW, if you plan to do something similar, I would recommend the O'Reilly book _Applying_RCS_and_SCCS_, by Bolinger and Bronson. It compares the systems and discusses
how to build a front end. FWIW, they prefer RCS, too.
--
Dave Mikesell
Christopher Green
>
> On 04 Nov 1998 16:51:24 PST, cjrg...@concentric.net wrote:
> >
> >One point I haven't seen mentioned in the other replies is that
> >RCS is easier to use with Make (the reason being that RCS file
> >names use a suffix convention, while SCCS file names use a pre-
> >fix). This makes it much easier to write suffix rules for Make
> >when RCS, rather than SCCS, is used.
>
> have to write rules, because it automatically understands SCCS, and tries to
> pull your source out of the SCCS directory, if the source doesn't exist, but
> SCCS dir does exist.
>
> But if you really cared, you could look at the rules solaris uses, and learn
> from them. If you have access to a solaris box, they are in
> /usr/share/lib/make/
>
> --
> [trim the no-bots from my address to reply to me by email!]
> --------------------------------------------------
> "initiating.. 'getting the hell out of here' maneouver" - Lennier, babylon5
Since all of the products I handle have to build and run on
6 or more different flavors of Unix, I don't really care that
Solaris Make has its own way of handling SCCS files. I need
something that works close to the same way on every platform
I maintain. RCS, GNU Emacs, and GNU Make do that seamlessly.
Christopher Green
>
> Christopher Green <cjrg...@concentric.net> wrote:
> > One point I haven't seen mentioned in the other replies is that
> > RCS is easier to use with Make (the reason being that RCS file
> > names use a suffix convention, while SCCS file names use a pre-
> > fix). This makes it much easier to write suffix rules for Make
> > when RCS, rather than SCCS, is used.
>
> of 'make', both ways that special-case the RCS and SCCS files.
>
> anyway, I wouldn't use it (it creates more problems than it ever solves).
>
> --
> Thomas E. Dickey
> dic...@clark.net
> http://www.clark.net/pub/dickey
No special case needed for RCS files; just write suffix rules.
SCCS files require a Make that has a kludge to handle rules
that involve file prefixes.
Since I maintain several products across 6 flavors of Unix
using RCS and GNU Make, and each product requires only one
makefile, I fail to see how this creates any problem at all.
Jeremy Isserlis
Simplicity: users will be more likely to understand it and use it; there is less to go wrong, and if
it does you have got more chance of recovery. It is also easily tailored to local needs using shell script
wrappers if wanted.
Widely available: From a selfish point of view: the most important portability issue is the user's
own skill set. It makes him more employable if his skills are in widely available tools and makes him
productive more quickly if his employer uses those tools. Also, none of us should expect to have a job
for life or use the same hardware, software and working environment for life; your next employer or
fellow workers may be unwilling to pay for or use special, expensive tools, even if they are available for
your next software/hardware environment. You may need to port the software to another platform that does
not support the expensive tool.
Re make: I think that all the makes that I have used have default rules to handle SCCS files and to
add rules for RCS is trivial.
Re locks: I met the problem of locks not being "centralised" by RCS several years ago and proved it
at the time; we edited the RCS source to fix it. I am sure that the scheme has changed considerably in
the eight or nine years since. I have not got the man pages to hand; but I think "sccs admin" allows the
sccs administrator to set the locking strategy for editing and to set up a list of named users allowed to
edit a file. I rather think RCS has something similar. Of course, multiple concurrent authors is rather
dangerous and I would suggest separate branches for such work. In any case, should the proverbial 'bus run
over the key developer who has, insanely, neglected to check in his masterpiece before leaving work, both
RCS and SCCS provide administrative ways to break (or set) the lock. Both systems have commands that tell
who is editing a file.
Anyway, nothing more useful to say other than I am always suspicious of the technical breadth of
experience (I mean number of projects, sites etc.) of anyone who wants to spend loads of money and time on
complex, proprietary source code control systems of limited availability. If one runs "what" etc. on most
UNIX standard libraries and commands I think that one will recognise RCS $Header$ strings in most of them
and SCCS versions in the rest; X11 was developed under RCS (+ imake) and if these are good enough for whole
operating systems over several years I am happy to follow that example. Hmph.
Matt wrote:
> On Tue, 3 Nov 1998 06:55:53 GMT, Jeremy Isserlis
> <Jeremy....@compaq.com> wrote:
>
> (major snip)
>
> > Whatever you do, use a source code control system, preferably a widely available and simple one.
>
> (other major snip)
>
> Could you expand on your reasons for this? I'd like to hear your
> point of view.
>
> On the project I'm currently working on, the general consensus (not
> necessarily my opinion) is that a full-featured, complex, and
> expensive source code control system that is not necessarily
> mainstream nor easy to come by is the way to go. RCS is the one that
> I have experience with but I'm being told that we want to use this
> other product (one that will remain unnamed herein). So I'm wondering
Tim Singletary
> version control software.
You're asking about SCCS vs RCS, but the better question is SCCS vs
CVS, and the answer is ``forget SCCS, use CVS''.
SCCS and RCS manage individual files; CVS manages directories. CVS
uses RCS to manage the individual files in those directories.
Managing directories is such a huge advantage that I wonder if anyone
still uses RCS without CVS!
There's another difference between SCCS and CVS. SCCS is based on the
notion that only one programmer at a time can edit a file; CVS allows
multiple programmers to edit the same file simultaneously. At first
glance the SCCS approach seems more correct. But, in practice, CVS
works better.
A common problem in groups that use SCCS is that someone else (who's
out sick today) is already `sccs edit'ing the file you want. And
they've had it for the past month and you know they haven't touched it
in weeks.
The fear with CVS is that every programmer is going to edit the same
file at the same time and clobber each other. In practice, this is
rare. When it does happen, CVS allows the first programmer to commit
his changes but forces the other programmers to resolve the conflicts
first.
tim
Casper H.S. Dik - Network Security Engineer
Tim Singletary <tsi...@talon.clark.net> writes:
>There's another difference between SCCS and CVS. SCCS is based on the
>notion that only one programmer at a time can edit a file; CVS allows
>multiple programmers to edit the same file simultaneously. At first
>glance the SCCS approach seems more correct. But, in practice, CVS
>works better.
You're comparing "SCCS" which is pretty much a bare-bones lower layer
like RCS wiuth CVS. That's not a fair comparison.
(E.g., Sun's teamware uses an approach on top of SCCS which does allow
multiple edits)
>A common problem in groups that use SCCS is that someone else (who's
>out sick today) is already `sccs edit'ing the file you want. And
>they've had it for the past month and you know they haven't touched it
>in weeks.
I don't think you should have a shared RCS/SCCS repository; rather
you need a system on top of it (like CVS for RCS or teamware for
SCCS)
>The fear with CVS is that every programmer is going to edit the same
>file at the same time and clobber each other. In practice, this is
>rare. When it does happen, CVS allows the first programmer to commit
>his changes but forces the other programmers to resolve the conflicts
>first.
As it should be.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Ross Ridge
>ever heard of, all the way back to 1.0 I think, stored lock information
>in the master file itself.
RCS creates a lock file to prevent simultaneous updates of the
master file. This is just a temporary file and has nothing
to do with revision locks.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/
db //
Ross Ridge
>Since all of the products I handle have to build and run on
>6 or more different flavors of Unix, I don't really care that
>Solaris Make has its own way of handling SCCS files. I need
>something that works close to the same way on every platform
>I maintain. RCS, GNU Emacs, and GNU Make do that seamlessly.
So do SCCS, GNU Emacs and GNU Make.
Ross Ridge
> there's a couple of free clones of SCCS.
Paul D. Smith <psm...@baynetworks.com> wrote:
>These are all fairly recent and, in my (limited) experience, not very
>full-featured.
Hmm... mine is almost five years old now, and implements most everything
from the original SCCS.
>In fact, I believe the help for one of them said the best thing you
>can do with it is to use it with sccs2rcs :)
You must be talking about CSSC. I don't know why the maintainer
bothered GNU'izing my code (I hear it's even been changed to use the
GNU coding standard. *shudder*), if he detests SCCS.
Geoff Clare
> I thought there was some SCCS command that
>would show you what version (last?) changed one/each line of the file.
>Maybe I'm imagining it.
Extract from "man get" on my system (Unixware):
-m Causes each text line retrieved from the SCCS file
to be preceded by the SID of the delta that inserted
the text line in the SCCS file. The format is: SID,
followed by a horizontal tab, followed by the text line.
--
Geoff Clare <g...@root.co.uk>
UniSoft Limited, London, England.