An Introduction to the
                 Source Code Control System

                        Eric Allman
                       Project Ingres
            University of California at Berkeley

     This document gives a quick introduction to  using  the
Source  Code  Control  System  (SCCS).   The presentation is
geared to programmers who are more concerned with what to do
to get a task done rather than how it works; for this reason
some of the examples are not well explained.  For details of
what  the  magic  options  do,  see  the section on "Further
Information".

        This is a working document.  Please send any
        comments   or   suggestions  to  eric@Berke­
        ley.Edu.


1. Introduction


     SCCS is a source  management  system.   Such  a  system
maintains a record of versions of a system; a record is kept
with each set of changes of what the changes are,  why  they
were  made, and who made them and when.  Old versions can be
recovered, and different versions can be maintained simulta­
neously.   In  projects with more than one person, SCCS will
insure that two people are not editing the same file at  the
same time.

     All  versions  of  your program, plus the log and other
information, is kept in a file called the  "s-file".   There
are  three  major operations that can be performed on the s-
file:

 (1)   Get a file for compilation (not for  editing).   This
       operation retrieves a version of the file from the s-
       file.  By default, the latest version  is  retrieved.
       This  file  is intended for compilation, printing, or
____________________
   This is version 1.21 of this document.  It was last modi­
fied on 12/5/80.

An Introduction to the Source Code Control System   PSD:14-1


PSD:14-2   An Introduction to the Source Code Control System

       whatever; it  is  specifically  NOT  intended  to  be
       edited  or  changed in any way; any changes made to a
       file retrieved in this way will probably be lost.

 (2)   Get  a  file  for  editing.   This   operation   also
       retrieves  a version of the file from the s-file, but
       this file is intended to be edited and then  incorpo­
       rated  back  into the s-file.  Only one person may be
       editing a file at one time.

 (3)   Merge a file back into the s-file.  This is the  com­
       panion  operation  to  (2).   A new version number is
       assigned, and comments are saved explaining why  this
       change was made.


2. Learning the Lingo


     There  are  a  number  of terms that are worth learning
before we go any farther.


2.1. S-file


     The s-file is a single file that holds all the  differ­
ent  versions of your file.  The s-file is stored in differ­
ential format; i.e., only the differences  between  versions
are  stored, rather than the entire text of the new version.
This saves disk space and allows  selective  changes  to  be
removed  later.   Also included in the s-file is some header
information for each version, including the  comments  given
by  the  person  who  created the version explaining why the
changes were made.


2.2. Deltas


     Each set of changes to the s-file  (which  is  approxi­
mately  [but  not  exactly!]  equivalent to a version of the
file) is called a delta.  Although technically a delta  only
includes  the changes made, in practice it is usual for each
delta to be made with respect to all the  deltas  that  have
occurred  before1.  However, it is possible to get a version
of the file that has selected deltas removed out of the mid­
dle  of  the  list of changes -- equivalent to removing your
changes later.

____________________
   1This  matches  normal  usage, where the previous changes
are not saved at all, so all changes are automatically based
on all other changes that have happened through history.


An Introduction to the Source Code Control System   PSD:14-3


2.3. SID's (or, version numbers)


     A SID (SCCS Id) is a number that  represents  a  delta.
This is normally a two-part number consisting of a "release"
number and a "level" number.  Normally  the  release  number
stays  the  same, however, it is possible to move into a new
release if some major change is being made.

     Since all past deltas are normally applied, the SID  of
the  final  delta applied can be used to represent a version
number of the file as a whole.


2.4. Id keywords


     When you get a version of a file with intent to compile
and  install  it  (i.e., something other than edit it), some
special keywords are expanded inline by SCCS.  These Id Key­
words  can  be used to include the current version number or
other information into the file.  All id keywords are of the

form %x%, where x is an upper case letter. For example, %I%


is the SID of the latest delta applied, %W% includes the

module  name,  SID,  and  a mark that makes it findable by a

program, and %G% is the date of the latest delta applied.

