背景:首先,我在头脑中,至少7年前我曾在基础Clearcase工作,但我是UCM的新手。在我的新职位上似乎没有太多/任何SCM支持(他们失去了一些资源)IT维护Clearcase但是无法为开发过程提供太多支持。
问题:我正在尝试创建一个环境,其中2或3个人可以使用具有单独流的功能,我们可以在准备好时将其合并到集成流中。 (我们希望每个人都拥有自己的开发流,因此我们可以随意结账/进入,也不会影响进入集成流的其他开发工作)
我尝试“创建项目...”,我能够使用它自己的集成流创建项目(当我加入项目时,我能够创建我的dev和int视图)。让我们调用基础项目A和我创建的项目A'。我可以从A'结账并交付给A'_int流/视图。但是当我尝试从A'_int传递(希望转到A_int)时,我收到一条消息“无法传递”(尽管它确实正确地识别了我对A的集成视图)。
版本树如下所示:
main
|
0 -- A_int
|
0
|
...
|
x -- sceaj_A'-- A'_int
| |
0 0
| |
1 --------> 1
在基本clearcase中,版本树看起来像:
main
|
0 -- A_int
|
0
|
...
|
x -- A'_int
|
0 -- sceaj_A'
| |
| 0
| |
1 <--- 1
然后我可以合并回A_int。
那么,我该怎么做才能让它在UCM中发挥作用?问题是我作为普通用户在UCM中根本无法做到这一点吗?这甚至是正确的方法还是有不同的“UCM方式”?
更新:这是实际的分支结构。 。 版本282在A_Int上,iip_core_1.0.0_tr_Integeration是A'_Int(特征分支),jr ... _ip_core_1.0.0_tr是我的dev分支。这个结构是由“创建项目......”创建的,但我怀疑这不是我想要的。
答案 0 :(得分:0)
实际上,第一次交付已经交付给A_Int。
每个开发人员(ClearCase UCM view)在处理公共功能时创建seen here(为I always found an anti-pattern),因为每个开发人员必须执行的所有交付/ rebase常量工作流程为了从A_Int
的子流中受益于同事的工作
一旦交付(默认情况下从子流合并到其直接父流),您将合并到{{1}})
注意:我更喜欢在同一个流上只创建一个Dev流和多个UCM视图(每个开发人员一个):不需要交付/ rebase周期:每个开发人员都可以在签入时检测合并是否在他们工作时完成在相同的文件上 一旦完成检查,有人可以在该Dev(子) - 流上创建基线并将其传递给A_Int。
在您的情况下,看起来dev分支是从与功能分支相同的基础基线完成的 最好在基础分支上创建基线,然后使用它创建开发分支,然后从开发到功能,从功能交付到Int。
在任何情况下,请尝试在您的情况下制作功能基线,并尝试提供该功能以确定其是否更有效。
另见&#34; Difference between branches and streams in ClearCase?&#34;。