问题标签 [clearcase-ucm]

将 Rational ClearCase v. 7.0.1.1 与 UCM 一起使用，我在使用 ClearCase 的“从流传递到备用目标”功能时遇到了问题。

想象一下，我们有一个项目集成流和两个从它派生的开发人员流 A 和 B。现在我更改了流 A 中的一个文件。我希望拥有流 B 的开发者能够使用我的工作，而无需我将文件传送到集成流，因此我从流 A 传送到备用目标流 B。

到目前为止，一切都很好。我继续对文件进行另一项更改，但流 B 开发人员不需要此更改，因此我不将其交付给他。

再过一段时间，我将我的工作交付给主集成流。这很好用，尽管我想知道为什么 ClearCase 将合并标记为普通的“合并”而不是“合并（琐碎）”——除了我之外，没有人对文件进行过更改。

交付后，在主集成流上创建一个新基线。

真正的问题出现在开发人员 B 尝试重新设置他的流的基础上。由于开发人员 B 从未对文件进行任何更改，我希望合并是一个微不足道的合并，无需交互。但是发生的情况是，开发人员 B 被迫以图形方式解决该文件上的合并冲突，让他在集成流的基本版本、我交付给他的版本和我交付给集成流的版本之间进行选择。

当解决合并并完成 rebase 后，开发人员 B 想要向主集成流执行交付时，混乱继续存在。除了我最初交付给他的活动之外，他还被提供了一个名为 rebase_... 的活动，我从没想过会提供这个活动。

我在这里错过了什么吗？我们是否错误地使用了 ClearCase，或者这是一个已知的限制/错误？有没有人体验过这个功能？

在此先感谢您的帮助！

简

我有3个项目A，基于A的B，基于A的C。

更改 A 应首先合并到 B，然后从 B 合并到 C。B 中也有不影响 A 的更改，但其中一些更改需要合并到 C 中。

有一些从 A 被错误地直接从 A 合并到 C 绕过 B 的更改。（我使用“合并”这个词是因为我们需要手动合并这些更改，因为自动交付将包括一堆我们不需要的活动交付给 B 和 C)。

为了解决这个问题，我现在需要合并未在 B 中合并但已在 B 中合并到 C 中的更改，我正在寻找一种方法来列出 C 中通过从 A 合并创建的所有版本，所以我可以将这些文件的更改合并到 B.

谢谢

这个问题可能不是很清楚，因为我不是在寻找问题的解决方案，而是在寻求避免将来可能出现的问题。

假设我们有项目 AB 和 C，B 和 C 基于 A 的不同基线。在 B 和 C 的两个方向上进行 B 和 C 之间的合并是否可以，反之亦然，以后不会产生问题吗？

在我的特殊情况下，我将版本从 A 合并到 B，从 B 合并到 C，现在我想从 C 合并到 B。主干中的 A，C 是特定于安装的，B 是特定于客户的。当客户部署了更新的构建时，我们最终会放弃 C。但是现在有一种情况（错误地），一些更改从 A 合并到 C 绕过 B。这些更改应该是 A -> B -> C。问题是从 A 到 C 的一些合并是不平凡的合并，我不不想重复手动从 A 合并到 B 的工作。对于这个版本，从 C 合并到 B 似乎更容易。可以吗？

谢谢！

我们采用了一个模型，我们在其中每个 UCM 项目都有一个集成和一个通用开发流。项目 A 是主干。项目 B 是在项目 A 的集成流的基线 BL1 上创建的项目 A 的一个分支。项目 A 的开发流后来使用集成流中的基线 BL2 重新设置了基础。因此，与 BL1 相比，BL2 是一个更新的基线。

问题是，项目的 A 开发流和项目 B 的开发流现在具有不同的基础基线（项目的 A 开发流具有更新的基础基线）这一事实是否会影响从项目 B 开发流合并到项目 A 开发流？

我知道会有很多非 tivial 合并，因为差异很大，但需要确保在这种情况下 CC 不会出现任何基本问题。

谢谢！

我们有一个项目，即将在其他稳定的代码库中添加一个新功能，除了缺陷修复之外没有任何重大变化。该计划不会在一段时间内（可能一个月）单独开发新功能，进行中间构建和测试，当功能完成并且质量可以接受时，将新功能的代码合并到主分支中。

问题是以下两种情况中的哪一种在 Clear Case 方面更好：

1. 根据当前项目的集成流中的基线创建一个新项目，在这个单独的项目中开发新功能，并将中间交付到新项目的集成流并从集成流构建。并最终将新项目的集成流中的更改交付到主项目（到 dev 或 int）。

2. 在主项目中使用流的层次结构：在主项目中创建集成流的子流（称为 temp_int）和 temp_int 的子流（称为 temp_dev）。在 temp_dev 中开发新功能，定期交付 temp_int 并从 temp_int 构建，然后将新功能从 temp_int 交付到主集成流。