There  are many others, most of which are of dubious useful­
ness.

     When you get a file for editing, the  id  keywords  are
not  expanded; this is so that after you put them back in to
the s-file, they will be expanded automatically on each  new
version.  But notice: if you were to get them expanded acci­
dently, then your file would appear to be the  same  version
forever  more,  which  would  of  course defeat the purpose.
Also, if you should install a version of the program without
expanding  the  id  keywords,  it will be impossible to tell
what version it is (since all it will have is "%W%" or what­
ever).


3. Creating SCCS Files


     To put source files into SCCS format, run the following
shell script from csh:

        mkdir SCCS save
        foreach i (*.[ch])
             sccs admin -i$i $i
             mv $i save/$i
        end

This will put the named files into s-files in the  subdirec­
tory  "SCCS"  The  files  will  be  removed from the current
directory and hidden away in the directory  "save",  so  the
next  thing  you  will probably want to do is to get all the
files (described below).  When you are convinced  that  SCCS


PSD:14-4   An Introduction to the Source Code Control System

has  correctly  created  the  s-files, you should remove the
directory "save".

     If you want to have id keywords in  the  files,  it  is
best  to  put them in before you create the s-files.  If you
do not, admin will print "No Id Keywords (cm7)", which is  a
warning message only.


4. Getting Files for Compilation


     To get a copy of the latest version of a file, run

        sccs get prog.c

SCCS will respond:

        1.1
        87 lines

meaning  that  version 1.1 was retrieved2 and that it has 87
lines.  The file prog.c  will  be  created  in  the  current
directory.   The  file  will be read-only to remind you that
you are not supposed to change it.

     This copy of the file should not be changed, since SCCS
is unable to merge the changes back into the s-file.  If you
do make changes, they will be lost  the  next  time  someone
does a get.


5. Changing Files (or, Creating Deltas)



5.1. Getting a copy to edit


     To  edit a source file, you must first get it, request­
ing permission to edit it3:

        sccs edit prog.c

The  response  will  be  the same as with get except that it
will also say:

        New delta 1.2

____________________
   2Actually, the SID of the final delta applied was 1.1.
   3The "edit" command is equivalent to using the -e flag to
get, as:

        sccs get -e prog.c

Keep this in mind when reading other documentation.


An Introduction to the Source Code Control System   PSD:14-5

You then edit it, using a standard text editor:

        vi prog.c


5.2. Merging the changes back into the s-file


     When the desired changes are made,  you  can  put  your
changes into the SCCS file using the delta command:

        sccs delta prog.c

     Delta will prompt you for "comments?"  before it merges
the changes in.  At this prompt you should type  a  one-line
description  of  what  the  changes  mean (more lines can be
entered  by  ending  each  line  except  the  last  with   a
backslash4).  Delta will then type:

        1.2
        5 inserted
        3 deleted
        84 unchanged

saying  that  delta  1.2  was  created, and it inserted five
lines,  removed  three  lines, and left 84 lines unchanged5.
The prog.c file will be removed; it can be  retrieved  using
get.


5.3. When to make deltas


     It  is  probably  unwise  to  make a delta before every
recompilation or test; otherwise, you tend to get a  lot  of
deltas with comments like "fixed compilation problem in pre­
vious delta" or "fixed botch in 1.3".  However, it  is  very
important to delta everything before installing a module for
general use.  A good technique is  to  edit  the  files  you
need,  make  all  necessary changes and tests, compiling and
editing as often as necessary without making  deltas.   When
you  are  satisfied  that  you have a working version, delta
everything being edited, re-get them, and  recompile  every­
thing.


5.4. What's going on: the info command


     To find out what files where being edited, you can use:

____________________
   4Yes, this is a stupid default.
   5Changes to a line are counted as a line  deleted  and  a
line inserted.


PSD:14-6   An Introduction to the Source Code Control System

        sccs info

to print out all the files being edited and  other  informa­
tion  such  as the name of the user who did the edit.  Also,
the command:

        sccs check

