将 Clearcase 迁移到 X

Question

我被要求选择 Clearcase-UCM 的开源替代品，我需要一个建议，什么是最佳匹配。以下是我收集的一些参数：

• 一半的开发团队使用集成视图、开发视图、变基和交付方法。其余的只是直接在他们的集成流上使用私有视图，就好像它是主干一样。
• 所有团队都使用基线来标记版本。
• 他们声称面临与 Clearcase-UCM 的合并问题，因此替代方案必须具有精心设计的合并功能。
• 零维护 - 该工具没有 VCS 管理员。
• 基于Windows的开发，所以该工具必须有良好的win32支持。
• IDE 集成 (eclipse)。
• Mac-OS 支持。
• 很高兴拥有：迁移工具。

哪种工具适合这两种工作方法（两个小组都不会采用另一种方法）？ 到目前为止，我有 svn、mercurial 和 git 作为替代方案。其中一个适合吗？还有其他选择吗？

Answer 1

我不能代表迁移工具，但 mercurial 对我们来说非常有用。我们混合了 WinXP、Mac OS X 和 Linux 人员，并且没有遇到任何障碍。我不使用 IDE，但我相信 Aptana 收购了 pydev 组（Python for Eclipse），所以如果他们拥有它，我不会太惊讶。

Answer 2

在使用 UCM 并创建基线时，您可以有效地识别存储库的预定义子组的修订版（在 Vob 中定义的 UCM 组件，除非您已将一个所有 Vob 定义为组件）

因此，如果您使用的是 SVN、Git 或 Mercurial，您必须意识到您的每个 UCM 组件实际上都是一个（SVN-Git-or-Mercurial）存储库。

另外，您将需要重新创建 UCM 依赖项的概念（“编辑基线依赖项”，这些工具都没有。）

SO answer 中描述了最接近的近似原则：它可以完成但仍然是手动的。

注意：“零维护 - 该工具没有 VCS 管理员。”... errr 祝你好运：

• 备份
• DRP（灾难恢复计划）
• 具有“敏感”内容的某些存储库的正确访问权限
• 某些操作的脚本和客户端封装
• ....

无论你选择什么工具，你都需要一个管理员（不是全职，但仍然非常参与管理任务）

---

关于“可追溯性”，主要由 UCM 中的活动表示，但也由允许定义合并工作流的流层次结构表示，它在 Git/Mercurial 中不能很好地转换：这些工具是不同的。

对于 Git，提交是最接近活动的东西，特别是因为“git rebase -i”（rebase 交互式）允许您重新定义提交的内容（有点像再次为新的活动选择结帐）
关于合并，由于它们在 Git 或 Mercurial 中非常容易，因此并没有通过交付/rebase 操作正式定义的真正的“合并工作流程”。
而是在用户认为合适的情况下创建和使用/合并私有分支，其中一些分支被发布到另一个外部存储库。

Answer 3

在某种程度上，技术部分是容易处理的——你可以在 MacOSX 上使用它，或者你不能等等。棘手的部分是你作为 CC 许可证的一部分购买的“服务”，以及这些对开发人员来说并不明显，开发人员也不一定会关心。

贵公司的资产将存放在由您选择的工具管理的存储库中，从一种工具转移到另一种工具并不总是那么容易。因此，很大程度上取决于产品的生命周期。它们在市场上是否存在 6 个月、6 年甚至更长的时间？其中一些工具的问题只出现了几年，并且在某种程度上受到时尚的影响。 Git 受到青睐，Bazaar 似乎已经失宠。

我的建议是查看 Rational 在您当前的安排下提供什么，并尝试找到一个服务提供商支持的工具，该工具将为您提供同等服务。然后比较成本。

您可能还想考虑如何让您的开发人员离开 ClearCase 并使用新工具。根据我的经验，迁移工具 80% 与人有关。他们现在可能会为此痛苦地抱怨，但是如果在您的零维护场景中使用新工具时事情进展不顺利，那么他们的观点可能会改变......一直在那里。

如果他们在合并时遇到问题，则无法保证使用其他工具可以解决问题。如果迁移后问题仍然存在，您将知道问题不是工具。

任何工具都可以零维护。它坏了，你不修复它，然后迁移到另一个“本月工具”。