-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 (see 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 (see 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. See 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.
|
-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
(see Adding files).
|
-ksubst
|
Set the default keyword
substitution to subst. See 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 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.
See 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 (see 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 (see log), and in the
`$Log$ ' and `$State$ ' keywords
(see 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 ' (see 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 '. Reading from standard input does not work
for client/server CVS and may change in a future
release of CVS.
|
-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 a mail message to be sent to the original
locker. The message contains a commentary solicited
from the breaker. The commentary is terminated by
end-of-file or by a line containing . by itself.
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.
|