is nearly equivalent to the info command, except that it  is
silent if nothing is being edited, and returns non-zero exit
status if anything is being edited; it can  be  used  in  an
"install"  entry  in a makefile to abort the install if any­
thing has not been properly deltaed.

     If you know that  everything  being  edited  should  be
deltaed, you can use:

        sccs delta `sccs tell`

The  tell  command  is  similar to info except that only the
names of files being edited are output, one per line.

     All  of  these  commands  take  a  -b  flag  to  ignore

"branches" (alternate versions, described later) and the -u


flag to only give files being edited by you. The -u flag

takes  an  optional  user  argument, giving only files being
edited by that user.  For example,

        sccs info -ujohn

gives a listing of files being edited by john.


5.5. ID keywords


     Id keywords can be inserted into your file that will be
expanded automatically by get.  For example, a line such as:

        static char SccsId[] = "%W%\t%G%";

will be replaced with something like:

        static char SccsId[] = "@(#)prog.c 1.2  08/29/80";

This tells you the name and version of the source  file  and
the time the delta was created.  The string "@(#)" is a spe­
cial string which signals the beginning of an SCCS  Id  key­
word.


5.5.1. The what command


     To  find  out  what  version of a program is being run,
use:


An Introduction to the Source Code Control System   PSD:14-7

        sccs what prog.c /usr/bin/prog

which will print  all  strings  it  finds  that  begin  with
"@(#)".   This  works on all types of files, including bina­
ries and libraries.  For example,  the  above  command  will
output something like:

        prog.c:
             prog.c    1.2  08/29/80
        /usr/bin/prog:
             prog.c    1.1  02/05/79

From  this  I  can see that the source that I have in prog.c
will not compile into the same  version  as  the  binary  in
/usr/bin/prog.


5.5.2. Where to put id keywords


     ID keywords can be inserted anywhere, including in com­
ments, but Id Keywords that are  compiled  into  the  object
module  are  especially  useful,  since it lets you find out
what version of the object is being  run,  as  well  as  the
source.   However, there is a cost: data space is used up to
store the keywords, and on small address space machines this
may be prohibitive.

     When  you  put  id  keywords  into  header files, it is
important that you assign them to different variables.   For
example, you might use:

        static char AccessSid[] = "%W%     %G%";

in the file access.h and:

        static char OpsysSid[] = "%W% %G%";

in  the  file  opsys.h.  Otherwise, you will get compilation
errors because "SccsId" is redefined.  The problem with this
is  that if the header file is included by many modules that
are loaded together, the version number of that header  file
is included in the object module many times; you may find it
more to your taste to put id keywords  in  header  files  in
comments.


5.6. Keeping SID's consistent across files


     With  some  care, it is possible to keep the SID's con­
sistent in multi-file systems.  The trick here is to  always
edit  all  files  at  once.  The changes can then be made to
whatever files are necessary and then all files (even  those
not  changed) are redeltaed.  This can be done fairly easily
by just specifying the name of the directory that  the  SCCS
files are in:


PSD:14-8   An Introduction to the Source Code Control System

        sccs edit SCCS

which  will  edit  all files in that directory.  To make the
delta, use:

        sccs delta SCCS

You will be prompted for comments only once.


5.7. Creating new releases


     When you want to create a new release of a program, you
can  specify  the  release  number you want to create on the
edit command.  For example:

        sccs edit -r2 prog.c

will cause the next delta to be in release two (that is,  it
will  be numbered 2.1).  Future deltas will automatically be
in release two.  To change the release number of  an  entire
system, use:

        sccs edit -r2 SCCS


6. Restoring Old Versions



6.1. Reverting to old versions


     Suppose  that  after  delta 1.2 was stable you made and
released a delta 1.3.  But this introduced  a  bug,  so  you
made  a  delta  1.4 to correct it.  But 1.4 was still buggy,
and you decided you wanted to go back to  the  old  version.
You could revert to delta 1.2 by choosing the SID in a get:

        sccs get -r1.2 prog.c

