Loading...
Helix SwarmHelix Swarm
Loading...

br05.html

  • //
  • guest/
  • laura_wingerd/
  • perforce/
  • faq/
  • br05.html #1
  • View
  • Commits
  • Open Download .zip Download (5 KB) 
  1. <html>
  2. <head>
  3. <title>The Branching Papers -- Perforce FAQs</title>
  4. <head>
  5. <body bgcolor=#ffffff>
  6. <font size=-2><b><a href="branching.html#br05">[INDEX]</a></b></font>
  7. <p>
  8. <b>
  9. How can we integrate bug fixes from our development branch
  10. into our QA branch without dragging new feature-specific changes
  11. along with them? It there a way to mark the new development changes
  12. so that they won't get integrated into the QA branch?
  13. <p>
  14. In our Perforce evaluation,
  15. we set up a MAINDEV branch and branched it into QA60 for Release 6.
  16. Then we simulated more development in MAINDEV, and branched it into QA61.
  17. Now we've done more development in MAINDEV, including adding features
  18. for 6.2, and some bug fixes for all releases. Now we find we can't
  19. integrate our bug fixes from MAINDEV into QA61 or QA60, because the
  20. new 6.2 features get pulled along with them. 
  21. </b>
  22. <blockquote>
  23. Okay, the picture in my mind is:
  24. <pre>
  25.                        +-----------> QA61
  26.                       /
  27. ---------+-----------+-------------> MAINDEV
  28.           \
  29.            +-----------------------> QA60
  30. </pre>
  31. The complication you experienced is that in the MAINDEV->QA61
  32. integration you have to leapfrog over the 6.2 changes in MAINDEV.
  33. Although it is possible to do leapfrogging integrations, they are
  34. tricky, and unless you have a brain the size of a planet, you
  35. wouldn't want to do them every day.
  36. <p>
  37. You may be asking yourself why Perforce can't automate the
  38. leapfrogging.  Well, say we did. Say we provided a way for you to
  39. identify the 6.2 changes in MAINDEV, so that when you did a
  40. MAINDEV->QA61 integration, they could be skipped.
  41. <p>
  42. It turns out that the model to support that is effectively the same
  43. as if you have made a 6.2 development branch:
  44. <pre>
  45.  
  46. ---------+-----+------+--------------> MAINDEV
  47.           \     \      \
  48.            \     \      +------------> 62DEV
  49.             \     \
  50.              \     +-----------------> QA61
  51.               \
  52.                +---------------------> QA60
  53. </pre>
  54. Instead of assigning some oblique qualifier to the 6.2 changes
  55. checked into MAINDEV, you simply check them into 62DEV.
  56. <p>
  57. These branches would be used thus:
  58. <ul>
  59. <p><li>
  60.   MAINDEV: this is the trunk that forms the common base between
  61.   all branches. This is the <i>eventual</i> destination of <i>all</i> changes,
  62.   but at this [hypothetical] point in time, only 6.0 and 6.1 fixes
  63.   are in this branch.
  64. <p><li>
  65.   QA60: This is the released product. Critical 6.0 bug fixes are made 
  66.   here. 6.0 patches are built from this branch. Relevant fixes are 
  67.   integrated <i>from</i> here into MAINDEV.  Nothing is expected to be 
  68.   integrated <i>into</i> this branch.
  69. <p><li>
  70.   QA61: This is the upcoming release. All MAINDEV fixes are integrated
  71.   into this branch. This branch contains the same code as MAINDEV, for
  72.   now.
  73. <p>
  74.   Why even have this branch? So it can be frozen for QA. Developers
  75.   submit their 6.1 changes into MAINDEV, which is not frozen, and those
  76.   changes are integrated into QA61, according to QA/release schedules.
  77.   Eventually this will become the released 6.1 patch branch.
  78. <p><li>
  79.   62DEV: All 6.2 development is done here. All MAINDEV fixes 
  80.   are merged into this branch, which means that 62DEV contains all
  81.   6.0 and 6.1 fixes. (Or looking at it another way, "62DEV equals 
  82.   MAINDEV plus 6.2 features".) Nothing is expected to be integrated 
  83.   <i>from</i> 62DEV into MAINDEV until the 6.1 release is out the door.
  84. </ul>
  85. <p>
  86. At some point in time, the 6.0 release becomes obsolete, the 6.1
  87. release gets shipped, the 6.2 changes can be integrated into the
  88. trunk, and a QA62 line branched. The codeline would now look like:
  89. <pre>
  90. ------+-----+------+----------+-------+------> MAINDEV
  91.        \     \      \        /         \
  92.         \     \      +------+ 62DEV     +----> QA62
  93.          \     \
  94.           \     +----------------------------> QA61
  95.            \
  96.             +------------| QA60
  97. </pre>
  98. Whether or not the 62DEV branch lives on after the QA62 branch is
  99. created depends on whether anyone needs to continue work on a
  100. 62DEV feature. The theory is that at the point when 6.2 is merged
  101. into the trunk, all developers have finished their work, and can
  102. switch their client views to MAINDEV to do 6.2 mop-up work, although
  103. in practice, one or two people may lag behind. However, the goal
  104. should be to make 62DEV defunct once QA62 is branched, so that
  105. fewer cross-branch integrations are needed.
  106. <p>
  107. Obviously, the naming of branches, and the timing of it all, are
  108. subject to your shop's requirements. However, the examples above
  109. demonstrate (I hope) the general principal of maintaining a common 
  110. base so that integrations are as easy as possible.
  111. </blockquote>
  112. <p>
  113. <i>(February 1998)</i>
  114. </p>
  115. <font size=-2><b><a href="branching.html#br05">[INDEX]</a></b></font>
  116.  
  117. <hr>
  118. <h6>This is file $Id: //guest/laura_wingerd/perforce/faq/br05.html#1 $ in the 
  119. <a href="http://public.perforce.com/public/index.html">Perforce Public Depot</a></h6>
  120. </body>
  121. </html>
# Change User Description Committed
#1 83 Laura Wingerd The Branching Papers. 26 years ago