sccs.me

早期freebsd实现

.(b
static char OpsysSid[] = "%\&W\&%	%\&G\&%";
.)b
in the file
.i opsys.h .
Otherwise,
you will get compilation errors because
.q 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.
.sh 2 "Keeping \*I's consistent across files"
.pp
With some care,
it is possible to keep the \*I's consistent
in multi-file systems.
The trick here is to always
.i 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 \*S files are in:
.(b
sccs edit SCCS
.)b
which will
.i edit
all files in that directory.
To make the delta, use:
.(b
sccs delta SCCS
.)b
You will be prompted for comments only once.
.sh 2 "Creating new releases"
.pp
When you want to create a new release
of a program,
you can specify the release number you want to create
on the
.i edit
command.
For example:
.(b
sccs edit \-r2 prog.c
.)b
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:
.(b
sccs edit \-r2 SCCS
.)b
.sh 1 "Restoring Old Versions"
.sh 2 "Reverting to old versions"
.pp
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 \*I in a get:
.(b
sccs get \-r1.2 prog.c
.)b
This will produce a version of
.i prog.c
that is delta 1.2
that can be reinstalled so that work can proceed.
.pp
In some cases you don't know
what the \*I 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
.b \-c
(cutoff) flag.
For example,
.(b
sccs get \-c800722120000 prog.c
.)b
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:
.(b
sccs get \-c"80/07/22 12:00:00" prog.c
.)b
.sh 2 "Selectively deleting old deltas"
.pp
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
.i excluding
delta 1.3:
.(b
sccs edit \-x1.3 prog.c
.)b
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 example,
if you want to get rid of 1.3 and 1.4
you can use:
.(b
sccs edit \-x1.3\-1.4 prog.c
.)b
which will exclude all deltas from 1.3 to 1.4.
Alternatively,
.(b
sccs edit \-x1.3\-1 prog.c
.)b
will exclude a range of deltas
from 1.3 to the current highest delta in release 1.
.pp
In certain cases when using
.b \-x
(or
.b \-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,
\*S always prints out a message
telling the range of lines effected;
these lines should then be examined very carefully
to see if the version \*S got
is ok.
.pp
Since each delta
(in the sense of
.q "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.
.sh 1 "Auditing Changes"
.sh 2 "The prt command"
.pp
When you created a delta,
you presumably gave a reason for the delta
to the
.q "comments?"
prompt.
To print out these comments later,
use:
.(b
sccs prt prog.c
.)b
This will produce
a report
for each delta
of the \*I,
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:
.(b
D 1.2	80/08/29 12:35:31	bill	2	1	00005/00003/00084
removed "-q" option
.sp \n(psu
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
.)b
.sh 2 "Finding why lines were inserted"
.pp
To find out
why you inserted lines,
you can get a copy of the file
with each line
preceded by the \*I that created it:
.(b
sccs get \-m prog.c
.)b
You can then find out
what this delta did
by printing the comments using
.i prt .
.pp
To find out what lines are associated with a particular delta
(\c
.i e.g. ,
1.3),
use:
.(b
sccs get \-m \-p prog.c \(bv grep \'^1.3\'
.)b
The
.b \-p
flag causes \*S to output the generated source
to the standard output rather than to a file.
.sh 2 "Finding what changes you have made"
.pp
When you are editing a file,
you can find out what changes you have made using:
.(b
sccs diffs prog.c
.)b
Most of the ``diff'' flags can be used.
To pass the
.b \-c
flag,
use
.b \-C .
.pp
To compare two versions that are in deltas,
use:
.(b
sccs sccsdiff -r1.3 -r1.6 prog.c
.)b
to see the differences between delta 1.3 and delta 1.6.
.sh 1 "Shorthand Notations"
.pp
There are several sequences of commands that get
executed frequently.
.i Sccs
tries to make it easy to do these.
.sh 2 "Delget"
.pp
A frequent requirement is to make a delta of some file
and then get that file.
This can be done by using:
.(b
sccs delget prog.c
.)b
which is entirely equivalent to using:
.(b
sccs delta prog.c
sccs get prog.c
.)b
The
.q deledit
command is equivalent to
.q delget
except that the
.q edit
command is used
instead of the
.q get
command.
.sh 2 "Fix"
.pp
Frequently, there are small bugs
in deltas,
e.g., compilation errors,
for which there is no reason to maintain an audit trail.
To
.i replace
a delta, use:
.(b
sccs fix \-r1.4 prog.c
.)b
This will get a copy of delta 1.4 of prog.c for you to edit
and then delete delta 1.4 from the \*S 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 subsequent
to the creation of that delta.
.sh 2 "Unedit"
.pp
If you found you edited a file
that you did not want to edit,
you can back out by using:
.(b
sccs unedit prog.c
.)b
.sh 2 "The \-d flag"
.pp
If you are working on a project
where the \*S code is in a directory somewhere,
you may be able to simplify things
by using a shell alias.
For example,
the alias:
.(b
alias syssccs sccs \-d/usr/src
.)b
will allow you to issue commands such as:
.(b
syssccs edit cmd/who.c
.)b
which will look for the file
.q "/usr/src/cmd/SCCS/who.c" .
The file
.q who.c
will always be created in your current directory
regardless of the value of the \-d flag.
.sh 1 "Using \*S on a Project"
.pp
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.
\*S prevents this by locking an s-file
while it is being edited.
.pp
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:
.(b
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
.)b
.pp
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.
.sh 1 "Saving Yourself"
.sh 2 "Recovering a munged edit file"
.pp
Sometimes you may find
that you have destroyed or trashed
a file that you were trying to edit\**.
.(f
\**Or given up and decided to start over.
.)f
Unfortunately,
you can't just remove it
and re-\c
.i edit
it;
\*S 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
.i get ,
since that would expand the Id keywords.
Instead,
you can say:
.(b
sccs get \-k prog.c
.)b
This will not expand the Id keywords,
so it is safe to do a delta
with it.
.pp
Alternately,
you can
.i unedit
and
.i edit
the file.
.sh 2 "Restoring the s-file"
.pp
In particularly bad circumstances,
the \*S file itself
may get munged.
The most common way this happens
is that it gets edited.
Since \*S keeps a checksum,
you will get errors every time you read the file.
To fix this checksum, use:
.(b
sccs admin \-z prog.c
.)b
.sh 1 "Using the Admin Command"
.pp
There are a number of parameters that can be set
using the
.i admin
command.
The most interesting of these are flags.
Flags can be added by using the
.b \-f
flag.
For example:
.(b
sccs admin \-fd1 prog.c
.)b
sets the
.q d
flag to the value
.q 1 .
This flag can be deleted by using:
.(b
sccs admin \-dd prog.c
.)b
The most useful flags are:
.nr ii 7n
.ip "b"
Allow branches to be made using the
\-b
flag to
.i edit .
.ip "d\fISID\fP"
Default \*I to be used on a
.i get
or
.i edit .
If this is just a release number
it constrains the
version
to a particular release only.
.ip "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.
.ip "y"
The
.q type
of the module.
Actually,
the value of this flag is unused by \*S
except that it replaces the
.b %\&Y\&%
keyword.
.pp
The
.b \-t\fIfile\fR
flag can be used
to store descriptive text
from
.i file .
This descriptive text might be the documentation
or a design and implementation document.
Using the
.b \-t
flag insures that if the \*S file is sent,
the documentation will be sent also.
If
.i file
is omitted,
the descriptive text is deleted.
To see the descriptive text,
use
.q "prt \-t" .
.pp
The
.i admin
command can be used safely
any number of times on files.
A file need not be gotten
for
.i admin
to work.
.sh 1 "Maintaining Different Versions (Branches)"
.pp
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
.q branch.
Normally deltas continue in a straight line,
each depending on the delta before.
Creating a branch
.q "forks off"
a version of the program.
.pp
The ability to create branches
must be enabled in advance using:
.(b
sccs admin \-fb prog.c
.)b
The
.b \-fb
flag can be specified when the
\*S file is first created.
.sh 2 "Creating a branch"
.pp
To create a branch, use:
.(b
sccs edit \-b prog.c
.)b
This will create a branch
with (for example) \*I 1.5.1.1.
The deltas for this version
will be numbered
1.5.1.\c
.i n .
.sh 2 "Getting from a branch"
.pp
Deltas in a branch are normally not included
when you do a get.
To get these versions,
you will have to say:
.(b
sccs get \-r1.5.1 prog.c
.)b
.sh 2 "Merging a branch back into the main trunk"
.pp
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