This will produce a version of prog.c that is delta 1.2 that
can be reinstalled so that work can proceed.

     In some cases you don't know what the SID of the  delta
you  want is.  However, you can revert to the version of the
program that was running as of a certain date by  using  the

-c (cutoff) flag. For example,


        sccs get -c800722120000 prog.c

will  retrieve  whatever  version was current as of July 22,
1980 at 12:00 noon.  Trailing components can be stripped off
(defaulting  to  their highest legal value), and punctuation
can be inserted in the  obvious  places;  for  example,  the
above line could be equivalently stated:


An Introduction to the Source Code Control System   PSD:14-9

        sccs get -c"80/07/22 12:00:00" prog.c


6.2. Selectively deleting old deltas


     Suppose  that  you  later  decided  that  you liked the
changes in delta 1.4, but that delta 1.3 should be  removed.
You could do this by excluding delta 1.3:

        sccs edit -x1.3 prog.c

When  delta 1.5 is made, it will include the changes made in
delta 1.4, but will exclude the changes made in  delta  1.3.
You  can  exclude a range of deltas using a dash.  For exam­
ple, if you want to get rid of 1.3 and 1.4 you can use:

        sccs edit -x1.3-1.4 prog.c

which will exclude all deltas from  1.3  to  1.4.   Alterna­
tively,

        sccs edit -x1.3-1 prog.c

will exclude a range of deltas from 1.3 to the current high­
est delta in release 1.

     In certain cases when using -x (or -i; see below) there
will  be  conflicts between versions; for example, it may be
necessary to both include and delete a particular line.   If
this  happens,  SCCS always prints out a message telling the
range of lines effected; these lines should then be examined
very carefully to see if the version SCCS got is ok.

     Since  each  delta (in the sense of "a set of changes")
can be excluded at will, that this makes it most  useful  to
put each semantically distinct change into its own delta.


7. Auditing Changes



7.1. The prt command


     When  you created a delta, you presumably gave a reason
for the delta to the  "comments?"   prompt.   To  print  out
these comments later, use:

        sccs prt prog.c

This  will  produce a report for each delta of the SID, time
and date of creation, user who created the delta, number  of
lines  inserted,  deleted,  and  unchanged, and the comments
associated with the delta.  For example, the output  of  the
above command might be:


PSD:14-10  An Introduction to the Source Code Control System

        D 1.2     80/08/29 12:35:31   bill 2    1    00005/00003/00084
        removed "-q" option

        D 1.1     79/02/05 00:19:31   eric 1    0    00087/00000/00000
        date and time created 80/06/10 00:19:31 by eric


7.2. Finding why lines were inserted


     To  find out why you inserted lines, you can get a copy
of the file with each line preceded by the SID that  created
it:

        sccs get -m prog.c

You  can  then  find out what this delta did by printing the
comments using prt.

     To find out what lines are associated with a particular
delta (e.g., 1.3), use:

        sccs get -m -p prog.c | grep ´^1.3´


The -p flag causes SCCS to output the generated source to

the standard output rather than to a file.


7.3. Finding what changes you have made


     When you are editing a file,  you  can  find  out  what
changes you have made using:

        sccs diffs prog.c


Most of the ``diff'' flags can be used. To pass the -c


flag, use -C.


     To compare two versions that are in deltas, use:

        sccs sccsdiff -r1.3 -r1.6 prog.c

to see the differences between delta 1.3 and delta 1.6.


8. Shorthand Notations


     There are several sequences of commands that  get  exe­
cuted frequently.  Sccs tries to make it easy to do these.


8.1. Delget


     A  frequent requirement is to make a delta of some file
and then get that file.  This can be done by using:

        sccs delget prog.c


An Introduction to the Source Code Control System  PSD:14-11

which is entirely equivalent to using:

        sccs delta prog.c
        sccs get prog.c

The "deledit" command is equivalent to "delget" except  that
the "edit" command is used instead of the "get" command.


