346 lines
7.6 KiB
HTML
346 lines
7.6 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Branching and Merging</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="CVS Best Practices"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="CVS Server Configuration"
|
|
HREF="section1-serverconfig.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Change Propagation"
|
|
HREF="section1-chgpropagation.html"></HEAD
|
|
><BODY
|
|
CLASS="sect1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>CVS Best Practices</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="section1-serverconfig.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="section1-chgpropagation.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="sect1"
|
|
><H1
|
|
CLASS="sect1"
|
|
><A
|
|
NAME="section1-branchmerge"
|
|
></A
|
|
>6. Branching and Merging</H1
|
|
><P
|
|
> Branching in CVS splits a project's development into separate,
|
|
parallel histories. Changes made on one branch do not affect the other
|
|
branches. Branching can be used extensively to maintain multiple versions
|
|
of a product for providing support and new features. </P
|
|
><P
|
|
> Merging converges the branches back to the main trunk. In a merge,
|
|
CVS calculates the changes made on the branch between the point where it
|
|
diverged from the trunk and the branch's tip (its most recent state), then
|
|
applies those differences to the project at the tip of the trunk. </P
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="section2-branchowner"
|
|
></A
|
|
>6.1. Assign ownership to Trunk and Branches</H2
|
|
><P
|
|
>The main trunk of the source tree and the various branches should have a
|
|
owner assigned who will be responsible for. </P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
>Keep the list of configurable items for the branch or trunk.
|
|
</P
|
|
><P
|
|
>The owner will be the maintainer of the contents list for the branch or
|
|
trunk. This list should contain the item name and a brief description about
|
|
the item. This list is essential since new artifacts are always added to or
|
|
removed from the repository on an ongoing basis. This list will be able to
|
|
track the new additions/deletions to the repository for the respective branch.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Establish a working policy for the branch or trunk.
|
|
</P
|
|
><P
|
|
>The owner will establish policies for check-in and check-out. The
|
|
policy will define when the code can be checked in (after coding or after
|
|
review etc.,). Who is responsible to merge changes on the same file and
|
|
resolve conflicts (the author or the person who recently changed the file).
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Identify and document policy deviations
|
|
</P
|
|
><P
|
|
>Policies once established tend to have exceptions. The owner will be
|
|
responsible for identifying the workaround and tracking/documenting the same
|
|
for future use. </P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Responsible for merge with the trunk
|
|
</P
|
|
><P
|
|
>The branch owner will be responsible for ensuring that the changes in
|
|
the branch can be successfully merged with the main trunk at a reasonable point
|
|
in time. </P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="section2-tagrelease"
|
|
></A
|
|
>6.2. Tag each release</H2
|
|
><P
|
|
>As part of the release process, the entire code base must be tagged with an
|
|
identifier that can help in uniquely identifying the release. A tag gives a
|
|
label to the collection of revisions represented by one developer's working
|
|
copy (usually, that working copy is completely up to date so the tag name is
|
|
attached to the <SPAN
|
|
CLASS="QUOTE"
|
|
>"latest and greatest"</SPAN
|
|
> revisions in the
|
|
repository). </P
|
|
><P
|
|
>The identifier for the tag should provide enough information to
|
|
identify the release at any point in time in the future. One suggested tag
|
|
identifier is of the form. </P
|
|
><P
|
|
CLASS="literallayout"
|
|
><br>
|
|
<TT
|
|
CLASS="literal"
|
|
>release_</TT
|
|
>{major version #}_{minor version #}<br>
|
|
</P
|
|
><DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>As one reader pointed out to me, a good practice here is to tag
|
|
the release first. Checkout the entire codebase using the tag, and then
|
|
proceed to go through a build / deploy / test process before making the
|
|
actual release. This will absolutely ensure that what <SPAN
|
|
CLASS="QUOTE"
|
|
>"leaves the
|
|
door "</SPAN
|
|
> is a verified and tested codebase.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="section2-branchatrelease"
|
|
></A
|
|
>6.3. Create a branch after each release</H2
|
|
><P
|
|
>After each software release, once the CVS repository is tagged, a
|
|
branch has to be immediately created. This branch will serve as the bug fix
|
|
baseline for that release. This branch is created only if the release is
|
|
not a bug fix or patch release in the first place. Patches that have to be
|
|
made for this release at any point in time in the future will be developed
|
|
on this branch. The main trunk will be used for ongoing product
|
|
development. </P
|
|
><P
|
|
>With this arrangement, the changes in the code for the ongoing
|
|
development will be on the main trunk and the branch will provide a separate
|
|
partition for hot fixes and bug fix releases. </P
|
|
><P
|
|
>The identifier for the branch name can be of the form. </P
|
|
><P
|
|
CLASS="literallayout"
|
|
><br>
|
|
<TT
|
|
CLASS="literal"
|
|
>release_</TT
|
|
>{major version #}_{minor version #}<TT
|
|
CLASS="literal"
|
|
>_patches</TT
|
|
><br>
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="section2-bugfixbranches"
|
|
></A
|
|
>6.4. Make bug fixes to branches only</H2
|
|
><P
|
|
>This practice extends from the previous practice of creating a
|
|
separate branch after a major release. The branch will serve as the code
|
|
base for all bug fixes and patch release that have to be made. Thus, there
|
|
is a separate repository <SPAN
|
|
CLASS="QUOTE"
|
|
>"sandbox"</SPAN
|
|
> where the hot fixes and
|
|
patches can be developed apart from the mainstream development. </P
|
|
><P
|
|
>This practice also ensures that bug fixes done to previous releases do
|
|
not mysteriously affect the mainstream version. In addition, new features
|
|
added to the mainstream version do not creep into the patch release
|
|
accidentally. </P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="section2-patchesfrombranches"
|
|
></A
|
|
>6.5. Make patch releases from branches only</H2
|
|
><P
|
|
>Since all the bug fixes for a given release are done on its
|
|
corresponding branch, the patch releases are made from the branch. This
|
|
ensures that there is no confusion on the feature set that is released as
|
|
part of the patch release. </P
|
|
><P
|
|
>After the patch release is made, the branch has to be tagged using the
|
|
release tagging practice (see <A
|
|
HREF="section1-branchmerge.html#section2-tagrelease"
|
|
>Tag each release</A
|
|
>). </P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="section1-serverconfig.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="section1-chgpropagation.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>CVS Server Configuration</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Change Propagation</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |