Stream structure | 易学教程

问题

We have two structures, a stair step from PROD_int with child of release_Int then with child of a maintenance/hotfix and also projectA_Int, projectA has childs of deploy & dev and also projectB_int, projectB has child of deploy & dev and projectC_int then ProjectC has childs of Deploy & dev. The other is mainline where Prod_int, maintenance_int, hotfix_int, projectA_int and projectB_int are all on same downline and each (except PROD) have a deploy and dev child stream This stair step deliveries seem to take much longer; but the latter seems to have more merge conflicts; not sure if it is the structure or just the way we are using them

Does one cause more merges than the other?

回答1:

So basically:

PROD_Int
  |
  --Release_Int
    |
    --Maintenance_Int
      |
      --HotFix

ProjectA/B/C
  |
  --deploy
  |
  --dev

Vs.

Int
|
--Prd_Int
|
--maintenance_int
|
--hotfix_int
|
--ProjectA/B_Int

What takes time in the stair scenario are the deliver/rebases cycles.
But everytime you need to consolidate code from sub-streams, a parent stream is useful.
If you just want to represent different steps in the development lifecycle, a parent stream is harmful, because of the artificial need to delivedr, then rebase on other streams.

I would suggests a mixed approach, with 2 UCM projects:

one dedicated to integration, prod and hotfix,
one dedicated to dev.

When the release date approaches, you can start delilvering from one (dev) project to integration, then freezing your features one that stream, rebasing to prod when you release, and then rebasing on hotfix for post-release maintenance.

Do not try to mix 'deploy' and 'dev' together: they don't go along so well.

Dev is parent for many feature substream.
Deploy can is the children of 'Integration', where you have consolidated what will actually goes into production.

来源：https://stackoverflow.com/questions/11676969/stream-structure

标签

clearcase-ucm