8.2. Fix


     Frequently,  there are small bugs in deltas, e.g., com­
pilation errors, for which there is no reason to maintain an
audit trail.  To replace a delta, use:

        sccs fix -r1.4 prog.c

This  will get a copy of delta 1.4 of prog.c for you to edit
and then delete delta 1.4 from the SCCS file.  When you do a
delta  of  prog.c,  it will be delta 1.4 again.  The -r flag
must be specified, and the delta that is specified must be a
leaf  delta, i.e., no other deltas may have been made subse­
quent to the creation of that delta.


8.3. Unedit


     If you found you edited a file that you did not want to
edit, you can back out by using:

        sccs unedit prog.c


8.4. The -d flag


     If  you are working on a project where the SCCS code is
in a directory somewhere, you may be able to simplify things
by using a shell alias.  For example, the alias:

        alias syssccs sccs -d/usr/src

will allow you to issue commands such as:

        syssccs edit cmd/who.c

which will look for the file "/usr/src/cmd/SCCS/who.c".  The
file "who.c" will always be created in your  current  direc­
tory regardless of the value of the -d flag.


9. Using SCCS on a Project


     Working  on  a  project with several people has its own
set of special problems.  The main problem occurs  when  two
people  modify  a file at the same time.  SCCS prevents this
by locking an s-file while it is being edited.


PSD:14-12  An Introduction to the Source Code Control System

     As a result, files should not be reserved  for  editing
unless  they  are  actually  being edited at the time, since
this will prevent other people on the  project  from  making
necessary changes.  For example, a good scenario for working
might be:

        sccs edit a.c g.c t.c
        vi a.c g.c t.c
        # do testing of the (experimental) version
        sccs delget a.c g.c t.c
        sccs info
        # should respond "Nothing being edited"
        make install

     As a general rule, all source files should  be  deltaed
before  installing  the  program for general use.  This will
insure that it is possible to restore any version in use  at
any time.


10. Saving Yourself



10.1. Recovering a munged edit file


     Sometimes  you  may  find  that  you  have destroyed or
trashed a file that you  were  trying  to  edit6.   Unfortu­
nately,  you can't just remove it and re-edit it; SCCS keeps
track of the fact that someone is trying to edit it,  so  it
won't  let  you  do  it  again.  Neither can you just get it
using  get,  since  that  would  expand  the  Id   keywords.
Instead, you can say:

        sccs get -k prog.c

This  will not expand the Id keywords, so it is safe to do a
delta with it.

     Alternately, you can unedit and edit the file.


10.2. Restoring the s-file


     In particularly bad circumstances, the SCCS file itself
may get munged.  The most common way this happens is that it
gets edited.  Since SCCS keeps  a  checksum,  you  will  get
errors  every time you read the file.  To fix this checksum,
use:

        sccs admin -z prog.c

____________________
   6Or given up and decided to start over.


An Introduction to the Source Code Control System  PSD:14-13


11. Using the Admin Command


     There are a number of parameters that can be set  using
the admin command.  The most interesting of these are flags.

Flags can be added by using the -f flag. For example:


        sccs admin -fd1 prog.c

sets the "d" flag to  the  value  "1".   This  flag  can  be
deleted by using:

        sccs admin -dd prog.c

The most useful flags are:

b      Allow  branches to be made using the -b flag to edit.

dSID   Default SID to be used on a get or edit.  If this  is
       just  a release number it constrains the version to a
       particular release only.

i      Give a fatal error if there are no Id Keywords  in  a
       file.   This is useful to guarantee that a version of
       the file does not get merged into the s-file that has
       the  Id  Keywords  inserted  as  constants instead of
       internal forms.

y      The "type" of the module.   Actually,  the  value  of
       this  flag  is unused by SCCS except that it replaces
       the %Y% keyword.

     The -tfile flag can be used to store  descriptive  text
from file.  This descriptive text might be the documentation

or a design and implementation document. Using the -t flag

