将Clearcase迁移到X

Question

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

• 一半的开发团队使用集成视图、开发视图、重基和交付方法。其余的只是直接处理它们的集成流和私有视图，就好像它是主干一样。
• 所有的团队都使用基线来标记版本。
• 他们声称面临着与Clearcase-UCM合并的问题，所以选择必须有很好的合并能力。
• 零维护--该工具没有VCS管理。基于
• Windows的开发，因此该工具必须有良好的win32支持。
• IDE集成
• 拥有:迁移工具.

<代码>F 217

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

Answer 1

我不能为迁移工具说话，但mercurial对我们非常有用。我们有一个WinXP，Mac和Linux的混合，没有任何障碍。我不使用IDE，但我相信Aptana获得了pydev组()，所以如果他们拥有这个组，我不会感到太惊讶。

Answer 2

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

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

此外，您还需要重新创建UCM依赖项的概念(“编辑基线依赖项”，这些工具都没有)。

在这个SO answer中描述了最接近的近似原理:它可以完成，但仍然是手动的。

注意：“零维护-没有VCS管理的工具。”错，祝你好运：

• backup
• DRP (灾难恢复计划)对某些存储库具有“敏感”content
• scripting和特定operations
• ....

的客户端封装的

• 访问权限

不管你会选择什么工具，你都需要一个管理员(不是全职的，但仍然很喜欢管理任务)。

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

对于Git来说，提交是活动中最接近的东西，特别是因为'git rebase -i‘(重基交互)允许您重新定义提交的内容(有点像您再次为新签出选择某个活动时那样)。

关于合并，由于它们在Git或Mercurial中非常容易，所以没有通过交付/重基操作正式定义的真正的“合并工作流”。

而是创建私有分支，并根据用户的需要使用/合并，其中一些分支被发布到另一个外部存储库。

Answer 3

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

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

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

您可能还想考虑如何将您的开发人员从ClearCase中转移到新工具上。在我的经验中，迁移工具80%是关于人的。他们可能会在此刻痛苦地抱怨，但是当你的零维护场景中的新工具不太顺利时，他们的观点可能会改变.去过那里。

如果他们合并有困难，那就不能保证去另一个工具就能解决这个问题。如果迁移后问题仍然存在，那么您就会知道，问题不在于工具。

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