Mercurial 需要定义一个工作流/流程，将软件开发一直集成到配置管理

我们有一组约10名开发人员。只编写内部测试软件的人员。到目前为止，所有的开发都是临时的，只有几个开发人员以自己的方式使用Mercurial。其他人没有使用版本控制，我知道。配置管理在过去也有点特别。 现在，母公司希望我们更加有条理。现在，我们正在强制Mercurial控制所有代码，直到母公司将我们连接到他们的公司ClearCase服务器（几个月后）

我们希望本论坛中有人能够描述一个经过验证的流程/工作流，该流程/工作流涵盖了从Mercurial到ClearCase的整个开发过程和配置管理

我们在这两种工具（Mercurial和ClearCase）方面都很有经验，但在围绕这些工具设置流程方面没有太多经验。因此，如果这里可以描述一个经过验证的过程，那么我们将以此为起点来定义我们自己的开发过程，然后再定义配置管理集成过程

使用clearcase对我们来说是强制性的，所以不需要解释clearcase的缺点

任何帮助都将不胜感激。

---

谢谢

没有服务器项目符号，这实际上取决于您打算如何使用ClearCase，它是一种CVCS（集中式VCS）。
我已在以下方面详细说明了CVCS和DVCS之间的差异：

• “”（它介于ClearCase和Git之间，但它确实适用于Mercurial），并且
• “”

我见过的唯一一个这样的集成运行良好（或者至少“不太糟糕”）的例子是在DVCS和ClearCase UCM之间

如果您当前的Mercurial存储库是围绕“组件”的概念来组织的（请参阅“”，它还解释了组件是什么，并且适用于任何源代码管理工具），那么下面的映射是简单的

one DVCS repo <=> one ClearCase UCM Component

一个DVCS回购一个ClearCase UCM组件

这允许您定义：

• 明确进口程序（基于）
• Mercurial标记和ClearCase UCM基线之间的明确匹配（由于基本ClearCase标记或“标签”是在逐个文件的基础上应用的，所以所述标签不是建模DVCS版本的好工具。DVCS标记引用的是所有存储库，而不是所述repo中的一些文件子集。）
• 清除依赖关系管理（vs）

---

我希望您能找到一个适合您的流程，但要使您的问题适合本网站，它需要是一个有答案的实际问题。你需要一个可能在别处进行的讨论。否则，把它分解成具体的问题（包括问号）并分别提问。很好的信息。非常感谢。这应该让我们开始。