insures  that  if  the  SCCS file is sent, the documentation
will be sent also.  If file is omitted, the descriptive text
is deleted.  To see the descriptive text, use "prt -t".

     The  admin  command  can  be  used safely any number of
times on files.  A file need not  be  gotten  for  admin  to
work.


12. Maintaining Different Versions (Branches)


     Sometimes  it is convenient to maintain an experimental
version of a program for an  extended  period  while  normal
maintenance  continues  on  the version in production.  This
can be done using a "branch."  Normally deltas continue in a
straight line, each depending on the delta before.  Creating
a branch "forks off" a version of the program.

     The ability to  create  branches  must  be  enabled  in
advance using:


PSD:14-14  An Introduction to the Source Code Control System

        sccs admin -fb prog.c


The -fb flag can be specified when the SCCS file is first

created.


12.1. Creating a branch


     To create a branch, use:

        sccs edit -b prog.c

This will create a branch with (for  example)  SID  1.5.1.1.
The deltas for this version will be numbered 1.5.1.n.


12.2. Getting from a branch


     Deltas  in  a branch are normally not included when you
do a get.  To get these versions, you will have to say:

        sccs get -r1.5.1 prog.c


12.3. Merging a branch back into the main trunk


     At some point you will have  finished  the  experiment,
and  if  it  was  successful you will want to incorporate it
into the release version.  But in the meantime  someone  may
have  created  a delta 1.6 that you don't want to lose.  The
commands:

        sccs edit -i1.5.1.1-1.5.1 prog.c
        sccs delta prog.c

will merge all of your changes into the release system.   If
some  of  the changes conflict, get will print an error; the
generated result should be  carefully  examined  before  the
delta is made.


12.4. A more detailed example


     The  following  technique  might  be used to maintain a
different version of a program.  First, create  a  directory
to contain the new version:

        mkdir ../newxyz
        cd ../newxyz

Edit a copy of the program on a branch:

        sccs -d../xyz edit prog.c


When using the old version, be sure to use the -b flag to

info, check,  tell,  and  clean  to  avoid  confusion.   For


An Introduction to the Source Code Control System  PSD:14-15

example, use:

        sccs info -b

when in the directory "xyz".

     If you want to save a copy of the program (still on the
branch) back in the s-file, you can use:

        sccs -d../xyz deledit prog.c

which will do a delta on the branch and reedit it for you.

     When the experiment is complete, merge it back into the
s-file using delta:

        sccs -d../xyz delta prog.c

At this point you must decide whether this version should be
merged back into the  trunk  (i.e.   the  default  version),
which  may  have undergone changes.  If so, it can be merged

using the -i flag to edit as described above.



12.5. A warning


     Branches should be kept to a minimum.  After the  first
branch  from  the  trunk,  SID's are assigned rather haphaz­
ardly, and the structure gets complex fast.


13. Using SCCS with Make


     SCCS and make can be made to work together with a  lit­
tle  care.   A  few sample makefiles for common applications
are shown.

     There are a few basic entries that every makefile ought
to have.  These are:

a.out     (or  whatever the makefile generates.)  This entry
          regenerates whatever this makefile is supposed  to
          regenerate.   If  the  makefile  regenerates  many
          things, this should be called "all" and should  in
          turn  have dependencies on everything the makefile
          can generate.

install   Moves the objects  to  the  final  resting  place,
          doing any special chmod's or ranlib's as appropri­
          ate.

sources   Creates all the source files from SCCS files.

clean     Removes all files from the current directory  that
          can be regenerated from SCCS files.


PSD:14-16  An Introduction to the Source Code Control System

print     Prints the contents of the directory.

The  examples shown below are only partial examples, and may
omit some of these entries when they are deemed to be  obvi­
ous.

     The  clean  entry  should  not remove files that can be
regenerated from the SCCS files.  It is sufficiently  impor­
tant  to  have the source files around at all times that the
only time they should be removed is when  the  directory  is
being mothballed.  To do this, the command:

        sccs clean

