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?

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.

Okay, the picture in my mind is:
                       +-----------> QA61
---------+-----------+-------------> MAINDEV
           +-----------------------> QA60
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.

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.

It turns out that the model to support that is effectively the same as if you have made a 6.2 development branch:

---------+-----+------+--------------> MAINDEV
          \     \      \
           \     \      +------------> 62DEV
            \     \
             \     +-----------------> QA61
               +---------------------> QA60
Instead of assigning some oblique qualifier to the 6.2 changes checked into MAINDEV, you simply check them into 62DEV.

These branches would be used thus:

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:

------+-----+------+----------+-------+------> MAINDEV
       \     \      \        /         \
        \     \      +------+ 62DEV     +----> QA62
         \     \
          \     +----------------------------> QA61
            +------------| QA60
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.

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.

(February 1998)

This is file $Id: //public/perforce/faq/br05.html#1 $ in the Perforce Public Depot