Starting from the branch diagram in the documentation, where we see a Main branch, a first branch created from main revision 1.2 as 126.96.36.199, a second branch created from 1.2 as 188.8.131.52 and a new branch created from 184.108.40.206 as 220.127.116.11.1.0.
Now let's say my first branch is my hot fix branch my second branch is my dev branch and the third is a feature branch.
THE DIFFERENCE is that each branch is a parent of one, instead of the Main having two children.
So you get 1.2 which spawns 18.104.22.168 which spawns 22.214.171.124.1.0 which spawns 126.96.36.199.188.8.131.52. I've attached a drawing at the bottom.
Each revision in the HF branch is rebased to both the dev and feature branch, and each dev revision is rebased to feature. When the feature completes it is promoted to DEV.
My concern is the following, and I've seen it happen:
1) In the lowest branch of my example, the "even" revisions come from rebases while the "odd" revisions are check-ins using a task in that view.
2) At some point after the last rebase, the the task linked to revision 184.108.40.206.220.127.116.11 is completed and set for promotion.
3) The promoted revision will create a 18.104.22.168.1.3 revision in its parent branch and will inevitably come from a merge, likely done automatically or maybe even an overwrite. Unfortunately the common ancestor if 5 revisions behind in the lowest branch and 3 revisions behind in the parent. When it comes time to merge we are left dealing with several changes from several sources.
***The problem I notice is how do we make sure the code from revision 22.214.171.124.1.2 is not removed from the parent branch on revision 126.96.36.199.1.3 because it is not included in its child branch on the last revision made by the process item being promoted.
One answer is to check the difference between 188.8.131.52.1.2 and 184.108.40.206.1.1 in the parent . Unfortunately I have to open that up in a side instance of StarTeam or some other compare tool. The common ancestor is too far behind to be of any use.
I just want to know if there is a fundamental principle I am missing here.
I'd appreciate your input as this must be a common problem. If it's not then there's something I must change on my end.
Keep in mind my example is simplified. Often, the process items will have modified dozens (sometimes hundreds) of files and the content changes are not easily identified to their source.
Thanks, here is my drawing: