This is cvs.info, produced by makeinfo version 4.5 from cvs.texinfo.
INFO-DIR-SECTION GNU Packages
START-INFO-DIR-ENTRY
* CVS: (cvs). Concurrent Versions System
END-INFO-DIR-ENTRY
INFO-DIR-SECTION Individual utilities
START-INFO-DIR-ENTRY
* cvs: (cvs)CVS commands. Concurrent Versions System
END-INFO-DIR-ENTRY
File: cvs.info, Node: admin options, Up: admin
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.
File: cvs.info, Node: annotate, Next: checkout, Prev: admin, Up: CVS commands
annotate--What revision modified each line of a file?
=====================================================
* Synopsis: annotate [options] files...
* Requires: repository.
* Changes: nothing.
For each file in FILES, print the head revision of the trunk,
together with information on the last modification for each line.
* Menu:
* annotate options:: annotate options
* annotate example:: annotate example
File: cvs.info, Node: annotate options, Next: annotate example, Up: annotate
annotate options
----------------
These standard options are supported by `annotate' (*note Common
options::, for a complete description of them):
`-l'
Local directory only, no recursion.
`-R'
Process directories recursively.
`-f'
Use head revision if tag/date not found.
`-F'
Annotate binary files.
`-r REVISION'
Annotate file as of specified revision/tag.
`-D DATE'
Annotate file as of specified date.
File: cvs.info, Node: annotate example, Prev: annotate options, Up: annotate
annotate example
----------------
For example:
$ cvs annotate ssfile
Annotations for ssfile
***************
1.1 (mary 27-Mar-96): ssfile line 1
1.2 (joe 28-Mar-96): ssfile line 2
The file `ssfile' currently contains two lines. The `ssfile line 1'
line was checked in by `mary' on March 27. Then, on March 28, `joe'
added a line `ssfile line 2', without modifying the `ssfile line 1'
line. This report doesn't tell you anything about lines which have
been deleted or replaced; you need to use `cvs diff' for that (*note
diff::).
The options to `cvs annotate' are listed in *Note Invoking CVS::,
and can be used to select the files and revisions to annotate. The
options are described in more detail there and in *Note Common
options::.
File: cvs.info, Node: checkout, Next: commit, Prev: annotate, Up: CVS commands
checkout--Check out sources for editing
=======================================
* Synopsis: checkout [options] modules...
* Requires: repository.
* Changes: working directory.
* Synonyms: co, get
Create or update a working directory containing copies of the source
files specified by MODULES. You must execute `checkout' before using
most of the other CVS commands, since most of them operate on your
working directory.
The MODULES are either symbolic names for some collection of source
directories and files, or paths to directories or files in the
repository. The symbolic names are defined in the `modules' file.
*Note modules::.
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
source 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).
The files created by `checkout' are created read-write, unless the
`-r' option to CVS (*note Global options::) is specified, the `CVSREAD'
environment variable is specified (*note Environment variables::), or a
watch is in effect for that file (*note Watches::).
Note that running `checkout' on a directory that was already built
by a prior `checkout' is also permitted. This is similar to specifying
the `-d' option to the `update' command in the sense that new
directories that have been created in the repository will appear in
your work area. However, `checkout' takes a module name whereas
`update' takes a directory name. Also to use `checkout' this way it
must be run from the top level directory (where you originally ran
`checkout' from), so before you run `checkout' to update an existing
directory, don't forget to change your directory to the top level
directory.
For the output produced by the `checkout' command see *Note update
output::.
* Menu:
* checkout options:: checkout options
* checkout examples:: checkout examples
File: cvs.info, Node: checkout options, Next: checkout examples, Up: checkout
checkout options
----------------
These standard options are supported by `checkout' (*note Common
options::, for a complete description of them):
`-D DATE'
Use the most recent revision no later than DATE. This option is
sticky, and implies `-P'. See *Note Sticky tags::, for more
information on sticky tags/dates.
`-f'
Only useful with the `-D DATE' or `-r TAG' flags. If no matching
revision is found, retrieve the most recent revision (instead of
ignoring the file).
`-k KFLAG'
Process keywords according to KFLAG. See *Note Keyword
substitution::. This option is sticky; future updates of this
file in this working directory will use the same KFLAG. The
`status' command can be viewed to see the sticky options. See
*Note Invoking CVS::, for more information on the `status' command.
`-l'
Local; run only in current working directory.
`-n'
Do not run any checkout program (as specified with the `-o' option
in the modules file; *note modules::).
`-P'
Prune empty directories. See *Note Moving directories::.
`-p'
Pipe files to the standard output.
`-R'
Checkout directories recursively. This option is on by default.
`-r TAG'
Use revision TAG. This option is sticky, and implies `-P'. See
*Note Sticky tags::, for more information on sticky tags/dates.
In addition to those, you can use these special command options with
`checkout':
`-A'
Reset any sticky tags, dates, or `-k' options. See *Note Sticky
tags::, for more information on sticky tags/dates.
`-c'
Copy the module file, sorted, to the standard output, instead of
creating or modifying any files or directories in your working
directory.
`-d DIR'
Create a directory called DIR for the working files, instead of
using the module name. In general, using this flag is equivalent
to using `mkdir DIR; cd DIR' followed by the checkout command
without the `-d' flag.
There is an important exception, however. It is very convenient
when checking out a single item to have the output appear in a
directory that doesn't contain empty intermediate directories. In
this case _only_, CVS tries to "shorten" pathnames to avoid those
empty directories.
For example, given a module `foo' that contains the file `bar.c',
the command `cvs co -d dir foo' will create directory `dir' and
place `bar.c' inside. Similarly, given a module `bar' which has
subdirectory `baz' wherein there is a file `quux.c', the command
`cvs co -d dir bar/baz' will create directory `dir' and place
`quux.c' inside.
Using the `-N' flag will defeat this behavior. Given the same
module definitions above, `cvs co -N -d dir foo' will create
directories `dir/foo' and place `bar.c' inside, while `cvs co -N -d
dir bar/baz' will create directories `dir/bar/baz' and place
`quux.c' inside.
`-j TAG'
With two `-j' options, merge changes from the revision specified
with the first `-j' option to the revision specified with the
second `j' option, into the working directory.
With one `-j' option, merge changes from the ancestor revision to
the revision specified with the `-j' option, into the working
directory. The ancestor revision is the common ancestor of the
revision which the working directory is based on, and the revision
specified in the `-j' option.
In addition, each -j option can contain an 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:
`-jSYMBOLIC_TAG:DATE_SPECIFIER'.
*Note Branching and merging::.
`-N'
Only useful together with `-d DIR'. With this option, CVS will
not "shorten" module paths in your working directory when you
check out a single module. See the `-d' flag for examples and a
discussion.
`-s'
Like `-c', but include the status of all modules, and sort it by
the status string. *Note modules::, for info about the `-s'
option that is used inside the modules file to set the module
status.
File: cvs.info, Node: checkout examples, Prev: checkout options, Up: checkout
checkout examples
-----------------
Get a copy of the module `tc':
$ cvs checkout tc
Get a copy of the module `tc' as it looked one day ago:
$ cvs checkout -D yesterday tc
File: cvs.info, Node: commit, Next: diff, Prev: checkout, Up: CVS commands
commit--Check files into the repository
=======================================
* Synopsis: commit [-lnRf] [-m 'log_message' | -F file] [-r
revision] [files...]
* Requires: working directory, repository.
* Changes: repository.
* Synonym: ci
Use `commit' when you want to incorporate changes from your working
source files into the 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.
`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 committing, if any of the specified files must be made
current first with `update' (*note 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 (*note
modules::, and *note loginfo::) and placed in the RCS file inside the
repository. This log message can be retrieved with the `log' command;
see *Note log::. You can specify the log message on the command line
with the `-m MESSAGE' option, and thus avoid the editor invocation, or
use the `-F FILE' option to specify that the argument file contains the
log message.
* Menu:
* commit options:: commit options
* commit examples:: commit examples
File: cvs.info, Node: commit options, Next: commit examples, Up: commit
commit options
--------------
These standard options are supported by `commit' (*note Common
options::, for a complete description of them):
`-l'
Local; run only in current working directory.
`-R'
Commit directories recursively. This is on by default.
`-r REVISION'
Commit to REVISION. REVISION must be either a branch, or a
revision on the main trunk that is higher than any existing
revision number (*note Assigning revisions::). You cannot commit
to a specific revision on a branch.
`commit' also supports these options:
`-F FILE'
Read the log message from FILE, instead of invoking an editor.
`-f'
Note that this is not the standard behavior of the `-f' option as
defined in *Note Common options::.
Force CVS to commit a new revision even if you haven't made any
changes to the file. If the current revision of FILE is 1.7, then
the following two commands are equivalent:
$ cvs commit -f FILE
$ cvs commit -r 1.8 FILE
The `-f' option disables recursion (i.e., it implies `-l'). To
force CVS to commit a new revision for all files in all
subdirectories, you must use `-f -R'.
`-m MESSAGE'
Use MESSAGE as the log message, instead of invoking an editor.
File: cvs.info, Node: commit examples, Prev: commit options, Up: commit
commit examples
---------------
Committing to a branch
......................
You can commit to a branch revision (one that has an even number of
dots) with the `-r' option. To create a branch revision, use the `-b'
option of the `rtag' or `tag' commands (*note Branching and merging::).
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 disturbing 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:
$ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module
$ cvs checkout -r FCS1_2_Patch product_module
$ cd product_module
[[ hack away ]]
$ cvs commit
This works automatically since the `-r' option is sticky.
Creating the branch after editing
.................................
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. Others can then checkout your experimental stuff and
utilize the full benefit of CVS conflict resolution. The scenario might
look like:
[[ hacked sources are present ]]
$ cvs tag -b EXPR1
$ cvs update -r EXPR1
$ cvs commit
The `update' command will make the `-r EXPR1' option sticky on all
files. Note that your changes to the files will never be removed by the
`update' command. The `commit' will automatically commit to the
correct branch, because the `-r' is sticky. You could also do like
this:
[[ hacked sources are present ]]
$ cvs tag -b EXPR1
$ cvs commit -r EXPR1
but then, only those files that were changed by you will have the `-r
EXPR1' sticky flag. If you hack away, and commit without specifying
the `-r EXPR1' flag, some files may accidentally end up on the main
trunk.
To work with you on the experimental change, others would simply do
$ cvs checkout -r EXPR1 whatever_module
File: cvs.info, Node: diff, Next: export, Prev: commit, Up: CVS commands
diff--Show differences between revisions
========================================
* Synopsis: diff [-lR] [-k kflag] [format_options] [[-r rev1 | -D
date1] [-r rev2 | -D date2]] [files...]
* Requires: working directory, repository.
* Changes: nothing.
The `diff' command is used to compare different revisions of files.
The default action is to compare your working files with the revisions
they were based on, and report any differences that are found.
If any file names are given, only those files are compared. If any
directories are given, all files under them will be compared.
The exit status for diff is different than for other CVS commands;
for details *Note Exit status::.
* Menu:
* diff options:: diff options
* diff examples:: diff examples
File: cvs.info, Node: diff options, Next: diff examples, Up: diff
diff options
------------
These standard options are supported by `diff' (*note Common
options::, for a complete description of them):
`-D DATE'
Use the most recent revision no later than DATE. See `-r' for how
this affects the comparison.
`-k KFLAG'
Process keywords according to KFLAG. See *Note Keyword
substitution::.
`-l'
Local; run only in current working directory.
`-R'
Examine directories recursively. This option is on by default.
`-r TAG'
Compare with revision TAG. Zero, one or two `-r' options can be
present. With no `-r' option, the working file will be compared
with the revision it was based on. With one `-r', that revision
will be compared to your current working file. With two `-r'
options those two revisions will be compared (and your working
file will not affect the outcome in any way).
One or both `-r' options can be replaced by a `-D DATE' option,
described above.
The following options specify the format of the output. They have
the same meaning as in GNU diff. Most options have two equivalent
names, one of which is a single letter preceded by `-', and the other
of which is a long name preceded by `--'.
`-LINES'
Show LINES (an integer) lines of context. This option does not
specify an output format by itself; it has no effect unless it is
combined with `-c' or `-u'. This option is obsolete. For proper
operation, `patch' typically needs at least two lines of context.
`-a'
Treat all files as text and compare them line-by-line, even if they
do not seem to be text.
`-b'
Ignore trailing white space and consider all other sequences of
one or more white space characters to be equivalent.
`-B'
Ignore changes that just insert or delete blank lines.
`--binary'
Read and write data in binary mode.
`--brief'
Report only whether the files differ, not the details of the
differences.
`-c'
Use the context output format.
`-C LINES'
`--context[=LINES]'
Use the context output format, showing LINES (an integer) lines of
context, or three if LINES is not given. For proper operation,
`patch' typically needs at least two lines of context.
`--changed-group-format=FORMAT'
Use FORMAT to output a line group containing differing lines from
both files in if-then-else format. *Note Line group formats::.
`-d'
Change the algorithm to perhaps find a smaller set of changes.
This makes `diff' slower (sometimes much slower).
`-e'
`--ed'
Make output that is a valid `ed' script.
`--expand-tabs'
Expand tabs to spaces in the output, to preserve the alignment of
tabs in the input files.
`-f'
Make output that looks vaguely like an `ed' script but has changes
in the order they appear in the file.
`-F REGEXP'
In context and unified format, for each hunk of differences, show
some of the last preceding line that matches REGEXP.
`--forward-ed'
Make output that looks vaguely like an `ed' script but has changes
in the order they appear in the file.
`-H'
Use heuristics to speed handling of large files that have numerous
scattered small changes.
`--horizon-lines=LINES'
Do not discard the last LINES lines of the common prefix and the
first LINES lines of the common suffix.
`-i'
Ignore changes in case; consider upper- and lower-case letters
equivalent.
`-I REGEXP'
Ignore changes that just insert or delete lines that match REGEXP.
`--ifdef=NAME'
Make merged if-then-else output using NAME.
`--ignore-all-space'
Ignore white space when comparing lines.
`--ignore-blank-lines'
Ignore changes that just insert or delete blank lines.
`--ignore-case'
Ignore changes in case; consider upper- and lower-case to be the
same.
`--ignore-matching-lines=REGEXP'
Ignore changes that just insert or delete lines that match REGEXP.
`--ignore-space-change'
Ignore trailing white space and consider all other sequences of
one or more white space characters to be equivalent.
`--initial-tab'
Output a tab rather than a space before the text of a line in
normal or context format. This causes the alignment of tabs in
the line to look normal.
`-L LABEL'
Use LABEL instead of the file name in the context format and
unified format headers.
`--label=LABEL'
Use LABEL instead of the file name in the context format and
unified format headers.
`--left-column'
Print only the left column of two common lines in side by side
format.
`--line-format=FORMAT'
Use FORMAT to output all input lines in if-then-else format.
*Note Line formats::.
`--minimal'
Change the algorithm to perhaps find a smaller set of changes.
This makes `diff' slower (sometimes much slower).
`-n'
Output RCS-format diffs; like `-f' except that each command
specifies the number of lines affected.
`-N'
`--new-file'
In directory comparison, if a file is found in only one directory,
treat it as present but empty in the other directory.
`--new-group-format=FORMAT'
Use FORMAT to output a group of lines taken from just the second
file in if-then-else format. *Note Line group formats::.
`--new-line-format=FORMAT'
Use FORMAT to output a line taken from just the second file in
if-then-else format. *Note Line formats::.
`--old-group-format=FORMAT'
Use FORMAT to output a group of lines taken from just the first
file in if-then-else format. *Note Line group formats::.
`--old-line-format=FORMAT'
Use FORMAT to output a line taken from just the first file in
if-then-else format. *Note Line formats::.
`-p'
Show which C function each change is in.
`--rcs'
Output RCS-format diffs; like `-f' except that each command
specifies the number of lines affected.
`--report-identical-files'
`-s'
Report when two files are the same.
`--show-c-function'
Show which C function each change is in.
`--show-function-line=REGEXP'
In context and unified format, for each hunk of differences, show
some of the last preceding line that matches REGEXP.
`--side-by-side'
Use the side by side output format.
`--speed-large-files'
Use heuristics to speed handling of large files that have numerous
scattered small changes.
`--suppress-common-lines'
Do not print common lines in side by side format.
`-t'
Expand tabs to spaces in the output, to preserve the alignment of
tabs in the input files.
`-T'
Output a tab rather than a space before the text of a line in
normal or context format. This causes the alignment of tabs in
the line to look normal.
`--text'
Treat all files as text and compare them line-by-line, even if they
do not appear to be text.
`-u'
Use the unified output format.
`--unchanged-group-format=FORMAT'
Use FORMAT to output a group of common lines taken from both files
in if-then-else format. *Note Line group formats::.
`--unchanged-line-format=FORMAT'
Use FORMAT to output a line common to both files in if-then-else
format. *Note Line formats::.
`-U LINES'
`--unified[=LINES]'
Use the unified output format, showing LINES (an integer) lines of
context, or three if LINES is not given. For proper operation,
`patch' typically needs at least two lines of context.
`-w'
Ignore white space when comparing lines.
`-W COLUMNS'
`--width=COLUMNS'
Use an output width of COLUMNS in side by side format.
`-y'
Use the side by side output format.
* Menu:
* Line group formats:: Line group formats
* Line formats:: Line formats
File: cvs.info, Node: Line group formats, Next: Line formats, Up: diff options
Line group formats
..................
Line group formats let you specify formats suitable for many
applications that allow if-then-else input, including programming
languages and text formatting languages. A line group format specifies
the output format for a contiguous group of similar lines.
For example, the following command compares the TeX file `myfile'
with the original version from the repository, and outputs a merged
file in which old regions are surrounded by `\begin{em}'-`\end{em}'
lines, and new regions are surrounded by `\begin{bf}'-`\end{bf}' lines.
cvs diff \
--old-group-format='\begin{em}
%<\end{em}
' \
--new-group-format='\begin{bf}
%>\end{bf}
' \
myfile
The following command is equivalent to the above example, but it is a
little more verbose, because it spells out the default line group
formats.
cvs diff \
--old-group-format='\begin{em}
%<\end{em}
' \
--new-group-format='\begin{bf}
%>\end{bf}
' \
--unchanged-group-format='%=' \
--changed-group-format='\begin{em}
%<\end{em}
\begin{bf}
%>\end{bf}
' \
myfile
Here is a more advanced example, which outputs a diff listing with
headers containing line numbers in a "plain English" style.
cvs diff \
--unchanged-group-format='' \
--old-group-format='-------- %dn line%(n=1?:s) deleted at %df:
%<' \
--new-group-format='-------- %dN line%(N=1?:s) added after %de:
%>' \
--changed-group-format='-------- %dn line%(n=1?:s) changed at %df:
%<-------- to:
%>' \
myfile
To specify a line group format, use one of the options listed below.
You can specify up to four line group formats, one for each kind of
line group. You should quote FORMAT, because it typically contains
shell metacharacters.
`--old-group-format=FORMAT'
These line groups are hunks containing only lines from the first
file. The default old group format is the same as the changed
group format if it is specified; otherwise it is a format that
outputs the line group as-is.
`--new-group-format=FORMAT'
These line groups are hunks containing only lines from the second
file. The default new group format is same as the changed group
format if it is specified; otherwise it is a format that outputs
the line group as-is.
`--changed-group-format=FORMAT'
These line groups are hunks containing lines from both files. The
default changed group format is the concatenation of the old and
new group formats.
`--unchanged-group-format=FORMAT'
These line groups contain lines common to both files. The default
unchanged group format is a format that outputs the line group
as-is.
In a line group format, ordinary characters represent themselves;
conversion specifications start with `%' and have one of the following
forms.
`%<'
stands for the lines from the first file, including the trailing
newline. Each line is formatted according to the old line format
(*note Line formats::).
`%>'
stands for the lines from the second file, including the trailing
newline. Each line is formatted according to the new line format.
`%='
stands for the lines common to both files, including the trailing
newline. Each line is formatted according to the unchanged line
format.
`%%'
stands for `%'.
`%c'C''
where C is a single character, stands for C. C may not be a
backslash or an apostrophe. For example, `%c':'' stands for a
colon, even inside the then-part of an if-then-else format, which
a colon would normally terminate.
`%c'\O''
where O is a string of 1, 2, or 3 octal digits, stands for the
character with octal code O. For example, `%c'\0'' stands for a
null character.
`FN'
where F is a `printf' conversion specification and N is one of the
following letters, stands for N's value formatted with F.
`e'
The line number of the line just before the group in the old
file.
`f'
The line number of the first line in the group in the old
file; equals E + 1.
`l'
The line number of the last line in the group in the old file.
`m'
The line number of the line just after the group in the old
file; equals L + 1.
`n'
The number of lines in the group in the old file; equals L -
F + 1.
`E, F, L, M, N'
Likewise, for lines in the new file.
The `printf' conversion specification can be `%d', `%o', `%x', or
`%X', specifying decimal, octal, lower case hexadecimal, or upper
case hexadecimal output respectively. After the `%' the following
options can appear in sequence: a `-' specifying
left-justification; an integer specifying the minimum field width;
and a period followed by an optional integer specifying the
minimum number of digits. For example, `%5dN' prints the number
of new lines in the group in a field of width 5 characters, using
the `printf' format `"%5d"'.
`(A=B?T:E)'
If A equals B then T else E. A and B are each either a decimal
constant or a single letter interpreted as above. This format
spec is equivalent to T if A's value equals B's; otherwise it is
equivalent to E.
For example, `%(N=0?no:%dN) line%(N=1?:s)' is equivalent to `no
lines' if N (the number of lines in the group in the new file) is
0, to `1 line' if N is 1, and to `%dN lines' otherwise.
File: cvs.info, Node: Line formats, Prev: Line group formats, Up: diff options
Line formats
............
Line formats control how each line taken from an input file is
output as part of a line group in if-then-else format.
For example, the following command outputs text with a one-column
change indicator to the left of the text. The first column of output
is `-' for deleted lines, `|' for added lines, and a space for
unchanged lines. The formats contain newline characters where newlines
are desired on output.
cvs diff \
--old-line-format='-%l
' \
--new-line-format='|%l
' \
--unchanged-line-format=' %l
' \
myfile
To specify a line format, use one of the following options. You
should quote FORMAT, since it often contains shell metacharacters.
`--old-line-format=FORMAT'
formats lines just from the first file.
`--new-line-format=FORMAT'
formats lines just from the second file.
`--unchanged-line-format=FORMAT'
formats lines common to both files.
`--line-format=FORMAT'
formats all lines; in effect, it sets all three above options
simultaneously.
In a line format, ordinary characters represent themselves;
conversion specifications start with `%' and have one of the following
forms.
`%l'
stands for the contents of the line, not counting its trailing
newline (if any). This format ignores whether the line is
incomplete.
`%L'
stands for the contents of the line, including its trailing newline
(if any). If a line is incomplete, this format preserves its
incompleteness.
`%%'
stands for `%'.
`%c'C''
where C is a single character, stands for C. C may not be a
backslash or an apostrophe. For example, `%c':'' stands for a
colon.
`%c'\O''
where O is a string of 1, 2, or 3 octal digits, stands for the
character with octal code O. For example, `%c'\0'' stands for a
null character.
`Fn'
where F is a `printf' conversion specification, stands for the
line number formatted with F. For example, `%.5dn' prints the
line number using the `printf' format `"%.5d"'. *Note Line group
formats::, for more about printf conversion specifications.
The default line format is `%l' followed by a newline character.
If the input contains tab characters and it is important that they
line up on output, you should ensure that `%l' or `%L' in a line format
is just after a tab stop (e.g. by preceding `%l' or `%L' with a tab
character), or you should use the `-t' or `--expand-tabs' option.
Taken together, the line and line group formats let you specify many
different formats. For example, the following command uses a format
similar to `diff''s normal format. You can tailor this command to get
fine control over `diff''s output.
cvs diff \
--old-line-format='< %l
' \
--new-line-format='> %l
' \
--old-group-format='%df%(f=l?:,%dl)d%dE
%<' \
--new-group-format='%dea%dF%(F=L?:,%dL)
%>' \
--changed-group-format='%df%(f=l?:,%dl)c%dF%(F=L?:,%dL)
%<---
%>' \
--unchanged-group-format='' \
myfile
File: cvs.info, Node: diff examples, Prev: diff options, Up: diff
diff examples
-------------
The following line produces a Unidiff (`-u' flag) between revision
1.14 and 1.19 of `backend.c'. Due to the `-kk' flag no keywords are
substituted, so differences that only depend on keyword substitution
are ignored.
$ cvs diff -kk -u -r 1.14 -r 1.19 backend.c
Suppose the experimental branch EXPR1 was based on a set of files
tagged RELEASE_1_0. To see what has happened on that branch, the
following can be used:
$ cvs diff -r RELEASE_1_0 -r EXPR1
A command like this can be used to produce a context diff between
two releases:
$ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs
If you are maintaining ChangeLogs, a command like the following just
before you commit your changes may help you write the ChangeLog entry.
All local modifications that have not yet been committed will be
printed.
$ cvs diff -u | less
File: cvs.info, Node: export, Next: history, Prev: diff, Up: CVS commands
export--Export sources from CVS, similar to checkout
====================================================
* Synopsis: export [-flNnR] [-r rev|-D date] [-k subst] [-d dir]
module...
* Requires: repository.
* Changes: current directory.
This command is a variant of `checkout'; use it when you want a copy
of the source for module without the CVS administrative directories.
For example, you might use `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 (and thus it always prunes empty directories).
One often would like to use `-kv' with `cvs export'. This causes
any keywords to be expanded such that an import done at some other site
will not lose the keyword revision information. But be aware that
doesn't handle an export containing binary files correctly. Also be
aware that after having used `-kv', one can no longer use the `ident'
command (which is part of the RCS suite--see ident(1)) which looks for
keyword strings. If you want to be able to use `ident' you must not
use `-kv'.
* Menu:
* export options:: export options
File: cvs.info, Node: export options, Up: export
export options
--------------
These standard options are supported by `export' (*note Common
options::, for a complete description of them):
`-D DATE'
Use the most recent revision no later than DATE.
`-f'
If no matching revision is found, retrieve the most recent
revision (instead of ignoring the file).
`-l'
Local; run only in current working directory.
`-n'
Do not run any checkout program.
`-R'
Export directories recursively. This is on by default.
`-r TAG'
Use revision TAG.
In addition, these options (that are common to `checkout' and
`export') are also supported:
`-d DIR'
Create a directory called DIR for the working files, instead of
using the module name. *Note checkout options::, for complete
details on how CVS handles this flag.
`-k SUBST'
Set keyword expansion mode (*note Substitution modes::).
`-N'
Only useful together with `-d DIR'. *Note checkout options::, for
complete details on how CVS handles this flag.
File: cvs.info, Node: history, Next: import, Prev: export, Up: CVS commands
history--Show status of files and users
=======================================
* Synopsis: history [-report] [-flags] [-options args] [files...]
* Requires: the file `$CVSROOT/CVSROOT/history'
* Changes: nothing.
CVS can keep a history file that tracks each use of the `checkout',
`commit', `rtag', `update', and `release' commands. You can use
`history' to display this information in various formats.
Logging must be enabled by creating the file
`$CVSROOT/CVSROOT/history'.
*Note: `history' uses `-f', `-l', `-n', and `-p' in ways that
conflict with the normal use inside CVS (*note Common options::).*
* Menu:
* history options:: history options