can be used.  This will remove all files for which an s-file
exists, but which is not being edited.


13.1. To maintain single programs


     Frequently there are directories with  several  largely
unrelated  programs (such as simple commands).  These can be
put into a single makefile:

        LDFLAGS= -i -s

        prog: prog.o
             $(CC) $(LDFLAGS) -o prog prog.o
        prog.o: prog.c prog.h

        example: example.o
             $(CC) $(LDFLAGS) -o example example.o
        example.o: example.c

        .DEFAULT:
             sccs get $<

The trick here is that the .DEFAULT  rule  is  called  every
time  something  is needed that does not exist, and no other

rule exists to make it. The explicit dependency of the .o


file on the .c file is important. Another way of doing the

same thing is:


An Introduction to the Source Code Control System  PSD:14-17

        SRCS=     prog.c prog.h example.c

        LDFLAGS= -i -s

        prog: prog.o
             $(CC) $(LDFLAGS) -o prog prog.o
        prog.o: prog.h

        example: example.o
             $(CC) $(LDFLAGS) -o example example.o

        sources: $(SRCS)
        $(SRCS):
             sccs get $@

There are a couple of advantages to this approach:  (1)  the
explicit  dependencies  of  the  .o  on the .c files are not
needed, (2) there is an entry called  "sources"  so  if  you
want to get all the sources you can just say "make sources",
and (3) the makefile is less likely to do  confusing  things
since it won't try to get things that do not exist.


13.2. To maintain a library


     Libraries  that  are  largely  static  are best updated
using explicit  commands,  since  make  doesn't  know  about
updating  them properly.  However, libraries that are in the
process of being developed can be handled quite  adequately.
The  problem is that the .o files have to be kept out of the
library as well as in the library.


PSD:14-18  An Introduction to the Source Code Control System

        # configuration information
        OBJS=     a.o b.o c.o d.o
        SRCS=     a.c b.c c.c d.s x.h y.h z.h
        TARG=     /usr/lib

        # programs
        GET= sccs get
        REL=
        AR=  -ar
        RANLIB=   ranlib

        lib.a: $(OBJS)
             $(AR) rvu lib.a $(OBJS)
             $(RANLIB) lib.a

        install: lib.a
             sccs check
             cp lib.a $(TARG)/lib.a
             $(RANLIB) $(TARG)/lib.a

        sources: $(SRCS)
        $(SRCS):
             $(GET) $(REL) $@

        print: sources
             pr *.h *.[cs]
        clean:
             rm -f *.o
             rm -f core a.out $(LIB)

     The "$(REL)" in the get can be used to get old versions
easily; for example:

        make b.o REL=-r1.3

     The install entry includes the line "sccs check" before
anything else.  This guarantees that all the s-files are  up
to  date (i.e., nothing is being edited), and will abort the
make if this condition is not met.


13.3. To maintain a large program



An Introduction to the Source Code Control System  PSD:14-19

        OBJS=     a.o b.o c.o d.o
        SRCS=     a.c b.c c.y d.s x.h y.h z.h

        GET= sccs get
        REL=

        a.out: $(OBJS)
             $(CC) $(LDFLAGS) $(OBJS) $(LIBS)

        sources: $(SRCS)
        $(SRCS):
             $(GET) $(REL) $@

(The print and clean entries are identical to  the  previous
case.)   This  makefile  requires  copies  of the source and
object files to be kept during development.  It is  probably
also wise to include lines of the form:

        a.o: x.h y.h
        b.o: z.h
        c.o: x.h y.h z.h
        z.h: x.h

so that modules will be recompiled if header files change.

     Since  make does not do transitive closure on dependen­
cies, you may find in some makefiles lines like:

        z.h: x.h
             touch z.h

This would be used in cases where file z.h has a line:

        #include "x.h"

in order to bring the mod date of z.h in line with  the  mod
date  of  x.h.   When you have a makefile such as above, the
touch command can  be  removed  completely;  the  equivalent
effect will be achieved by doing an automatic get on z.h.