我们在同一级别的层次结构中有两个 Clearcase UCM 流（即相同的父流）。如果两个子流都重新定位到相同的父基线，这是否意味着

• 将两个流的活动传递给父级（一个，然后另一个）

相当于：

• 将一个子流的活动交付给另一个子流，然后简单地将一个子流交付给父流

这是真的吗？似乎应该是，假设所有交付的任何手动/用户选择的合并都是以相同的方式进行的。

我和我的同事相对需要使用 Clearcase UCM 的流创意。目前管理层已经为每个功能软件包创建了流，每个软件包都有定义的接口并存在于分层架构中。开发人员根据他们正在使用的包创建子流，并尝试独立开发他们的代码，但是他们通常在初始开发期间依赖于其他包。这导致我们的集成小组创建系统构建，然后开发人员使用这些构建来创建足够的环境来开发他们的软件并手动引入依赖项（即 zip 文件、补丁等）。

我的论点是这是错误的，而不是 UCM 的预期用途，但我需要更熟悉 UCM 的人来确认我的信念。

我认为应该从功能的角度创建流（虽然每个包都有一些功能，但多个架构包有助于实现一些客户功能，称之为“ABC”）。然后，将针对功能“ABC”执行初始开发的每个架构组件的组件添加到流中。现在，功能“ABC”的所有开发人员都在流（或某些子流集）中工作以完成该功能。一旦完成，您就有了每个 UCM 组件的基线，并且从 UCM 的角度来看，组件之间不存在“绑定”（有人声称这可能由于活动记录而在 UCM 内以某种方式发生）。

注意：我同意你可能不会永远这样工作，但是在接口通常发生变化的初始开发过程中，你还没有实现所有功能的所有接口，因此让多个组件在一个流中一起工作是最有意义的. 稍后，您可以过渡到“以架构包为中心”的工作方式，其中每个包都独立于另一个包的更改。

想法？抱歉发了这么长的帖子，我觉得细节是必要的。

我们正在考虑为变更管理和缺陷跟踪实施 Rational ClearQuest。当我们集成 Rational ClearQuest 和 Rational ClearCase 时，活动将来自 Rational ClearQuest。

现在，由于 Rational ClearQuest 的实现需要时间，因此我们正在考虑从开​​发人员端移除活动创建。我们正在考虑让管理员为每个开发人员创建活动。

现在我有几个问题，如果管理员创建活动并使用保护命令更改活动和组的所有者，是否足够？其他开发人员也会使用此活动吗？既然活动是一项工作，这可以分享吗？

我需要澄清一下。

谢谢。

我们提出了 Rational ClearCase UCM 模型的流结构。

我们最近将代码库迁移到了新设置中。我们有三个不同的代码库，即三个物理代码库。

迁移过程：

我们首先移动了生产代码，创建了一个活动，将活动交付给集成流，创建了一个基线。
然后 uat 代码创建了一个活动，将活动交付给集成流，在合并期间，我们选择了贡献者 2 的更改以保留来自 uat 的现有代码，创建了一个基线。开发环境的相同过程。

截至目前，集成流具有最新的基线，即开发基线。
现在，我们还有另外两个流用于 prd 和 uat，将在各自的环境中从中完成发布。

我现在有我的开发流。我创建了一个活动并进行了一些更改。现在我需要将这些更改推广到 uat 环境中。如果我将更改交付到集成流，则合并完成，但在开发基线上。我不想将它重新设置为 uat，因为许多开发应用程序将重新设置为不需要的 uat。

如何实现促进对 uat 环境（uat 流）的更改。好心劝告。

一个配置管理模式问题（使用 Rational ClearCase UCM）

当我使用主线方法时，我通过以下方式创建新版本：

• 从主线创建版本 1
• 在某个时刻基线版本 1，将版本 1 交付给主线
• 从主线创建第 2 版
• 在某个时刻基线版本 2，将版本 2 交付给主线
• 从主线创建第 3 版
• ETC...

工作得很好，因为路径名是/main/release 3/latest而不是/main/release 1/release 2/release 3/latestetc...

但是...当在第 1 版中是必须传播到更高版本的新元素时，我不能使用主线，因为主线已经在例如第 4 版上。

我唯一能做的就是直接从版本 1 交付/合并到版本 2。
坏事是路径名随后变成/main/release 1/release 2/latest了该文件（可能还有以后的版本）。那就是我认为不符合主线的做法。

我究竟做错了什么？

交叉发布于：http: //www.cmcrossroads.com/forums?func=view&catid=31&id=99369#99369 交叉发布于：https ://www.ibm.com/developerworks/forums/thread.jspa?threadID=330226