










                   [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 before[1].  However, it is possible to get  a  ver‐
sion of the file that has selected deltas removed out of the
middle  of the list of changes — equivalent to removing your
changes later.




____________________
   [1]This  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 retrieved[2] 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 it[3]:

        sccs edit prog.c

The response will be the same as with  [4mget[24m  except  that  it
will also say:

        New delta 1.2

____________________
   [2]Actually, the SID of the final delta applied was 1.1.
   [3]The  “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  back‐
slash[4]).  [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 unchanged[5].
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
everything 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:

____________________
   [4]Yes, this is a stupid default.
   [5]Changes 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  edit[6].   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

____________________
   [6]Or 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.
