DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 

(cvs.info.gz) Sticky tags

Info Catalog (cvs.info.gz) Tagging add/remove (cvs.info.gz) Revisions
 
 4.9 Sticky tags
 ===============
 
 Sometimes a working copy's revision has extra data associated with it,
 for example it might be on a branch ( Branching and merging), or
 restricted to versions prior to a certain date by `checkout -D' or
 `update -D'.  Because this data persists - that is, it applies to
 subsequent commands in the working copy - we refer to it as "sticky".
 
    Most of the time, stickiness is an obscure aspect of CVS that you
 don't need to think about.  However, even if you don'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 `status' command to see if any sticky tags or dates
 are set:
 
      $ 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)
 
    The sticky tags will remain on your working files until you delete
 them with `cvs update -A'.  The `-A' option merges local changes into
 the version of the file from the head of the trunk, removing any sticky
 tags, dates, or options.  See  update for more on the operation
 of `cvs update'.
 
    The most common use of sticky tags is to identify which branch one
 is working on, as described in  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 `cvs update'.  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 `cvs update' commands will not retrieve the latest
 revision until you reset the tag with `cvs update -A'.  Likewise, use
 of the `-D' option to `update' or `checkout' sets a "sticky date",
 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 `-p' option to
 `checkout' or `update', which sends the contents of the file to
 standard output.  For example:
      $ cvs update -p -r 1.1 file1 >file1
      ===================================================================
      Checking out file1
      RCS:  /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
      VERS: 1.1
      ***************
      $
 
    However, this isn't the easiest way, if you are asking how to undo a
 previous checkin (in this example, put `file1' back to the way it was
 as of revision 1.1).  In that case you are better off using the `-j'
 option to `update'; for further discussion see  Merging two
 revisions.
 
Info Catalog (cvs.info.gz) Tagging add/remove (cvs.info.gz) Revisions
automatically generated byinfo2html