Dot notation and lost changes on promotes after rebases
Starting from the branch diagram in the documentation, where we see a Main branch, a first branch created from main revision 1.2 as 184.108.40.206, a second branch created from 1.2 as 220.127.116.11 and a new branch created from 18.104.22.168 as 22.214.171.124.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 126.96.36.199 which spawns 188.8.131.52.1.0 which spawns 184.108.40.206.220.127.116.11. 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 18.104.22.168.22.214.171.124 is completed and set for promotion.
3) The promoted revision will create a 126.96.36.199.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 188.8.131.52.1.2 is not removed from the parent branch on revision 184.108.40.206.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 220.127.116.11.1.2 and 18.104.22.168.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:
Following best practices for view branching is what is most important.
In StarTeam engineering, across all our products, the main branch is our 'current work in progress' branch.
Every engineer working in a project has his 'development sandbox' branch under 'Main'
When a particular threshold (sprint end, dev release cycle) is reached, we branch a release view.
Every engineer working in the project has his 'release sandbox' branch under the release view.
Release views are all siblings under Main.
Our VCM process is - always Promote by Process Item (from Sandbox to Release, from Sandbox to Main, from Release to Main)
Rebase at Full View Scope from Release to Sandbox, Main to Sandbox.
We try to avoid VCM Rebases from Main into Release, because we run the risk of introducing revisions that aren't bug fixes.
If we're forced to , we have to deal with manual merges or use skip-a-revision.
but to your concern...
>>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.
I have no idea. I've never encountered it myself. ever.
that doesn;t mean it isn;t possible, it sounds like you're facing this situation under some circumstances.
But if you were in a position to follow an air tight best practice, I think you'd largely mitigate/reduce your risk of spurious data.
And I'm going to go out on a limb and say - that's true no matter which SCM system you use.
The way I picture it is a main branch with several sibling dev sandbox views per engineer.
So further on, when you say you "branch a release view", you branch it from where? Main, or from every dev sandbox views?
If every engineer then has a release sandbox view under release, what do you mean by "release views are siblings under Main"?
Perhaps I can ask in a different way - when your "threshold" is reached are the dev sandboxes promoted back to main before main is branched to release which is further branched to sibling release sandboxes (under release)? Then, is Release promoted back to Main at some point?
Our main issue here is we have a single build server with hardcoded build scripts which checkout from specific views. If we start spawning sporadic views per engineer we'll need to modify build scripts with view name inputs so that each sandbox can be tested during development (we have lean teams which test directly and concurrently from dev).
I am trying to adapt the tool (StarTeam) to the culture rather than revamping the culture, which would be easier for me but harder for everyone.
That is why I am digging into the strategy you presented and attempting to get inspired from it. I hope you do not mind.
Thanks so much for sharing. You've already given me food for thought.
We also use an architecture closer to yours/GitFlow, but we also have per-engineer sandboxes. However, we run into the same merging issue as you've described with ancestors being too old to be of value and sometimes new or old code getting put in unexpected places.
I have been considering for awhile trying to move us towards the example Anil provided. Your team seems to be quicker at implementing changes like this, so I'd be interested to hear some feedback about how the transition went and/or if it solves your problems.
One follow-on question I have to Anil is when, if ever, do you close (and maybe delete) any of the sandbox branches? Do you keep them around forever? Or shortly after a promote do you delete them?
We'll typically keep release based sandboxes around for as long as we're supporting defect fixes for the release.
The main view sandbox branches stay around for ever, for the most part.
>>shortly after a promote do you delete them?
No, however, we are working on a p.o.c. for a new feature called light weight views.
The idea behind light weight views is precisely aimed at targeted defect fixes.
create a lightweight view, fix a bug, verify the fix, promote it to the release view, then up to the main view, delete the lightweight view.
we do not have a release date scheduled for this yet. still in the investigation and p.o.c. phase.
hope this helps
Thanks for participating, I appreciate different views (no pun intended).
What I retain from Anil architecture - more than the fact that they branch by engineer - is that they keep the lifetime of the DEV sanboxes relatively short. This is what eliminates the far-back common ancestor. In a release sandbox, I presume it can last longer because the code is much more stable. In the case when several hot fixes were done from a release sandbox and the common ancestor starts to get old, they'll run into the same problem over time, but there's nothing preventing them from branching a new release sandbox thereby generating another common ancestor.
There may also be a way to do that without a new branch: after promoting the release sandbox to Release and making sure the sandbox is in sync via rebasing, you can perhaps promote the entire view and set everything to "Marked Resolved" thus creating new merge points for everything. However I'm not sure if a common merge behaves the same as a common ancestor.
So at this point I'm not sure whether I'll try to adopt a branch by engineer or "branch by feature" or "branch by sprint". The import thing is to keep the common ancestor from getting old - and by "old" I mean having too many changes between source<->common and target<->common.