Man page for apt-get cvsnt Command
This tutorial shows the man page for man cvsnt in linux.
Open terminal with 'su' access and type the command as shown below:
man cvsnt
Result of the Command Execution shown below:
CVS(1) CVS(1)
NAME
cvs Concurrent Versions System
SYNOPSIS
cvs [ cvs_options ]
cvs_command [ command_options ] [ command_args ]
NOTE
This manpage is a summary of some of the features of cvs but for more in depth documentation, consult the Cederqvist manual (as described in the SEE ALSO
section of this manpage).
DESCRIPTION
CVS is a version control system, which allows you to keep old versions of files (usually source code), keep a log of who, when, and why changes occurred,
etc., like RCS or SCCS. Unlike the simpler systems, CVS does not just operate on one file at a time or one directory at a time, but operates on hierarchical
collections of directories consisting of version controlled files. CVS helps to manage releases and to control the concurrent editing of source files among
multiple authors. CVS allows triggers to enable/log/control various operations and works well over a wide area network.
cvs keeps a single copy of the master sources. This copy is called the source ``repository''; it contains all the information to permit extracting previous
software releases at any time based on either a symbolic revision tag, or a date in the past.
ESSENTIAL COMMANDS
cvs provides a rich variety of commands (cvs_command in the Synopsis), each of which often has a wealth of options, to satisfy the many needs of source man
agement in distributed environments. However, you don't have to master every detail to do useful work with cvs; in fact, five commands are sufficient to use
(and contribute to) the source repository.
cvs checkout modules...
A necessary preliminary for most cvs work: creates your private copy of the source for modules (named collections of source; you can also use a path
relative to the source repository here). You can work with this copy without interfering with others' work. At least one subdirectory level is
always created.
cvs update
Execute this command from within your private source directory when you wish to update your copies of source files from changes that other developers
have made to the source in the repository.
cvs add file...
Use this command to enroll new files in cvs records of your working directory. The files will be added to the repository the next time you run `cvs
commit'. Note: You should use the `cvs import' command to bootstrap new sources into the source repository. `cvs add' is only used for new files to
an already checked out module.
cvs remove file...
Use this command (after erasing any files listed) to declare that you wish to eliminate files from the repository. The removal does not affect others
until you run `cvs commit'.
cvs commit file...
Use this command when you wish to ``publish'' your changes to other developers, by incorporating them in the source repository.
OPTIONS
The cvs command line can include cvs_options, which apply to the overall cvs program; a cvs_command, which specifies a particular action on the source repos
itory; and command_options and command_arguments to fully specify what the cvs_command will do.
Warning: you must be careful of precisely where you place options relative to the cvs_command. The same option can mean different things depending on
whether it is in the cvs_options position (to the left of a cvs command) or in the command_options position (to the right of a cvs command).
There are only two situations where you may omit cvs_command: `cvs H' or `cvs help' elicits a list of available commands, and `cvs v' or `cvs version'
displays version information on cvs itself.
CVS OPTIONS
As of release 1.6, cvs supports GNU style long options as well as short options. Only a few long options are currently supported, these are listed in brack
ets after the short options whose functions they duplicate.
Use these options to control the overall cvs program:
H [ help ]
Display usage information about the specified cvs_command (but do not actually execute the command). If you don't specify a command name, `cvs H'
displays a summary of all the commands available.
Q Causes the command to be really quiet; the command will generate output only for serious problems.
q Causes the command to be somewhat quiet; informational messages, such as reports of recursion through subdirectories, are suppressed.
b bindir
Use bindir as the directory where RCS programs are located (CVS 1.9 and older). Overrides the setting of the RCSBIN environment variable. This value
should be specified as an absolute pathname.
d CVS_root_directory
Use CVS_root_directory as the root directory pathname of the master source repository. Overrides the setting of the CVSROOT environment variable.
This value should be specified as an absolute pathname.
D CVS_prefix_directory
Use CVS_prefix_directory as the filename prefix to all repositories. This value should be specified as an absolute pathname.
e editor
Use editor to enter revision log information. Overrides the setting of the CVSEDITOR, VISUAL, and EDITOR environment variables.
f Do not read the cvs startup file (~/.cvsrc).
l Do not log the cvs_command in the command history (but execute it anyway). See the description of the history command for information on command his
tory.
n Do not change any files. Attempt to execute the cvs_command, but only to issue reports; do not remove, update, or merge any existing files, or create
any new files.
t Trace program execution; display messages showing the steps of cvs activity. Particularly useful with n to explore the potential impact of an unfa
miliar command.
r Makes new working files read only. Same effect as if the CVSREAD environment variable is set.
v [ version ]
Displays version and copyright information for cvs.
w Makes new working files read write (default). Overrides the setting of the CVSREAD environment variable.
x Encrypt all communication between the client and the server. As of this writing, this is only implemented when using a Kerberos connection.
z compression level
When transferring files across the network use gzip with compression level compression level to compress and de compress data as it is transferred.
Requires the presence of the GNU gzip program in the current search path at both ends of the link.
USAGE
Except when requesting general help with `cvs H', you must specify a cvs_command to cvs to select a specific release control function to perform. Each cvs
command accepts its own collection of options and arguments. However, many options are available across several commands. You can display a usage summary
for each command by specifying the H option with the command.
CVS STARTUP FILE
Normally, when CVS starts up, it reads the .cvsrc file from the home directory of the user reading it. This startup procedure can be turned off with the f
flag.
The .cvsrc file lists CVS commands with a list of arguments, one command per line. For example, the following line in .cvsrc:
diff c
will mean that the `cvs diff' command will always be passed the c option in addition to any other options that are specified in the command line (in this
case it will have the effect of producing context sensitive diffs for all executions of `cvs diff' ).
CVS COMMAND SUMMARY
Here are brief descriptions of all the cvs commands:
add Add a new file or directory to the repository, pending a `cvs commit' on the same file. Can only be done from within sources created by a previous
`cvs checkout' invocation. Use `cvs import' to place whole new hierarchies of sources under cvs control. (Does not directly affect repository;
changes working directory.)
admin Execute control functions on the source repository. (Changes repository directly; uses working directory without changing it.)
checkout
Make a working directory of source files for editing. (Creates or changes working directory.)
commit Apply to the source repository changes, additions, and deletions from your working directory. (Changes repository.)
diff Show differences between files in working directory and source repository, or between two revisions in source repository. (Does not change either
repository or working directory.)
export Prepare copies of a set of source files for shipment off site. Differs from `cvs checkout' in that no cvs administrative directories are created (and
therefore `cvs commit' cannot be executed from a directory prepared with `cvs export'), and a symbolic tag must be specified. (Does not change repos
itory; creates directory similar to working directories).
history
Show reports on cvs commands that you or others have executed on a particular file or directory in the source repository. (Does not change repository
or working directory.) History logs are kept only if enabled by creation of the `$CVSROOT/CVSROOT/history' file; see cvs(5).
import Incorporate a set of updates from off site into the source repository, as a ``vendor branch''. (Changes repository.)
init Initialize a repository by adding the CVSROOT subdirectory and some default control files. You must use this command or initialize the repository in
some other way before you can use it.
log Display log information. (Does not change repository or working directory.)
rdiff Prepare a collection of diffs as a patch file between two releases in the repository. (Does not change repository or working directory.)
release
Cancel a `cvs checkout', abandoning any changes. (Can delete working directory; no effect on repository.)
remove Remove files from the source repository, pending a `cvs commit' on the same files. (Does not directly affect repository; changes working directory.)
rtag Explicitly specify a symbolic tag for particular revisions of files in the source repository. See also `cvs tag'. (Changes repository directly; does
not require or affect working directory.)
status Show current status of files: latest version, version in working directory, whether working version has been edited and, optionally, symbolic tags in
the RCS file. (Does not change repository or working directory.)
tag Specify a symbolic tag for files in the repository. By default, tags the revisions that were last synchronized with your working directory.
(Changes repository directly; uses working directory without changing it.)
update Bring your working directory up to date with changes from the repository. Merges are performed automatically when possible; a warning is issued if
manual resolution is required for conflicting changes. (Changes working directory; does not change repository.)
COMMON COMMAND OPTIONS
This section describes the command_options that are available across several cvs commands. Not all commands support all of these options; each option is
only supported for commands where it makes sense. However, when a command has one of these options you can count on the same meaning for the option as in
other commands. (Other command options, which are listed with the individual commands, may have different meanings from one cvs command to another.) Warn
ing: the history command is an exception; it supports many options that conflict even with these standard options.
D date_spec
Use the most recent revision no later than date_spec (a single argument, date description specifying a date in the past). A wide variety of date for
mats are supported, in particular ISO ("1972 09 24 20:05") or Internet ("24 Sep 1972 20:05"). The date_spec is interpreted as being in the local
timezone, unless a specific timezone is specified. The specification is ``sticky'' when you use it to make a private copy of a source file; that is,
when you get a working file using D, cvs records the date you specified, so that further updates in the same directory will use the same date (unless
you explicitly override it; see the description of the update command). D is available with the checkout, diff, history, export, rdiff, rtag, and
update commands. Examples of valid date specifications include:
1 month ago
2 hours ago
400000 seconds ago
last year
last Monday
yesterday
a fortnight ago
3/31/92 10:00:07 PST
January 23, 1987 10:05pm
22:00 GMT
f When you specify a particular date or tag to cvs commands, they normally ignore files that do not contain the tag (or did not exist on the date) that
you specified. Use the f option if you want files retrieved even when there is no match for the tag or date. (The most recent version is used in
this situation.) f is available with these commands: checkout, export, rdiff, rtag, and update.
k kflag
Alter the default processing of keywords. The k option is available with the add, checkout, diff, export, rdiff, and update commands. Your kflag
specification is ``sticky'' when you use it to create a private copy of a source file; that is, when you use this option with the checkout or update
commands, cvs associates your selected kflag with the file, and continues to use it with future update commands on the same file until you specify
otherwise.
Some of the more useful kflags are ko and kb (for binary files), and kv which is useful for an export where you wish to retain keyword information
after an import at some other site.
l Local; run only in current working directory, rather than recurring through subdirectories. Available with the following commands: checkout, commit,
diff, export, remove, rdiff, rtag, status, tag, and update. Warning: this is not the same as the overall `cvs l' option, which you can specify to
the left of a cvs command!
n Do not run any checkout/commit/tag/update program. (A program can be specified to run on each of these activities, in the modules database; this
option bypasses it.) Available with the checkout, commit, export, and rtag commands. Warning: this is not the same as the overall `cvs n' option,
which you can specify to the left of a cvs command!
P Prune (remove) directories that are empty after being updated, on checkout, or update. Normally, an empty directory (one that is void of revision
controlled files) is left alone. Specifying P will cause these directories to be silently removed from your checked out sources. This does not
remove the directory from the repository, only from your checked out copy. Note that this option is implied by the r or D options of checkout and
export.
p Pipe the files retrieved from the repository to standard output, rather than writing them in the current directory. Available with the checkout and
update commands.
r tag Use the revision specified by the tag argument instead of the default ``head'' revision. As well as arbitrary tags defined with the tag or rtag com
mand, two special tags are always available: `HEAD' refers to the most recent version available in the repository, and `BASE' refers to the revision
you last checked out into the current working directory.
The tag specification is ``sticky'' when you use this option with `cvs checkout' or `cvs update' to make your own copy of a file: cvs remembers the
tag and continues to use it on future update commands, until you specify otherwise. tag can be either a symbolic or numeric tag. Specifying the q
global option along with the r command option is often useful, to suppress the warning messages when the RCS file does not contain the specified tag.
r is available with the checkout, commit, diff, history, export, rdiff, rtag, and update commands. Warning: this is not the same as the overall `cvs
r' option, which you can specify to the left of a cvs command!
CVS COMMANDS
Here (finally) are details on all the cvs commands and the options each accepts. The summary lines at the top of each command's description highlight three
kinds of things:
Command Options and Arguments
Special options are described in detail below; common command options may appear only in the summary line.
Working Directory, or Repository?
Some cvs commands require a working directory to operate; some require a repository. Also, some commands change the repository, some change the
working directory, and some change nothing.
Synonyms
Many commands have synonyms, which you may find easier to remember (or type) than the principal name.
add [ k kflag] [ m 'message'] files...
Requires: repository, working directory.
Changes: working directory.
Synonym: new
Use the add command to create a new file or directory in the source repository. The files or directories specified with add must already exist in the
current directory (which must have been created with the checkout command). To add a whole new directory hierarchy to the source repository (for
example, files received from a third party vendor), use the `cvs import' command instead.
If the argument to `cvs add' refers to an immediate sub directory, the directory is created at the correct place in the source repository, and the
necessary cvs administration files are created in your working directory. If the directory already exists in the source repository, `cvs add' still
creates the administration files in your version of the directory. This allows you to use `cvs add' to add a particular directory to your private
sources even if someone else created that directory after your checkout of the sources. You can do the following:
example% mkdir new_directory
example% cvs add new_directory
example% cvs update new_directory
An alternate approach using `cvs update' might be:
example% cvs update d new_directory
(To add any available new directories to your working directory, it's probably simpler to use `cvs checkout' or `cvs update d'.)
The added files are not placed in the source repository until you use `cvs commit' to make the change permanent. Doing a `cvs add' on a file that was
removed with the `cvs remove' command will resurrect the file, if no `cvs commit' command intervened.
You will have the opportunity to specify a logging message, as usual, when you use `cvs commit' to make the new file permanent. If you'd like to have
another logging message associated with just creation of the file (for example, to describe the file's purpose), you can specify it with the ` m mes
sage' option to the add command.
The ` k kflag' option specifies the default way that this file will be checked out. The `kflag' argument is stored in the RCS file and can be changed
with `cvs admin'. Specifying ` ko' is useful for checking in binaries that shouldn't have keywords expanded.
admin [rcs options] files...
Requires: repository, working directory.
Changes: repository.
Synonym: rcs
This is the cvs interface to assorted administrative facilities, similar to rcs(1). This command works recursively, so extreme care should be used.
checkout [options] modules...
Requires: repository.
Changes: working directory.
Synonyms: co, get
Make a working directory containing copies of the source files specified by modules. You must execute `cvs checkout' before using most of the other
cvs commands, since most of them operate on your working directory.
modules are either symbolic names (themselves defined as the module `modules' in the source repository; see cvs(5)) for some collection of source
directories and files, or paths to directories or files in the repository.
Depending on the modules you specify, checkout may recursively create directories and populate them with the appropriate source files. You can then
edit these source files at any time (regardless of whether other software developers are editing their own copies of the sources); update them to
include new changes applied by others to the source repository; or commit your work as a permanent change to the repository.
Note that checkout is used to create directories. The top level directory created is always added to the directory where checkout is invoked, and
usually has the same name as the specified module. In the case of a module alias, the created sub directory may have a different name, but you can be
sure that it will be a sub directory, and that checkout will show the relative path leading to each file as it is extracted into your private work
area (unless you specify the Q global option).
Running `cvs checkout' on a directory that was already built by a prior checkout is also permitted, and has the same effect as specifying the d
option to the update command described below.
The options permitted with `cvs checkout' include the standard command options P, f, k kflag , l, n, p, r tag, and D date.
In addition to those, you can use these special command options with checkout:
Use the A option to reset any sticky tags, dates, or k options. (If you get a working file using one of the r, D, or k options, cvs remembers
the corresponding tag, date, or kflag and continues using it on future updates; use the A option to make cvs forget these specifications, and
retrieve the ``head'' version of the file).
The j branch option merges the changes made between the resulting revision and the revision that it is based on (e.g., if the tag refers to a branch,
cvs will merge all changes made in that branch into your working file).
With two j options, cvs will merge in the changes between the two respective revisions. This can be used to ``remove'' a certain delta from your
working file.
In addition, each j option can contain on optional date specification which, when used with branches, can limit the chosen revision to one within a
specific date. An optional date is specified by adding a colon (:) to the tag. An example might be what `cvs import' tells you to do when you have
just imported sources that have conflicts with local changes:
example% cvs checkout jTAG:yesterday jTAG module
Use the N option with ` d dir' to avoid shortening module paths in your working directory. (Normally, cvs shortens paths as much as possible when
you specify an explicit target directory.)
Use the c option to copy the module file, sorted, to the standard output, instead of creating or modifying any files or directories in your working
directory.
Use the d dir option to create a directory called dir for the working files, instead of using the module name. Unless you also use N, the paths
created under dir will be as short as possible.
Use the s option to display per module status information stored with the s option within the modules file.
commit [ lnR] [ m 'log_message' | f file] [ r revision] [files...]
Requires: working directory, repository.
Changes: repository.
Synonym: ci
Use `cvs commit' when you want to incorporate changes from your working source files into the general source repository.
If you don't specify particular files to commit, all of the files in your working current directory are examined. commit is careful to change in the
repository only those files that you have really changed. By default (or if you explicitly specify the R option), files in subdirectories are also
examined and committed if they have changed; you can use the l option to limit commit to the current directory only. Sometimes you may want to force
a file to be committed even though it is unchanged; this is achieved with the f flag, which also has the effect of disabling recursion (you can turn
it back on with R of course).
commit verifies that the selected files are up to date with the current revisions in the source repository; it will notify you, and exit without com
mitting, if any of the specified files must be made current first with `cvs update'. commit does not call the update command for you, but rather
leaves that for you to do when the time is right.
When all is well, an editor is invoked to allow you to enter a log message that will be written to one or more logging programs and placed in the
source repository file. You can instead specify the log message on the command line with the m option, thus suppressing the editor invocation, or
use the F option to specify that the argument file contains the log message.
The r option can be used to commit to a particular symbolic or numeric revision. For example, to bring all your files up to the revision ``3.0''
(including those that haven't changed), you might do:
example% cvs commit r3.0
cvs will only allow you to commit to a revision that is on the main trunk (a revision with a single dot). However, you can also commit to a branch
revision (one that has an even number of dots) with the r option. To create a branch revision, one typically use the b option of the rtag or tag
commands. Then, either checkout or update can be used to base your sources on the newly created branch. From that point on, all commit changes made
within these working sources will be automatically added to a branch revision, thereby not perturbing main line development in any way. For example,
if you had to create a patch to the 1.2 version of the product, even though the 2.0 version is already under development, you might do:
example% cvs rtag b rFCS1_2 FCS1_2_Patch product_module
example% cvs checkout rFCS1_2_Patch product_module
example% cd product_module
[[ hack away ]]
example% cvs commit
Say you have been working on some extremely experimental software, based on whatever revision you happened to checkout last week. If others in your
group would like to work on this software with you, but without disturbing main line development, you could commit your change to a new branch. Oth
ers can then checkout your experimental stuff and utilize the full benefit of cvs conflict resolution. The scenario might look like:
example% cvs tag b EXPR1
example% cvs update rEXPR1
[[ hack away ]]
example% cvs commit
Others would simply do `cvs checkout rEXPR1 whatever_module' to work with you on the experimental change.
diff [ kl] [rcsdiff_options] [[ r rev1 | D date1] [ r rev2 | D date2]] [files...]
Requires: working directory, repository.
Changes: nothing.
You can compare your working files with revisions in the source repository, with the `cvs diff' command. If you don't specify a particular revision,
your files are compared with the revisions they were based on. You can also use the standard cvs command option r to specify a particular revision
to compare your files with. Finally, if you use r twice, you can see differences between two revisions in the repository. You can also specify D
options to diff against a revision in the past. The r and D options can be mixed together with at most two options ever specified.
See rcsdiff(1) for a list of other accepted options.
If you don't specify any files, diff will display differences for all those files in the current directory (and its subdirectories, unless you use the
standard option l) that differ from the corresponding revision in the source repository (i.e. files that you have changed), or that differ from the
revision specified.
export [ flNnQq] r rev| D date [ d dir] [ k kflag] module...
Requires: repository.
Changes: current directory.
This command is a variant of `cvs checkout'; use it when you want a copy of the source for module without the cvs administrative directories. For
example, you might use `cvs export' to prepare source for shipment off site. This command requires that you specify a date or tag (with D or r), so
that you can count on reproducing the source you ship to others.
The only non standard options are ` d dir' (write the source into directory dir) and ` N' (don't shorten module paths). These have the same meanings
as the same options in `cvs checkout'.
The kv option is useful when export is used. This causes any keywords to be expanded such that an import done at some other site will not lose the
keyword revision information. Other kflags may be used with `cvs export' and are described in co(1).
history [ report] [ flags] [ options args] [files...]
Requires: the file `$CVSROOT/CVSROOT/history'
Changes: nothing.
cvs keeps a history file that tracks each use of the checkout, commit, rtag, update, and release commands. You can use `cvs history' to display this
information in various formats.
Warning: `cvs history' uses ` f', ` l', ` n', and ` p' in ways that conflict with the descriptions in COMMON COMMAND OPTIONS.
Several options (shown above as report) control what kind of report is generated:
c Report on each time commit was used (i.e., each time the repository was modified).
m module
Report on a particular module. (You can meaningfully use m more than once
Español
русский
中国