清除案例问题

本文介绍了清除案例问题的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我负责我的项目中的clearcase。我没有太多经验。 我的问题是，现在我们在cc中的项目结构是一个具有PROD，PV，ST，DV流的项目，如下所示；

链接到屏幕截图

现在如您所见，DV流下的每个开发人员都有单独的流。我们向上游交付代码的方式是一对一的。现在由于管理方面的变化，我们必须以可以进行并行开发的方式实施。也就是说，如果Prod中存在错误，而我们想修复它并将其交付给prod，而又不交付其他开发人员正在研究的当前活动/基准，那么我们如何更改cc项目以将其合并？ p>

我们希望有类似 PROD（JAN版本） -PV（JAN版本） -ST（JAN，FEB版本）的东西 -DV（JAN，FEB，MAR版本）

分别管理JAN，FEB，MAR版本。如果我们必须修复JAN版本中的某些内容并且不想包含FEB和MAR版本，我们该怎么做？

如果您能给我们，那将是很棒的

解决方案

DV流下每个开发人员的独立流

谁？？？？这是斯巴达！ （err ... no：疯狂：这是疯狂）

流表示开发工作，而不是资源（即开发人员）的沙箱。资源随处可见，开发任务得以保留。 每条开发线都应有一个流，许多开发人员都可以在此流上创建自己的视图。

这样，如果您需要并行开发，则只需在当前流旁边创建一个兄弟流，以便使用PROD的基线来重新构建该错误修复流。 因此：

PROD PV ST DV PV-JAN

通过创建PV-JAN，您可以创建一个流，该流专门用于向所创建的基准进行细微的演变 而且您不必为每个开发人员创建所有这些子流，因为这将代表过多的交付/重新设置步骤。 2个或3个开发人员需要修复PV-JAN上的所有内容，并在 same 流上创建自己的视图。他们都将参与相同的开发工作（修复PV的JAN版本的错误）

I am responsible for clearcase at my project. I do not have much experience. My issue is , right now our project structure in cc is a project with PROD,PV, ST, DV streams as seen here;

Link to the screenshot

Now as you can see we have individual stream for each developer under DV stream. The way we deliver code up stream is one by one. Now due to changes in the management, we have to implement in such a way that PARALLEL development is possible. i.e. if there is a bug in Prod and we want to fix it and deliver it back to prod, without delivering the current activities/baselines which are being worked on by different developers, how can we change our cc project to incorporate that?

we want to have something like PROD (JAN release) -PV (JAN release) -ST (JAN, FEB release) -DV (JAN, FEB, MAR release)

to manage JAN, FEB, MAR release separately. If we have to fix something in JAN release and do not want to include FEB and MAR releases, how can we do that?

It will be great if you can give us some insight as soon as possible.

解决方案

individual stream for each developer under DV stream

Whoât???? This is SPARTA! (err... no: madness: this is madness)

A stream represents a development effort, not a sandbox for a "resource" (i.e. "a developer"). Resources come and go, development tasks stay. You should have a stream per development line, upon which many developers create their own view.

That way, if you need a parallel development, you only need to create one "brother" stream beside the current one, in order to rebase that bug-fix stream with a baseline from PROD. So:

PROD PV ST DV PV-JAN

By creating PV-JAN, you create a stream dedicated to small evolutions to the baseline created for JAN. And you do not have to create all those sub-streams per developer, since it would represent far too many deliver/rebase steps. The 2 or 3 developers who need to fix anything on PV-JAN create their own view on the same stream. They will all participate to the same development effort (fixing bugs for the JAN release of PV)