DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 

(cvs.info.gz) commit examples

Info Catalog (cvs.info.gz) commit options (cvs.info.gz) commit
 
 A.10.2 commit examples
 ----------------------
 
 A.10.2.1 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 ( 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.
 
 A.10.2.2 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
 
Info Catalog (cvs.info.gz) commit options (cvs.info.gz) commit
automatically generated byinfo2html