










                   [1mAn Introduction to the[0m
                 [1mSource Code Control System[0m

                        Eric Allman
                       [4mProject[24m [4mIngres[0m
            [4mUniversity[24m [4mof[24m [4mCalifornia[24m [4mat[24m [4mBerkeley[0m





     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 In-
formation”.

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


[1m1.  Introduction[0m

     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  re-
       trieves  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 as-
       signed, and comments are saved  explaining  why  this
       change was made.

[1m2.  Learning the Lingo[0m

     There are a number of terms that are worth learning be-
fore we go any farther.

[1m2.1.  S‐file[0m

     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; [4mi.e.[24m, 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 re-
moved later.  Also included in the s‐file is some header in-
formation for each version, including the comments given  by
the  person  who  created  the  version  explaining  why the
changes were made.

[1m2.2.  Deltas[0m

     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 [4mdelta[24m.  Although technically a delta  only
includes  the [4mchanges[24m 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


[1m2.3.  SID’s (or, version numbers)[0m

     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.

[1m2.4.  Id keywords[0m

     When you get a version of a file with intent to compile
and  install  it  ([4mi.e.[24m, something other than edit it), some
special keywords are expanded inline by SCCS.  These [4mId[24m [4mKey-[0m
[4mwords[24m  can  be used to include the current version number or
other information into the file.  All id keywords are of the
form [1m%[4m[22mx[24m[1m%[22m, where [4mx[24m is an upper case letter.  For example, [1m%I%[0m
is the SID of the latest delta  applied,  [1m%W%  [22mincludes  the
module  name,  SID,  and  a mark that makes it findable by a
program, and [1m%G% [22mis 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).

[1m3.  Creating SCCS Files[0m

     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 di-
rectory 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  has










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


correctly  created the s‐files, you should remove the direc-
tory “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, [4madmin[24m will print “No Id Keywords (cm7)”, which is  a
warning message only.

[1m4.  Getting Files for Compilation[0m

     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 [4mprog.c[24m will be created in the  current  di-
rectory.   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 [4mget[24m.

[1m5.  Changing Files (or, Creating Deltas)[0m

[1m5.1.  Getting a copy to edit[0m

     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 [4mget[24m 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
[4mget[24m, 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


[1m5.2.  Merging the changes back into the s‐file[0m

     When the desired changes are made,  you  can  put  your
changes into the SCCS file using the [4mdelta[24m 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 en-
tered  by  ending  each  line  except  the   last   with   a
backslash4).  [4mDelta[24m 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 [4mprog.c[24m file will be removed; it can be  retrieved  using
[4mget[24m.

[1m5.3.  When to make deltas[0m

     It  is probably unwise to make a delta before every re-
compilation 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 ev-
erything being edited, re‐get  them,  and  recompile  every-
thing.

[1m5.4.  What’s going on: the info command[0m

     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 [4minfo[24m 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 [4mtell[24m command is similar to [4minfo[24m  except  that  only  the
names of files being edited are output, one per line.

     All  of  these  commands  take  a  [1m−b  [22mflag  to  ignore
“branches” (alternate versions, described later) and the  [1m−u[0m
flag  to  only  give files being edited by you.  The [1m−u [22mflag
takes an optional [4muser[24m argument,  giving  only  files  being
edited by that user.  For example,

        sccs info −ujohn

gives a listing of files being edited by john.

[1m5.5.  ID keywords[0m

     Id keywords can be inserted into your file that will be
expanded automatically by [4mget[24m.  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.

[1m5.5.1.  The what command[0m

     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.

[1m5.5.2.  Where to put id keywords[0m

     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 im-
portant that you assign them to  different  variables.   For
example, you might use:

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

in the file [4maccess.h[24m and:

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

in  the  file  [4mopsys.h[24m.  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.

[1m5.6.  Keeping SID’s consistent across files[0m

     With  some  care, it is possible to keep the SID’s con-
sistent in multi‐file systems.  The trick here is to  always
[4medit[24m  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  [4medit[24m  all files in that directory.  To make the
delta, use:

        sccs delta SCCS

You will be prompted for comments only once.

[1m5.7.  Creating new releases[0m

     When you want to create a new release of a program, you
can  specify  the  release  number you want to create on the
[4medit[24m 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


[1m6.  Restoring Old Versions[0m

[1m6.1.  Reverting to old versions[0m

     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 [4mprog.c[24m 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
[1m−c [22m(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


[1m6.2.  Selectively deleting old deltas[0m

     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 [4mexcluding[24m 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 [1m−x [22m(or [1m−i[22m; 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.

[1m7.  Auditing Changes[0m

[1m7.1.  The prt command[0m

     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 as-
sociated 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


[1m7.2.  Finding why lines were inserted[0m

     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 [4mprt[24m.

     To find out what lines are associated with a particular
delta ([4me.g.[24m, 1.3), use:

        sccs get −m −p prog.c ⎪ grep ´^1.3´

The  [1m−p  [22mflag  causes SCCS to output the generated source to
the standard output rather than to a file.

[1m7.3.  Finding what changes you have made[0m

     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 [1m−c[0m
flag, use [1m−C[22m.

     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.

[1m8.  Shorthand Notations[0m

     There are several sequences of commands that  get  exe-
cuted frequently.  [4mSccs[24m tries to make it easy to do these.

[1m8.1.  Delget[0m

     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.

[1m8.2.  Fix[0m

     Frequently,  there are small bugs in deltas, e.g., com-
pilation errors, for which there is no reason to maintain an
audit trail.  To [4mreplace[24m 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.

[1m8.3.  Unedit[0m

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

        sccs unedit prog.c


[1m8.4.  The −d flag[0m

     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.

[1m9.  Using SCCS on a Project[0m

     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.

[1m10.  Saving Yourself[0m

[1m10.1.  Recovering a munged edit file[0m

     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‐[4medit[24m 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 us-
ing [4mget[24m, 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 [4munedit[24m and [4medit[24m the file.

[1m10.2.  Restoring the s‐file[0m

     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  er-
rors  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


[1m11.  Using the Admin Command[0m

     There are a number of parameters that can be set  using
the [4madmin[24m command.  The most interesting of these are flags.
Flags can be added by using the [1m−f [22mflag.  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 [4medit[24m.

d[4mSID[24m   Default  SID to be used on a [4mget[24m or [4medit[24m.  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  in-
       ternal forms.

y      The  “type”  of  the  module.  Actually, the value of
       this flag is unused by SCCS except that  it  replaces
       the [1m%Y% [22mkeyword.

     The  [1m−t[4m[22mfile[24m  flag can be used to store descriptive text
from [4mfile[24m.  This descriptive text might be the documentation
or  a design and implementation document.  Using the [1m−t [22mflag
insures that if the SCCS file  is  sent,  the  documentation
will be sent also.  If [4mfile[24m is omitted, the descriptive text
is deleted.  To see the descriptive text, use “prt −t”.

     The [4madmin[24m command can be  used  safely  any  number  of
times  on  files.   A  file  need not be gotten for [4madmin[24m to
work.

[1m12.  Maintaining Different Versions (Branches)[0m

     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 ad-
vance using:










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


        sccs admin −fb prog.c

The [1m−fb [22mflag can be specified when the SCCS  file  is  first
created.

[1m12.1.  Creating a branch[0m

     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.[4mn[24m.

[1m12.2.  Getting from a branch[0m

     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


[1m12.3.  Merging a branch back into the main trunk[0m

     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.

[1m12.4.  A more detailed example[0m

     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  [1m−b  [22mflag  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  ([4mi.e.[24m  the default version),
which may have undergone changes.  If so, it can  be  merged
using the [1m−i [22mflag to [4medit[24m as described above.

[1m12.5.  A warning[0m

     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.

[1m13.  Using SCCS with Make[0m

     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, do-
          ing any special [4mchmod[24m’s or [4mranlib[24m’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 [4mclean[24m entry should not remove files that can be re-
generated from the SCCS files.  It is sufficiently important
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.

[1m13.1.  To maintain single programs[0m

     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 [1m.o[0m
file on the [1m.c [22mfile 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 [4mget[24m things that do not exist.

[1m13.2.  To maintain a library[0m

     Libraries that are largely static are best updated  us-
ing  explicit commands, since [4mmake[24m doesn’t know about updat-
ing 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 [4minstall[24m entry includes the line “sccs check” before
anything  else.  This guarantees that all the s‐files are up
to date ([4mi.e.[24m, nothing is being edited), and will abort  the
[4mmake[24m if this condition is not met.

[1m13.3.  To maintain a large program[0m




















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  [4mprint[24m  and [4mclean[24m entries are identical to the previous
case.)  This makefile requires copies of the source and  ob-
ject  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 [4mmake[24m 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
[4mtouch[24m  command can be removed completely; the equivalent ef-
fect will be achieved by doing an automatic [4mget[24m on z.h.

[1m14.  Further Information[0m

     The [4mSCCS/PWB[24m [4mUser’s[24m [4mManual[24m 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  [4msccs[0m
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


                      [1mQuick Reference[0m



[1m1.  Commands[0m

     The following commands  should  all  be  preceded  with
“sccs”.   This  list is not exhaustive; for more options see
[4mFurther[24m [4mInformation[24m.

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

         −r[4mSID[24m   Version to get.

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

         −k      Don’t expand id keywords.

         −i[4mlist[24m  List of deltas to include.

         −x[4mlist[24m  List of deltas to exclude.

         −m      Precede each  line  with  SID  of  creating
                 delta.

         −c[4mdate[24m  Don’t apply any deltas created after [4mdate.[0m

edit     Gets  files  for  editing.  Id keywords are not ex-
         panded.  Should be matched with a [4mdelta[24m command.

         −r[4mSID[24m   Same as [4mget[24m.  If [4mSID[24m  specifies  a  release
                 that  does  not yet exist, the highest num-
                 bered delta is retrieved and the new  delta
                 is numbered with [4mSID[24m.

         −b      Create a branch.

         −i[4mlist[24m  Same as [4mget[24m.

         −x[4mlist[24m  Same as [4mget[24m.

delta    Merge  a  file  gotten  using [4medit[24m 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[[4muser[24m]
              Ignore files not being edited by [4muser[24m.

check    Same as [4minfo[24m, except that  nothing  is  printed  if
         nothing  is  being  edited  and  exit status is re-
         turned.

tell     Same as [4minfo[24m, 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.

         −i[4mfile[24m  Create, using [4mfile[24m as the initial contents.

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

         −f[4mflag[24m  Turn on the [4mflag[24m.

         −d[4mflag[24m  Turn off (delete) the [4mflag[24m.

         −t[4mfile[24m  Replace  the descriptive text in the s‐file
                 with the contents  of  [4mfile[24m.   If  [4mfile[24m  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 [4medit.[0m

         d[4mSID[24m    Default SID to be used on a [4mget[24m or [4medit[24m.

         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 [1m%Y% [22mkeyword.










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


fix      Remove a delta and reedit it.

delget   Do a [4mdelta[24m followed by a [4mget[24m.

deledit  Do a [4mdelta[24m followed by an [4medit[24m.

[1m2.  Id Keywords[0m

%Z%   Expands to “@(#)” for the [4mwhat[24m command to find.

%M%   The current module name, [4me.g.,[24m “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, [4mi.e.[24m, the first  component
      of the “%I%” keyword.

%Y%   Replaced by the value of the [1mt [22mflag (set by [4madmin[24m).




































----
This file was generated with "groff -me -Tutf8 sccs.me".
Use groff's -T option to generate formats like ps or html.
