Using Labels in a Waterfall Model
From Seapine Labs
The waterfall branch model is a very popular and effective way to handle web development in Surround SCM. The waterfall model is explained in more detail in the Branching Strategies article.
Changes are rebased from stage to stage until it reaches the production branch.
The advantage of using a waterfall approch (changes rebased down the tree) as opposed to a reverse waterfall (changes are promoted up the tree) is that rebase gives you more options than just rebase by the lastest version (like promotes).
The label enhancements in version 2009 leave you without an excuse to not employ the waterfall model for web development.
 The use case
In this example, we will use the trigger set up in this other example and create a global label everytime a check in is attached to a defect on the development branch (Mainline).
Changes will then be rebased based on label (defect number) to the QA branch for testing. Those files are also added to the same label.
 Step 1: Check in file
After changes are made to three files, they are checked in and attached to defect # 18.
Figure 1 below shows a screenshot of this process:
Further examination of the label shows that all three files are now associated with this label.
 Step 2 - Rebase files
The next step is to rebase the file into the QA branch, so our QA team can verify the changes before moving them to staging.
Once the changes are verfied, they can be moved to the Staging branch. From the QA branch, Rebase Branch... is selected and the method By label is chosen. The ttp:18 label shows up as an option.
On the Rebase Preview dialog we can see that the only the three files associated with the label are going to be rebased.
The advantages of rebasing by label is that you will only rebase the files associated with the label, and that it will not contain any changes made to the files after the label was applied.
 Step 3 - Label rebased files
After the files are rebased on the QA branch, add them to the same label. Figure 6 below shows the Add to Label dialog.
After the rebased files are applied to our label, when we pull up the file list for the label, we can see now the files on both branches show up. This is a way that we can show that the fix for defect 18 has made it to the QA branch.
 Step 4 - Repeat as nescessary
Now that the files on the QA branch are added to the label, when we are ready to rebase to the Staging branch, we'll be able to rebase based on the same label.
Once the files on the staging branch are labeled, we will also be able to rebase into the Production branch based on that label. Once those files are applied to the label, we can see in the file list that the fix for defect 18 was applied to three files and the change exists on all three branches.
 What if the change fails QA?
Remember that you can remove files from labels or update the label with newer versions of files. This can help you in the scenario where the change fails the QA process.
The removal of the file from the label will have to be done manually. The batch file used in this example can not handle adding a file to a label if a previous version of the file is already associated with the label.