14. Further Information


     The  SCCS/PWB  User's Manual gives a deeper description
of how to use SCCS.  Of particular interest are the  number­
ing  of  branches,  the l-file, which gives a description of
what deltas were used on a get, and certain other SCCS  com­
mands.

     The  SCCS  manual  pages are a good last resort.  These
should be read by software managers and by people  who  want
to know everything about everything.


PSD:14-20  An Introduction to the Source Code Control System

     Both  of  these documents were written without the sccs
front end in mind, so most of the examples are slightly dif­
ferent from those in this document.


An Introduction to the Source Code Control System  PSD:14-21

                      Quick Reference


1. Commands


     The  following  commands  should  all  be preceded with
"sccs".  This list is not exhaustive; for more  options  see
Further Information.

get      Gets  files  for compilation (not for editing).  Id
         keywords are expanded.

         -rSID   Version to get.

         -p      Send to standard output rather than to  the
                 actual file.

         -k      Don't expand id keywords.

         -ilist  List of deltas to include.

         -xlist  List of deltas to exclude.

         -m      Precede  each  line  with  SID  of creating
                 delta.

         -cdate  Don't apply any deltas created after  date.

edit     Gets  files  for  editing.   Id  keywords  are  not
         expanded.  Should be matched with a delta  command.

         -rSID   Same  as  get.   If SID specifies a release
                 that does not yet exist, the  highest  num­
                 bered  delta is retrieved and the new delta
                 is numbered with SID.

         -b      Create a branch.

         -ilist  Same as get.

         -xlist  Same as get.

delta    Merge a file gotten using edit  back  into  the  s-
         file.   Collect  comments  about why this delta was
         made.

unedit   Remove a file that has been edited previously with­
         out merging the changes into the s-file.

prt      Produce a report of changes.


PSD:14-22  An Introduction to the Source Code Control System

         -t   Print the descriptive text.

         -e   Print (nearly) everything.

info     Give a list of all files being edited.

         -b   Ignore branches.

         -u[user]
              Ignore files not being edited by user.

check    Same  as  info,  except  that nothing is printed if
         nothing  is  being  edited  and  exit   status   is
         returned.

tell     Same  as info, except that one line is produced per
         file being edited containing only the file name.

clean    Remove all files that can be regenerated  from  the
         s-file.

what     Find and print id keywords.

admin    Create or set parameters on s-files.

         -ifile  Create, using file as the initial contents.

         -z      Rebuild the checksum in case the  file  has
                 been trashed.

         -fflag  Turn on the flag.

         -dflag  Turn off (delete) the flag.

         -tfile  Replace  the descriptive text in the s-file
                 with the contents  of  file.   If  file  is
                 omitted,  the  text is deleted.  Useful for
                 storing documentation or "design  &  imple­
                 mentation"  documents  to  insure  they get
                 distributed with the s-file.

         Useful flags are:

         b       Allow branches to be made using the -b flag
                 to edit.

         dSID    Default SID to be used on a get or edit.

         i       Cause  "No Id Keywords" error message to be
                 a fatal error rather than a warning.

         t       The module "type"; the value of  this  flag
                 replaces the %Y% keyword.


An Introduction to the Source Code Control System  PSD:14-23

fix      Remove a delta and reedit it.

delget   Do a delta followed by a get.

deledit  Do a delta followed by an edit.


2. Id Keywords


%Z%   Expands to "@(#)" for the what command to find.

%M%   The current module name, e.g., "prog.c".

%I%   The highest SID applied.

%W%   A shorthand for "%Z%%M% <tab> %I%".

%G%   The  date of the delta corresponding to the "%I%" key­
      word.

%R%   The current release number, i.e., the first  component
      of the "%I%" keyword.


%Y% Replaced by the value of the t flag (set by admin).



Man(1) output converted with man2html


FhG FhG FOKUS BerliOS Schily Schily's Home VED powered