DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 

(cvs.info.gz) Tags

Info Catalog (cvs.info.gz) Assigning revisions (cvs.info.gz) Revisions (cvs.info.gz) Tagging the working directory
 
 4.4 Tags-Symbolic revisions
 ===========================
 
 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 CVS the revision numbers might
 change several times between two releases.  As an example, some of the
 source files that make up RCS 5.6 have the following revision numbers: 
 
      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
 
    You can use the `tag' command to give a symbolic name to a certain
 revision of a file.  You can use the `-v' flag to the `status' 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, `-', and `_'.
 The two tag names `BASE' and `HEAD' are reserved for use by CVS.  It is
 expected that future names which are special to CVS will be specially
 named, for example by starting with `.', rather than being named
 analogously to `BASE' and `HEAD', to avoid conflicts with actual tag
 names.
 
    You'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 `.' changed to `-', so
 that CVS 1.9 would be tagged with the name `cvs1-9'.  If you choose a
 consistent convention, then you won't constantly be guessing whether a
 tag is `cvs-1-9' or `cvs1_9' or what.  You might even want to consider
 enforcing your convention in the `taginfo' file ( taginfo).
 
    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 `backend.c' resides.
 
      $ 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)
 
    For a complete summary of the syntax of `cvs tag', including the
 various options, see  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.
 
      $ cvs tag rel-1-0 .
      cvs tag: Tagging .
      T Makefile
      T backend.c
      T driver.c
      T frontend.c
      T parser.c
 
 (When you give CVS 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.   Recursive behavior.)
 
    The `checkout' command has a flag, `-r', 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 `tc' at any time in the
 future:
 
      $ cvs checkout -r rel-1-0 tc
 
 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 on any branch at any given
 date.   checkout options.  When specifying `-r' or `-D' to any
 of these commands, you will need beware of sticky tags; see 
 Sticky tags.
 
    When you tag more than one file with the same tag you can think
 about the tag as "a curve drawn through a matrix of filename vs.
 revision number."  Say we have 5 files with the following revisions:
 
              file1   file2   file3   file4   file5
 
              1.1     1.1     1.1     1.1  /--1.1*      <-*-  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
 
    At some time in the past, the `*' 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 "sight" through a set
 of revisions that is "flat" along the tagged revisions, like this:
 
              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*    (--- <--- Look here
              1.3             1.6     1.3              \_
              1.4                     1.4
                                      1.5
 
Info Catalog (cvs.info.gz) Assigning revisions (cvs.info.gz) Revisions (cvs.info.gz) Tagging the working directory
automatically generated byinfo2html