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 \ +-----------------------> QA60The 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 \ +---------------------> QA60Instead 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:
- MAINDEV: this is the trunk that forms the common base between all branches. This is the eventual destination of all changes, but at this [hypothetical] point in time, only 6.0 and 6.1 fixes are in this branch.
- 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 from here into MAINDEV. Nothing is expected to be integrated into this branch.
- QA61: This is the upcoming release. All MAINDEV fixes are integrated into this branch. This branch contains the same code as MAINDEV, for now.
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.
- 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 from 62DEV into MAINDEV until the 6.1 release is out the door.
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 \ +------------| QA60Whether 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)
[INDEX]