1<div id="Creating-the-branch-after-editing"></div>
2<div class="header">
3<p>
4 &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
5</div>
6
7----
8
9===== Creating the branch after editing =====
10
11Say you have been working on some extremely
12experimental software, based on whatever revision you
13happened to checkout last week.  If others in your
14group would like to work on this software with you, but
15without disturbing main-line development, you could
16commit your change to a new branch.  Others can then
17checkout your experimental stuff and utilize the full
18benefit of <small>CVS</small> conflict resolution.  The scenario might
19look like:
20
21<div class="example" style="margin-left: 3.2em">
22 <nowiki>[[</nowiki> hacked sources are present <nowiki>]]</nowiki>
23 $ cvs tag -b EXPR1
24 $ cvs update -r EXPR1
25 $ cvs commit
26</div>
27
28The <code>update</code> command will make the &lsquo;<code>-r
29EXPR1</code>&rsquo; option sticky on all files.  Note that your
30changes to the files will never be removed by the
31<code>update</code> command.  The <code>commit</code> will
32automatically commit to the correct branch, because the
33&lsquo;<code>-r</code>&rsquo; is sticky.  You could also do like this:
34
35<div class="example" style="margin-left: 3.2em">
36 <nowiki>[[</nowiki> hacked sources are present <nowiki>]]</nowiki>
37 $ cvs tag -b EXPR1
38 $ cvs commit -r EXPR1
39</div>
40
41but then, only those files that were changed by you
42will have the &lsquo;<code>-r EXPR1</code>&rsquo; sticky flag.  If you hack
43away, and commit without specifying the &lsquo;<code>-r EXPR1</code>&rsquo;
44flag, some files may accidentally end up on the main
45trunk.
46
47To work with you on the experimental change, others
48would simply do
49
50<div class="example" style="margin-left: 3.2em">
51 $ cvs checkout -r EXPR1 whatever_module
52</div>
53
54This document was generated on <i>a sunny day</i> using [http://www.nongnu.org/texi2html/ <i>texi2html</i>].
55