br05.html #1 

<html>
<head>
<title>The Branching Papers -- Perforce FAQs</title>
<head>
<body bgcolor=#ffffff>
<font size=-2><b><a href="branching.html#br05">[INDEX]</a></b></font>
<p>
<b>
How can we integrate bug fixes from our development branch
into our QA branch without dragging new feature-specific changes
along with them? It there a way to mark the new development changes
so that they won't get integrated into the QA branch?
<p>
In our Perforce evaluation,
we set up a MAINDEV branch and branched it into QA60 for Release 6.
Then we simulated more development in MAINDEV, and branched it into QA61.
Now we've done more development in MAINDEV, including adding features
for 6.2, and some bug fixes for all releases. Now we find we can't
integrate our bug fixes from MAINDEV into QA61 or QA60, because the
new 6.2 features get pulled along with them. 
</b>
<blockquote>
Okay, the picture in my mind is:
<pre>
                       +-----------> QA61
                      /
---------+-----------+-------------> MAINDEV
          \
           +-----------------------> QA60
</pre>
The complication you experienced is that in the MAINDEV->QA61
integration you have to leapfrog over the 6.2 changes in MAINDEV.
Although it is possible to do leapfrogging integrations, they are
tricky, and unless you have a brain the size of a planet, you
wouldn't want to do them every day.
<p>
You may be asking yourself why Perforce can't automate the
leapfrogging.  Well, say we did. Say we provided a way for you to
identify the 6.2 changes in MAINDEV, so that when you did a
MAINDEV->QA61 integration, they could be skipped.
<p>
It turns out that the model to support that is effectively the same
as if you have made a 6.2 development branch:
<pre>

---------+-----+------+--------------> MAINDEV
          \     \      \
           \     \      +------------> 62DEV
            \     \
             \     +-----------------> QA61
              \
               +---------------------> QA60
</pre>
Instead of assigning some oblique qualifier to the 6.2 changes
checked into MAINDEV, you simply check them into 62DEV.
<p>
These branches would be used thus:
<ul>
<p><li>
  MAINDEV: this is the trunk that forms the common base between
  all branches. This is the <i>eventual</i> destination of <i>all</i> changes,
  but at this [hypothetical] point in time, only 6.0 and 6.1 fixes
  are in this branch.
<p><li>
  QA60: This is the released product. Critical 6.0 bug fixes are made 
  here. 6.0 patches are built from this branch. Relevant fixes are 
  integrated <i>from</i> here into MAINDEV.  Nothing is expected to be 
  integrated <i>into</i> this branch.
<p><li>
  QA61: This is the upcoming release. All MAINDEV fixes are integrated
  into this branch. This branch contains the same code as MAINDEV, for
  now.
<p>
  Why even have this branch? So it can be frozen for QA. Developers
  submit their 6.1 changes into MAINDEV, which is not frozen, and those
  changes are integrated into QA61, according to QA/release schedules.
  Eventually this will become the released 6.1 patch branch.
<p><li>
  62DEV: All 6.2 development is done here. All MAINDEV fixes 
  are merged into this branch, which means that 62DEV contains all
  6.0 and 6.1 fixes. (Or looking at it another way, "62DEV equals 
  MAINDEV plus 6.2 features".) Nothing is expected to be integrated 
  <i>from</i> 62DEV into MAINDEV until the 6.1 release is out the door.
</ul>
<p>
At some point in time, the 6.0 release becomes obsolete, the 6.1
release gets shipped, the 6.2 changes can be integrated into the
trunk, and a QA62 line branched. The codeline would now look like:
<pre>
------+-----+------+----------+-------+------> MAINDEV
       \     \      \        /         \
        \     \      +------+ 62DEV     +----> QA62
         \     \
          \     +----------------------------> QA61
           \
            +------------| QA60
</pre>
Whether or not the 62DEV branch lives on after the QA62 branch is
created depends on whether anyone needs to continue work on a
62DEV feature. The theory is that at the point when 6.2 is merged
into the trunk, all developers have finished their work, and can
switch their client views to MAINDEV to do 6.2 mop-up work, although
in practice, one or two people may lag behind. However, the goal
should be to make 62DEV defunct once QA62 is branched, so that
fewer cross-branch integrations are needed.
<p>
Obviously, the naming of branches, and the timing of it all, are
subject to your shop's requirements. However, the examples above
demonstrate (I hope) the general principal of maintaining a common 
base so that integrations are as easy as possible.
</blockquote>
<p>
<i>(February 1998)</i>
</p>
<font size=-2><b><a href="branching.html#br05">[INDEX]</a></b></font>

<hr>
<h6>This is file $Id: //guest/universitytexas/faq/br05.html#1 $ in the 
<a href="http://public.perforce.com/public/index.html">Perforce Public Depot</a></h6>
</body>
</html>
# Change User Description Committed
#1 684 jim_dowsett Beginning point for UTA se1 CSE5324 summer 2001 version control/file sharing project.
//public/perforce/faq/br05.html
#1 112 Laura Wingerd Publish "Branching FAQ"
(pull in changes from //guest/laura_wingerd/perforce/faq/... )
//guest/laura_wingerd/perforce/faq/br05.html
#1 83 Laura Wingerd The Branching Papers.