GNU Info
(cvs.info)admin options
admin options
-------------
Some of these options have questionable usefulness for CVS but exist
for historical purposes. Some even make it impossible to use CVS until
you undo the effect!
`-AOLDFILE'
Might not work together with CVS. Append the access list of
OLDFILE to the access list of the RCS file.
`-aLOGINS'
Might not work together with CVS. Append the login names
appearing in the comma-separated list LOGINS to the access list of
the RCS file.
`-b[REV]'
Set the default branch to REV. In CVS, you normally do not
manipulate default branches; sticky tags (Note: Sticky tags) are
a better way to decide which branch you want to work on. There is
one reason to run `cvs admin -b': to revert to the vendor's
version when using vendor branches (Note: Reverting local
changes). There can be no space between `-b' and its argument.
`-cSTRING'
Sets the comment leader to STRING. The comment leader is not used
by current versions of CVS or RCS 5.7. Therefore, you can almost
surely not worry about it. Note: Keyword substitution.
`-e[LOGINS]'
Might not work together with CVS. Erase the login names appearing
in the comma-separated list LOGINS from the access list of the RCS
file. If LOGINS is omitted, erase the entire access list. There
can be no space between `-e' and its argument.
`-I'
Run interactively, even if the standard input is not a terminal.
This option does not work with the client/server CVS and is likely
to disappear in a future release of CVS.
`-i'
Useless with CVS. This creates and initializes a new RCS file,
without depositing a revision. With CVS, add files with the `cvs
add' command (Note: Adding files).
`-kSUBST'
Set the default keyword substitution to SUBST. Note: Keyword
substitution. Giving an explicit `-k' option to `cvs update',
`cvs export', or `cvs checkout' overrides this default.
`-l[REV]'
Lock the revision with number REV. If a branch is given, lock the
latest revision on that branch. If REV is omitted, lock the
latest revision on the default branch. There can be no space
between `-l' and its argument.
This can be used in conjunction with the `rcslock.pl' script in
the `contrib' directory of the CVS source distribution to provide
reserved checkouts (where only one user can be editing a given
file at a time). See the comments in that file for details (and
see the `README' file in that directory for disclaimers about the
unsupported nature of contrib). According to comments in that
file, locking must set to strict (which is the default).
`-L'
Set locking to strict. Strict locking means that the owner of an
RCS file is not exempt from locking for checkin. For use with
CVS, strict locking must be set; see the discussion under the `-l'
option above.
`-mREV:MSG'
Replace the log message of revision REV with MSG.
`-NNAME[:[REV]]'
Act like `-n', except override any previous assignment of NAME.
For use with magic branches, see Note: Magic branch numbers.
`-nNAME[:[REV]]'
Associate the symbolic name NAME with the branch or revision REV.
It is normally better to use `cvs tag' or `cvs rtag' instead.
Delete the symbolic name if both `:' and REV are omitted;
otherwise, print an error message if NAME is already associated
with another number. If REV is symbolic, it is expanded before
association. A REV consisting of a branch number followed by a
`.' stands for the current latest revision in the branch. A `:'
with an empty REV stands for the current latest revision on the
default branch, normally the trunk. For example, `cvs admin
-nNAME:' associates NAME with the current latest revision of all
the RCS files; this contrasts with `cvs admin -nNAME:$' which
associates NAME with the revision numbers extracted from keyword
strings in the corresponding working files.
`-oRANGE'
Deletes ("outdates") the revisions given by RANGE.
Note that this command can be quite dangerous unless you know
_exactly_ what you are doing (for example see the warnings below
about how the REV1:REV2 syntax is confusing).
If you are short on disc this option might help you. But think
twice before using it--there is no way short of restoring the
latest backup to undo this command! If you delete different
revisions than you planned, either due to carelessness or (heaven
forbid) a CVS bug, there is no opportunity to correct the error
before the revisions are deleted. It probably would be a good
idea to experiment on a copy of the repository first.
Specify RANGE in one of the following ways:
`REV1::REV2'
Collapse all revisions between rev1 and rev2, so that CVS
only stores the differences associated with going from rev1
to rev2, not intermediate steps. For example, after `-o
1.3::1.5' one can retrieve revision 1.3, revision 1.5, or the
differences to get from 1.3 to 1.5, but not the revision 1.4,
or the differences between 1.3 and 1.4. Other examples: `-o
1.3::1.4' and `-o 1.3::1.3' have no effect, because there are
no intermediate revisions to remove.
`::REV'
Collapse revisions between the beginning of the branch
containing REV and REV itself. The branchpoint and REV are
left intact. For example, `-o ::1.3.2.6' deletes revision
1.3.2.1, revision 1.3.2.5, and everything in between, but
leaves 1.3 and 1.3.2.6 intact.
`REV::'
Collapse revisions between REV and the end of the branch
containing REV. Revision REV is left intact but the head
revision is deleted.
`REV'
Delete the revision REV. For example, `-o 1.3' is equivalent
to `-o 1.2::1.4'.
`REV1:REV2'
Delete the revisions from REV1 to REV2, inclusive, on the
same branch. One will not be able to retrieve REV1 or REV2
or any of the revisions in between. For example, the command
`cvs admin -oR_1_01:R_1_02 .' is rarely useful. It means to
delete revisions up to, and including, the tag R_1_02. But
beware! If there are files that have not changed between
R_1_02 and R_1_03 the file will have _the same_ numerical
revision number assigned to the tags R_1_02 and R_1_03. So
not only will it be impossible to retrieve R_1_02; R_1_03
will also have to be restored from the tapes! In most cases
you want to specify REV1::REV2 instead.
`:REV'
Delete revisions from the beginning of the branch containing
REV up to and including REV.
`REV:'
Delete revisions from revision REV, including REV itself, to
the end of the branch containing REV.
None of the revisions to be deleted may have branches or locks.
If any of the revisions to be deleted have symbolic names, and one
specifies one of the `::' syntaxes, then CVS will give an error
and not delete any revisions. If you really want to delete both
the symbolic names and the revisions, first delete the symbolic
names with `cvs tag -d', then run `cvs admin -o'. If one
specifies the non-`::' syntaxes, then CVS will delete the
revisions but leave the symbolic names pointing to nonexistent
revisions. This behavior is preserved for compatibility with
previous versions of CVS, but because it isn't very useful, in the
future it may change to be like the `::' case.
Due to the way CVS handles branches REV cannot be specified
symbolically if it is a branch. Note: Magic branch numbers, for
an explanation.
Make sure that no-one has checked out a copy of the revision you
outdate. Strange things will happen if he starts to edit it and
tries to check it back in. For this reason, this option is not a
good way to take back a bogus commit; commit a new revision
undoing the bogus change instead (Note: Merging two revisions).
`-q'
Run quietly; do not print diagnostics.
`-sSTATE[:REV]'
Useful with CVS. Set the state attribute of the revision REV to
STATE. If REV is a branch number, assume the latest revision on
that branch. If REV is omitted, assume the latest revision on the
default branch. Any identifier is acceptable for STATE. A useful
set of states is `Exp' (for experimental), `Stab' (for stable),
and `Rel' (for released). By default, the state of a new revision
is set to `Exp' when it is created. The state is visible in the
output from CVS LOG (Note: log), and in the `$Log$' and
`$State$' keywords (Note: Keyword substitution). Note that CVS
uses the `dead' state for its own purposes; to take a file to or
from the `dead' state use commands like `cvs remove' and `cvs
add', not `cvs admin -s'.
`-t[FILE]'
Useful with CVS. Write descriptive text from the contents of the
named FILE into the RCS file, deleting the existing text. The
FILE pathname may not begin with `-'. The descriptive text can be
seen in the output from `cvs log' (Note: log). There can be no
space between `-t' and its argument.
If FILE is omitted, obtain the text from standard input,
terminated by end-of-file or by a line containing `.' by itself.
Prompt for the text if interaction is possible; see `-I'.
`-t-STRING'
Similar to `-tFILE'. Write descriptive text from the STRING into
the RCS file, deleting the existing text. There can be no space
between `-t' and its argument.
`-U'
Set locking to non-strict. Non-strict locking means that the
owner of a file need not lock a revision for checkin. For use
with CVS, strict locking must be set; see the discussion under the
`-l' option above.
`-u[REV]'
See the option `-l' above, for a discussion of using this option
with CVS. Unlock the revision with number REV. If a branch is
given, unlock the latest revision on that branch. If REV is
omitted, remove the latest lock held by the caller. Normally,
only the locker of a revision may unlock it; somebody else
unlocking a revision breaks the lock. This causes the original
locker to be sent a `commit' notification (Note: Getting
Notified). There can be no space between `-u' and its argument.
`-VN'
In previous versions of CVS, this option meant to write an RCS
file which would be acceptable to RCS version N, but it is now
obsolete and specifying it will produce an error.
`-xSUFFIXES'
In previous versions of CVS, this was documented as a way of
specifying the names of the RCS files. However, CVS has always
required that the RCS files used by CVS end in `,v', so this
option has never done anything useful.
automatically generated by info2www version 1.2.2.9