[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1 admin

To create an SCCS archive of a source file `foo.c', do

 
admin -ifoo.c s.foo.c

This creates the archive file `s.foo.c' and initialises it with the current contents of your source file, `foo.c'. If you use Emacs as your editor, you can just use C-x v i instead.

Another frequently-used option is `-b', which indicates that the file is to be treated as a binary file rather than as text. You might want to do this because the file actually contains binary data, or just characters that have other meanings within an SCCS file, for example `^A', the character whose code is 1.

`-axxx'

Add user or group xxx to the list of those authorised to check revisions in (that is, use get -e and delta). Users must be specified by name and groups by numeric ID.

This feature is often used in conjunction with a setuid installation of the sccs driver program (see section sccs). This is not a good idea because the CSSC suite is not secure (see section Known Problems).

`-b'

Ensure that the file is encoded as a binary file. This option only works in conjunction with the -n or -i options.

This option is not available if binary file support is turned off (see section Interoperability) though this can be re-enabled if necessary with an environment variable (see section Environment Variables).

`-dF'

Delete flag F from the flags present in the file (see section Flags).

`-exxx'

Erase the specified user or group from the list of those authorised to check revisions in or out.

`-fF[xxx]'

Add the flag F (with optional value xxx) to the file's flags (see section Flags). For example, `-fv/tmp/checkit' sets the MR-validation flag to `/tmp/checkit'.

`-h'

Check the SCCS file. The exit value will be 0 if the file is valid, and not 0 otherwise. The checks made are the same as those made for val. Some problems with the SCCS file may not be diagnosed.

Warning messages may be emitted, indicating things that may or may not be wrong (e.g. time apparently going backwards), but if no actual errors are encountered, the exit value will still be zero.

This option is silently incompatible with all the other options; the specified SCCS files will not be modified by admin if the `-h' flag is used.

`-ifoo'

Initialise the SCCS file with the contents of the file foo. If no argument is given, read from standard input. This implies the `-n' option.

`-mMR-list'

When initialising a file, add the specified list of MR numbers (see section Modification Request Numbers) to the delta commentary for the initial version. This list can be empty. The specified MRs are validated according to the setting of the v flag, which should be set (see section Flags). If the v flag is set but has no value (i.e. is set to the empty string), validation silently succeeds. If the v flag is not set, the `-m' option causes delta to fail.

`-n'

Create a new SCCS file. Unless `-i' is also used, the new file will contain control information but the body will be initially empty. Some versions of SCCS require the `-i' option to be specified if `-n' is used. Therefore for greatest portability, specify `-i/dev/null' if you want an empty initial body. Interoperability.

`-rN'

Set the initial release number to N. The initial level within that release is always 1. Some versions of SCCS allow you to specify actual an actual SID here (for example `1.2' or `1.8.2.1'). CSSC also allows this, but emits a warning. If you use the `-r' option, you must also use the `-i' option (not just the `-n' option). If the initial SID you specify is not on the trunk, some tools will fail to work with the resulting file. See also See section SCCS Version Differences.

`-tdesc'

Read in descriptive text for this file from `desc'. This replaces any existing description. If no argument, remove any existing description (this is illegal if `-i' or `-n' is used).

`-V'

Display version information.

`-yadayada'

When initialising a file, set the comment for that delta to adayada. If the option is given just as `-y', the comment is recorded as empty. The following word in the argument list is not used as the comment. Note that this behaviour is different to most Unix programs, but is the same as the behaviour of traditional SCCS.

`-z'

Fix the checksum information. The SCCS file is still validated by CSSC; apart from possibly having an incorrect checksum, the s-file must be valid. If you use this option on an SCCS file which really is invalid, then the attempt may fail or silently write out a valid but incorrect file. This option does not work on BitKeeper files. Use this option with extreme care.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1.1 Flags

Flags are set and cleared with the admin program. See section admin.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

Boolean Flags

`b'

Enable branch deltas: this enables the `-b' option of get (see section get).

`e'

This flag indicates that the file controlled by this SCCS file is a binary file, and hence the body of the SCCS file is uuencoded. This flag can only be set with the `-b' option of admin at the time the file is created (or if admin takes it upon itself to set this flag automatically), and cannot be unset. The circumstances under which this can happen are discussed in Interoperability.

`f'

This flag is specific to the BitKeeper suite, and is only supported if CSSC has recognised the file as a BitKeeper file. CSSC does not understand the significance of this flag.

`i'

Make get and delta exit unsuccessfully when the `Warning: No id keywords' message is issued.

`j'

Enables concurrent updates: if you try to get a revision for editing, this normally fails if another user already has the file locked. Setting the `j' flag overrides this.

`n'

Create empty releases when the `-r' option to get is used to skip releases. These empty releases can later serve as branch points.

`x'

Sets the executable bit on the g-file. This flag is a SCO OpenServer extension and is not supported by other versions of SCCS. Setting this flag with admin -fx generates a warning to this effect. If CSSC is simply processing a file which already has this flag set, no message will be generated. See Interoperability for more information on compatibility between CSSC and other implementations of SCCS.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

Other Flags

`c'

Set the release ceiling. Releases higher than the ceiling cannot be checked out.

`f'

Set the release floor. Releases lower then the release floor cannot be checked out.

`d'

Set the default delta which is used when the get command is given without the `-r' option. The default behaviour for get is defined in get.

`l'

Set the locked release list. These releases cannot be checked out with get -e. The special value `a' denotes all releases.

`q'

Sets the value substituted for the `%Q%' keyword as described in Keyword Substitution. This flag is referred to in the output of SCCS as `csect name', and is variously referred to here as that, or the "user flag" or the "Q flag".

`m'

Sets the overridden value for the `%M%' keyword as described in Keyword Substitution.

`t'

Sets the value for the `%Y%' keyword as described in Keyword Substitution.

`v'

Sets the name of the program used to validate MR (modification request) numbers; MRs are described in Modification Request Numbers. This flag can be set to the empty string, in which case MRs are allowed and the validation silently succeeds without any program being run.

`y'

By default, all keywords are expanded in the gotten file. See Keyword Substitution for a list of such keywords. This flag can be set to a list of letters separated by commas, in which case keyword expansion will be limited to the specified keywords. For example, `admin -fyQ,M,Y' restricts keyword expansion so that `%Q%', `%M%' and `%Y%' are expanded, while other keywords such as `%Z%' are not. This flag is an extension introduced by Sun Solaris 8. See Interoperability for a discussion of the interoperability of CSSC with other SCCS implementations.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1.2 Modification Request Numbers

MRs are identifiers that can be specified when checking in a revision using `delta' (or even using `admin', when creating a file).

If the `v' ("validate") flag is set, the user running `delta' is prompted for MR numbers as well as revision comments. If this flag is not set, no validation is performed and no MR numbers are prompted for. If the `-m' option is given on the command line for `delta', the user is not prompted.

MR numbers are not required by CSSC to be actual numbers; they may contain any non-whitespace printable characters; other implementations may not be so flexible.

MR numbers are frequently used to tie code revisions to other things, for example engineering change management documents or bug-tracking databases. If your change management systems are computer-based, you can use the validation program to ensure that the offered MR number is valid and that the calling user is allowed to change the file.

The first argument passed to the validation program is the name of the g-file and the following arguments are the MR numbers offered. The validating program should return zero if all the MR numbers are acceptable.

One might think that it would be useful to associate the MR number with the action of checking out for a modification (get -e), but this is not possible with SCCS. If you want to do that kind of thing, you must use a more advanced system, for example GNU CVS.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]

This document was generated by Build on December, 22 2005 using texi2html 1.76.