<div id="Revisions"></div>
<div class="header">
<p>
Next: [[cvs: Branching and merging#Branching and merging|Branching and merging]], Previous: [[cvs: Starting a project with CVS#Starting a project with CVS|Starting a new project]], Up: [[cvs#Top|Top]] &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
</div>
<div id="Revisions-1"></div>
== Revisions ==

For many uses of <small>CVS</small>, one doesn&rsquo;t need to worry
too much about revision numbers; <small>CVS</small> assigns
numbers such as <code>1.1</code>, <code>1.2</code>, and so on, and
that is all one needs to know.  However, some people
prefer to have more knowledge and control concerning
how <small>CVS</small> assigns revision numbers.

If one wants to keep track of a set of revisions
involving more than one file, such as which revisions
went into a particular release, one uses a <em>tag</em>,
which is a symbolic revision which can be assigned to a
numeric revision in each file.

<div class="menu-preformatted" style="font-family: serif">
 [[#Revision numbers|&bull; Revision numbers]]::            The meaning of a revision number
 [[#Versions, revisions and releases|&bull; Versions revisions releases]]::  Terminology used in this manual
 [[#Assigning revisions|&bull; Assigning revisions]]::         Assigning revisions
 [[#Tags&ndash;Symbolic revisions|&bull; Tags]]::                        Tags&ndash;Symbolic revisions
 [[#Specifying what to tag from the working directory|&bull; Tagging the working directory]]::  The cvs tag command
 [[#Specifying what to tag by date or revision|&bull; Tagging by date/tag]]::         The cvs rtag command
 [[#Deleting, moving, and renaming tags|&bull; Modifying tags]]::              Adding, renaming, and deleting tags
 [[#Tagging and adding and removing files|&bull; Tagging add/remove]]::          Tags with adding and removing files
 [[#Sticky tags|&bull; Sticky tags]]::                 Certain tags are persistent
</div>


----

<div id="Revision-numbers"></div>
<div class="header">
<p>
Next: [[#Versions, revisions and releases|Versions revisions releases]], Up: [[#Revisions|Revisions]] &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
</div>
<div id="Revision-numbers-1"></div>
=== Revision numbers ===
<div id="index-Revision-numbers"></div>
<div id="index-Revision-tree"></div>
<div id="index-Linear-development"></div>
<div id="index-Number_002c-revision_002d"></div>
<div id="index-Decimal-revision-number"></div>
<div id="index-Branch-number"></div>
<div id="index-Number_002c-branch"></div>

Each version of a file has a unique <em>revision
number</em>.  Revision numbers look like &lsquo;<code>1.1</code>&rsquo;,
&lsquo;<code>1.2</code>&rsquo;, &lsquo;<code>1.3.2.2</code>&rsquo; or even &lsquo;<code>1.3.2.2.4.5</code>&rsquo;.
A revision number always has an even number of
period-separated decimal integers.  By default revision
1.1 is the first revision of a file.  Each successive
revision is given a new number by increasing the
rightmost number by one.  The following figure displays
a few revisions, with newer revisions to the right.

<div class="example" style="margin-left: 3.2em">
        +-----+    +-----+    +-----+    +-----+    +-----+
        ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
        +-----+    +-----+    +-----+    +-----+    +-----+
</div>

It is also possible to end up with numbers containing
more than one period, for example &lsquo;<code>1.3.2.2</code>&rsquo;.  Such
revisions represent revisions on branches
(see [[cvs: Branching and merging#Branching and merging|Branching and merging]]); such revision numbers
are explained in detail in [[cvs: Branching and merging#Branches and revisions|Branches and revisions]].


----

<div id="Versions-revisions-releases"></div>
<div class="header">
<p>
Next: [[#Assigning revisions|Assigning revisions]], Previous: [[#Revision numbers|Revision numbers]], Up: [[#Revisions|Revisions]] &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
</div>
<div id="Versions_002c-revisions-and-releases"></div>
=== Versions, revisions and releases ===
<div id="index-Revisions_002c-versions-and-releases"></div>
<div id="index-Versions_002c-revisions-and-releases"></div>
<div id="index-Releases_002c-revisions-and-versions"></div>

A file can have several versions, as described above.
Likewise, a software product can have several versions.
A software product is often given a version number such
as &lsquo;<code>4.1.1</code>&rsquo;.

Versions in the first sense are called <em>revisions</em>
in this document, and versions in the second sense are
called <em>releases</em>.  To avoid confusion, the word
<em>version</em> is almost never used in this document.


----

<div id="Assigning-revisions"></div>
<div class="header">
<p>
Next: [[#Tags&ndash;Symbolic revisions|Tags]], Previous: [[#Versions, revisions and releases|Versions revisions releases]], Up: [[#Revisions|Revisions]] &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
</div>
<div id="Assigning-revisions-1"></div>
=== Assigning revisions ===

By default, <small>CVS</small> will assign numeric revisions by
leaving the first number the same and incrementing the
second number.  For example, <code>1.1</code>, <code>1.2</code>,
<code>1.3</code>, etc.

When adding a new file, the second number will always
be one and the first number will equal the highest
first number of any file in that directory.  For
example, the current directory contains files whose
highest numbered revisions are <code>1.7</code>, <code>3.1</code>,
and <code>4.12</code>, then an added file will be given the
numeric revision <code>4.1</code>.

Normally there is no reason to care
about the revision numbers&mdash;it is easier to treat them
as internal numbers that <small>CVS</small> maintains, and tags
provide a better way to distinguish between things like
release 1 versus release 2 of your product
(see [[#Tags&ndash;Symbolic revisions|Tags]]).  However, if you want to set the
numeric revisions, the &lsquo;<code>-r</code>&rsquo; option to <code>cvs
commit</code> can do that.  The &lsquo;<code>-r</code>&rsquo; option implies the
&lsquo;<code>-f</code>&rsquo; option, in the sense that it causes the
files to be committed even if they are not modified.

For example, to bring all your files up to
revision 3.0 (including those that haven&rsquo;t changed),
you might invoke:

<div class="example" style="margin-left: 3.2em">
 $ cvs commit -r 3.0
</div>

Note that the number you specify with &lsquo;<code>-r</code>&rsquo; must be
larger than any existing revision number.  That is, if
revision 3.0 exists, you cannot &lsquo;<code>cvs commit
-r 1.3</code>&rsquo;.  If you want to maintain several releases in
parallel, you need to use a branch (see [[cvs: Branching and merging#Branching and merging|Branching and merging]]).


----

<div id="Tags"></div>
<div class="header">
<p>
Next: [[#Specifying what to tag from the working directory|Tagging the working directory]], Previous: [[#Assigning revisions|Assigning revisions]], Up: [[#Revisions|Revisions]] &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
</div>
<div id="Tags_002d_002dSymbolic-revisions"></div>
=== Tags&ndash;Symbolic revisions ===
<div id="index-Tags"></div>

The revision numbers live a life of their own.  They
need not have anything at all to do with the release
numbers of your software product.  Depending
on how you use <small>CVS</small> the revision numbers might change several times
between two releases.  As an example, some of the
source files that make up <small>RCS</small> 5.6 have the following
revision numbers:
<div id="index-RCS-revision-numbers"></div>

<div class="example" style="margin-left: 3.2em">
 ci.c            5.21
 co.c            5.9
 ident.c         5.3
 rcs.c           5.12
 rcsbase.h       5.11
 rcsdiff.c       5.10
 rcsedit.c       5.11
 rcsfcmp.c       5.9
 rcsgen.c        5.10
 rcslex.c        5.11
 rcsmap.c        5.2
 rcsutil.c       5.10
</div>

<div id="index-tag-_0028subcommand_0029_002c-introduction"></div>
<div id="index-Tags_002c-symbolic-name"></div>
<div id="index-Symbolic-name-_0028tag_0029"></div>
<div id="index-Name_002c-symbolic-_0028tag_0029"></div>
<div id="index-HEAD_002c-as-reserved-tag-name"></div>
<div id="index-BASE_002c-as-reserved-tag-name"></div>
You can use the <code>tag</code> command to give a symbolic name to a
certain revision of a file.  You can use the &lsquo;<code>-v</code>&rsquo; flag to the
<code>status</code> command to see all tags that a file has, and
which revision numbers they represent.  Tag names must
start with an uppercase or lowercase letter and can
contain uppercase and lowercase letters, digits,
&lsquo;<code>-</code>&rsquo;, and &lsquo;<code>_</code>&rsquo;.  The two tag names <code>BASE</code>
and <code>HEAD</code> are reserved for use by <small>CVS</small>.  It
is expected that future names which are special to
<small>CVS</small> will be specially named, for example by
starting with &lsquo;<code>.</code>&rsquo;, rather than being named analogously to
<code>BASE</code> and <code>HEAD</code>, to avoid conflicts with
actual tag names.

You&rsquo;ll want to choose some convention for naming tags,
based on information such as the name of the program
and the version number of the release.  For example,
one might take the name of the program, immediately
followed by the version number with &lsquo;<code>.</code>&rsquo; changed to
&lsquo;<code>-</code>&rsquo;, so that <small>CVS</small> 1.9 would be tagged with the name
<code>cvs1-9</code>.  If you choose a consistent convention,
then you won&rsquo;t constantly be guessing whether a tag is
<code>cvs-1-9</code> or <code>cvs1_9</code> or what.  You might
even want to consider enforcing your convention in the
taginfo file (see [[cvs: History browsing#User-defined logging|user-defined logging]]).

<div id="index-Adding-a-tag"></div>
<div id="index-Tags_002c-example"></div>
The following example shows how you can add a tag to a
file.  The commands must be issued inside your working
directory.  That is, you should issue the
command in the directory where &lsquo;<tt>backend.c</tt>&rsquo;
resides.

<div class="example" style="margin-left: 3.2em">
 $ cvs tag rel-0-4 backend.c
 T backend.c
 $ cvs status -v backend.c
 ===================================================================
 File: backend.c         Status: Up-to-date
 
     Version:            1.4     Tue Dec  1 14:39:01 1992
     RCS Version:        1.4     /u/cvsroot/yoyodyne/tc/backend.c,v
     Sticky Tag:         (none)
     Sticky Date:        (none)
     Sticky Options:     (none)
 
     Existing Tags:
         rel-0-4                     (revision: 1.4)
 
</div>

For a complete summary of the syntax of <code>cvs tag</code>,
including the various options, see [[cvs: Quick reference to CVS commands#Quick reference to CVS commands|Invoking CVS]].

There is seldom reason to tag a file in isolation.  A more common use is
to tag all the files that constitute a module with the same tag at
strategic points in the development life-cycle, such as when a release
is made.

<div class="example" style="margin-left: 3.2em">
 $ cvs tag rel-1-0 .
 cvs tag: Tagging .
 T Makefile
 T backend.c
 T driver.c
 T frontend.c
 T parser.c
</div>

(When you give <small>CVS</small> a directory as argument, it generally applies the
operation to all the files in that directory, and (recursively), to any
subdirectories that it may contain.  See [[cvs: Recursive behavior#Recursive behavior|Recursive behavior]].)

<div id="index-Retrieving-an-old-revision-using-tags"></div>
<div id="index-Tags_002c-retrieving-old-revisions"></div>
The <code>checkout</code> command has a flag, &lsquo;<code>-r</code>&rsquo;, that lets you check out
a certain revision of a module.  This flag makes it easy to
retrieve the sources that make up release 1.0 of the module &lsquo;<code>tc</code>&rsquo; at
any time in the future:

<div class="example" style="margin-left: 3.2em">
 $ cvs checkout -r rel-1-0 tc
</div>

This is useful, for instance, if someone claims that there is a bug in
that release, but you cannot find the bug in the current working copy.

You can also check out a module as it was at any given date.
See [[cvs: Guide to CVS commands#checkout options|checkout options]].  When specifying &lsquo;<code>-r</code>&rsquo; to
any of these commands, you will need beware of sticky
tags; see [[#Sticky tags|Sticky tags]].

When you tag more than one file with the same tag you
can think about the tag as &quot;a curve drawn through a
matrix of filename vs. revision number.&quot;  Say we have 5
files with the following revisions:

<div class="example" style="margin-left: 3.2em">
         file1   file2   file3   file4   file5
 
         1.1     1.1     1.1     1.1  /--1.1*      &lt;-*-  TAG
         1.2*-   1.2     1.2    -1.2*-
         1.3  \- 1.3*-   1.3   / 1.3
         1.4          \  1.4  /  1.4
                       \-1.5*-   1.5
                         1.6
</div>

At some time in the past, the <code>*</code> versions were tagged.
You can think of the tag as a handle attached to the curve
drawn through the tagged revisions.  When you pull on
the handle, you get all the tagged revisions.  Another
way to look at it is that you &quot;sight&quot; through a set of
revisions that is &quot;flat&quot; along the tagged revisions,
like this:

<div class="example" style="margin-left: 3.2em">
         file1   file2   file3   file4   file5
 
                         1.1
                         1.2
                 1.1     1.3                       _
         1.1     1.2     1.4     1.1              /
         1.2*----1.3*----1.5*----1.2*----1.1     (--- &lt;--- Look here
         1.3             1.6     1.3              \_
         1.4                     1.4
                                 1.5
</div>


----

<div id="Tagging-the-working-directory"></div>
<div class="header">
<p>
Next: [[#Specifying what to tag by date or revision|Tagging by date/tag]], Previous: [[#Tags&ndash;Symbolic revisions|Tags]], Up: [[#Revisions|Revisions]] &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
</div>
<div id="Specifying-what-to-tag-from-the-working-directory"></div>
=== Specifying what to tag from the working directory ===

<div id="index-tag-_0028subcommand_0029"></div>
The example in the previous section demonstrates one of
the most common ways to choose which revisions to tag.
Namely, running the <code>cvs tag</code> command without
arguments causes <small>CVS</small> to select the revisions which
are checked out in the current working directory.  For
example, if the copy of &lsquo;<tt>backend.c</tt>&rsquo; in working
directory was checked out from revision 1.4, then
<small>CVS</small> will tag revision 1.4.  Note that the tag is
applied immediately to revision 1.4 in the repository;
tagging is not like modifying a file, or other
operations in which one first modifies the working
directory and then runs <code>cvs commit</code> to transfer
that modification to the repository.

One potentially surprising aspect of the fact that
<code>cvs tag</code> operates on the repository is that you
are tagging the checked-in revisions, which may differ
from locally modified files in your working directory.
If you want to avoid doing this by mistake, specify the
&lsquo;<code>-c</code>&rsquo; option to <code>cvs tag</code>.  If there are any
locally modified files, <small>CVS</small> will abort with an
error before it tags any files:

<div class="example" style="margin-left: 3.2em">
 $ cvs tag -c rel-0-4
 cvs tag: backend.c is locally modified
 cvs <nowiki>[</nowiki>tag aborted<nowiki>]</nowiki>: correct the above errors first!
</div>


----

<div id="Tagging-by-date_002ftag"></div>
<div class="header">
<p>
Next: [[#Deleting, moving, and renaming tags|Modifying tags]], Previous: [[#Specifying what to tag from the working directory|Tagging the working directory]], Up: [[#Revisions|Revisions]] &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
</div>
<div id="Specifying-what-to-tag-by-date-or-revision"></div>
=== Specifying what to tag by date or revision ===
<div id="index-rtag-_0028subcommand_0029"></div>

The <code>cvs rtag</code> command tags the repository as of a
certain date or time (or can be used to tag the latest
revision).  <code>rtag</code> works directly on the
repository contents (it requires no prior checkout and
does not look for a working directory).

The following options specify which date or revision to
tag.  See [[cvs: Guide to CVS commands#Common command options|Common options]], for a complete
description of them.

;<code>-D <var>date</var></code>
: Tag the most recent revision no later than <var>date</var>.

;<code>-f</code>
: Only useful with the &lsquo;<code>-D <var>date</var></code>&rsquo; or &lsquo;<code>-r <var>tag</var></code>&rsquo; flags.  If no matching revision is found, use the most recent revision (instead of ignoring the file).

;<code>-r <var>tag</var></code>
: Only tag those files that contain existing tag <var>tag</var>.

The <code>cvs tag</code> command also allows one to specify
files by revision or date, using the same &lsquo;<code>-r</code>&rsquo;,
&lsquo;<code>-D</code>&rsquo;, and &lsquo;<code>-f</code>&rsquo; options.  However, this
feature is probably not what you want.  The reason is
that <code>cvs tag</code> chooses which files to tag based on
the files that exist in the working directory, rather
than the files which existed as of the given tag/date.
Therefore, you are generally better off using <code>cvs
rtag</code>.  The exceptions might be cases like:

<div class="example" style="margin-left: 3.2em">
 cvs tag -r 1.4 stable backend.c
</div>


----

<div id="Modifying-tags"></div>
<div class="header">
<p>
Next: [[#Tagging and adding and removing files|Tagging add/remove]], Previous: [[#Specifying what to tag by date or revision|Tagging by date/tag]], Up: [[#Revisions|Revisions]] &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
</div>
<div id="Deleting_002c-moving_002c-and-renaming-tags"></div>
=== Deleting, moving, and renaming tags ===


Normally one does not modify tags.  They exist in order
to record the history of the repository and so deleting
them or changing their meaning would, generally, not be
what you want.

However, there might be cases in which one uses a tag
temporarily or accidentally puts one in the wrong
place.  Therefore, one might delete, move, or rename a
tag.

'''WARNING: the commands in this section are
dangerous; they permanently discard historical
information and it can be difficult or impossible to
recover from errors.  If you are a <small>CVS</small>
administrator, you may consider restricting these
commands with taginfo (see [[cvs: History browsing#User-defined logging|user-defined logging]]).'''

<div id="index-Deleting-tags"></div>
<div id="index-Deleting-branch-tags"></div>
<div id="index-Removing-tags"></div>
<div id="index-Removing-branch-tags"></div>
<div id="index-Tags_002c-deleting"></div>
<div id="index-Branch-tags_002c-deleting"></div>
To delete a tag, specify the &lsquo;<code>-d</code>&rsquo; option to either
<code>cvs tag</code> or <code>cvs rtag</code>.  For example:

<div class="example" style="margin-left: 3.2em">
 cvs rtag -d rel-0-4 tc
</div>

deletes the non-branch tag <code>rel-0-4</code> from the module <code>tc</code>.
In the event that branch tags are encountered within the repository
with the given name, a warning message will be issued and the branch 
tag will not be deleted.  If you are absolutely certain you know what
you are doing, the <code>-B</code> option may be specified to allow deletion
of branch tags.  In that case, any non-branch tags encountered will
trigger warnings and will not be deleted.

'''WARNING: Moving branch tags is very dangerous!  If you think
you need the <code>-B</code> option, think again and ask your <small>CVS</small>
administrator about it (if that isn&rsquo;t you).  There is almost certainly
another way to accomplish what you want to accomplish.'''

<div id="index-Moving-tags"></div>
<div id="index-Moving-branch-tags"></div>
<div id="index-Tags_002c-moving"></div>
<div id="index-Branch-tags_002c-moving"></div>
When we say <em>move</em> a tag, we mean to make the same
name point to different revisions.  For example, the
<code>stable</code> tag may currently point to revision 1.4
of &lsquo;<tt>backend.c</tt>&rsquo; and perhaps we want to make it
point to revision 1.6.  To move a non-branch tag, specify the
&lsquo;<code>-F</code>&rsquo; option to either <code>cvs tag</code> or <code>cvs
rtag</code>.  For example, the task just mentioned might be
accomplished as:

<div class="example" style="margin-left: 3.2em">
 cvs tag -r 1.6 -F stable backend.c
</div>

If any branch tags are encountered in the repository 
with the given name, a warning is issued and the branch
tag is not disturbed.  If you are absolutely certain you
wish to move the branch tag, the <code>-B</code> option may be specified.
In that case, non-branch tags encountered with the given
name are ignored with a warning message.

'''WARNING: Moving branch tags is very dangerous!  If you think you
need the <code>-B</code> option, think again and ask your <small>CVS</small>
administrator about it (if that isn&rsquo;t you).  There is almost certainly
another way to accomplish what you want to accomplish.'''

<div id="index-Renaming-tags"></div>
<div id="index-Tags_002c-renaming"></div>
When we say <em>rename</em> a tag, we mean to make a
different name point to the same revisions as the old
tag.  For example, one may have misspelled the tag name
and want to correct it (hopefully before others are
relying on the old spelling).  To rename a tag, first
create a new tag using the &lsquo;<code>-r</code>&rsquo; option to
<code>cvs rtag</code>, and then delete the old name.  (Caution:
this method will not work with branch tags.) 
This leaves the new tag on exactly the 
same files as the old tag.  For example:

<div class="example" style="margin-left: 3.2em">
 cvs rtag -r old-name-0-4 rel-0-4 tc
 cvs rtag -d old-name-0-4 tc
</div>


----

<div id="Tagging-add_002fremove"></div>
<div class="header">
<p>
Next: [[#Sticky tags|Sticky tags]], Previous: [[#Deleting, moving, and renaming tags|Modifying tags]], Up: [[#Revisions|Revisions]] &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
</div>
<div id="Tagging-and-adding-and-removing-files"></div>
=== Tagging and adding and removing files ===

The subject of exactly how tagging interacts with
adding and removing files is somewhat obscure; for the
most part <small>CVS</small> will keep track of whether files
exist or not without too much fussing.  By default,
tags are applied to only files which have a revision
corresponding to what is being tagged.  Files which did
not exist yet, or which were already removed, simply
omit the tag, and <small>CVS</small> knows to treat the absence
of a tag as meaning that the file didn&rsquo;t exist as of
that tag.

However, this can lose a small amount of information.
For example, suppose a file was added and then removed.
Then, if the tag is missing for that file, there is no
way to know whether the tag refers to the time before
the file was added, or the time after it was removed.
If you specify the &lsquo;<code>-r</code>&rsquo; option to <code>cvs rtag</code>,
then <small>CVS</small> tags the files which have been removed,
and thereby avoids this problem.  For example, one
might specify <code>-r HEAD</code> to tag the head.

On the subject of adding and removing files, the
<code>cvs rtag</code> command has a &lsquo;<code>-a</code>&rsquo; option which
means to clear the tag from removed files that would
not otherwise be tagged.  For example, one might
specify this option in conjunction with &lsquo;<code>-F</code>&rsquo; when
moving a tag.  If one moved a tag without &lsquo;<code>-a</code>&rsquo;,
then the tag in the removed files might still refer to
the old revision, rather than reflecting the fact that
the file had been removed.  I don&rsquo;t think this is
necessary if &lsquo;<code>-r</code>&rsquo; is specified, as noted above.


----

<div id="Sticky-tags"></div>
<div class="header">
<p>
Previous: [[#Tagging and adding and removing files|Tagging add/remove]], Up: [[#Revisions|Revisions]] &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
</div>
<div id="Sticky-tags-1"></div>
=== Sticky tags ===
<div id="index-Sticky-tags"></div>
<div id="index-Tags_002c-sticky"></div>


Sometimes a working copy&rsquo;s revision has extra data
associated with it, for example it might be on a branch
(see [[cvs: Branching and merging#Branching and merging|Branching and merging]]), or restricted to
versions prior to a certain date by &lsquo;<code>checkout -D</code>&rsquo;
or &lsquo;<code>update -D</code>&rsquo;.  Because this data persists &ndash;
that is, it applies to subsequent commands in the
working copy &ndash; we refer to it as <em>sticky</em>.

Most of the time, stickiness is an obscure aspect of
<small>CVS</small> that you don&rsquo;t need to think about.  However,
even if you don&rsquo;t want to use the feature, you may need
to know ''something'' about sticky tags (for
example, how to avoid them!).

You can use the <code>status</code> command to see if any
sticky tags or dates are set:

<div class="example" style="margin-left: 3.2em">
 $ cvs status driver.c
 ===================================================================
 File: driver.c          Status: Up-to-date
 
     Version:            1.7.2.1 Sat Dec  5 19:35:03 1992
     RCS Version:        1.7.2.1 /u/cvsroot/yoyodyne/tc/driver.c,v
     Sticky Tag:         rel-1-0-patches (branch: 1.7.2)
     Sticky Date:        (none)
     Sticky Options:     (none)
 
</div>

<div id="index-Resetting-sticky-tags"></div>
<div id="index-Sticky-tags_002c-resetting"></div>
<div id="index-Deleting-sticky-tags"></div>
The sticky tags will remain on your working files until
you delete them with &lsquo;<code>cvs update -A</code>&rsquo;.  The
&lsquo;<code>-A</code>&rsquo; option merges local changes into the version of the
file from the head of the trunk, removing any sticky tags,
dates, or options.  See [[cvs: Guide to CVS commands#update&mdash;Bring work tree in sync with repository|update]] for more on the operation
of <code>cvs update</code>.

<div id="index-Sticky-date"></div>
The most common use of sticky tags is to identify which
branch one is working on, as described in
[[cvs: Branching and merging#Accessing branches|Accessing branches]].  However, non-branch
sticky tags have uses as well.  For example,
suppose that you want to avoid updating your working
directory, to isolate yourself from possibly
destabilizing changes other people are making.  You
can, of course, just refrain from running <code>cvs
update</code>.  But if you want to avoid updating only a
portion of a larger tree, then sticky tags can help.
If you check out a certain revision (such as 1.4) it
will become sticky.  Subsequent <code>cvs update</code>
commands will
not retrieve the latest revision until you reset the
tag with <code>cvs update -A</code>.  Likewise, use of the
&lsquo;<code>-D</code>&rsquo; option to <code>update</code> or <code>checkout</code>
sets a <em>sticky date</em>, which, similarly, causes that
date to be used for future retrievals.

People often want to retrieve an old version of
a file without setting a sticky tag.  This can
be done with the &lsquo;<code>-p</code>&rsquo; option to <code>checkout</code> or
<code>update</code>, which sends the contents of the file to
standard output.  For example:
<div class="example" style="margin-left: 3.2em">
 $ cvs update -p -r 1.1 file1 &gt;file1
 ===================================================================
 Checking out file1
 RCS:  /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
 VERS: 1.1
 ***************
 $
</div>

However, this isn&rsquo;t the easiest way, if you are asking
how to undo a previous checkin (in this example, put
&lsquo;<tt>file1</tt>&rsquo; back to the way it was as of revision
1.1).  In that case you are better off using the
&lsquo;<code>-j</code>&rsquo; option to <code>update</code>; for further
discussion see [[cvs: Branching and merging#Merging differences between any two revisions|Merging two revisions]].


----

<div class="header">
<p>
Previous: [[#Tagging and adding and removing files|Tagging add/remove]], Up: [[#Revisions|Revisions]] &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
</div>
This document was generated on <i>a sunny day</i> using [http://www.nongnu.org/texi2html/ <i>texi2html</i>].
