由于合并和收购，用于集成各种版本控制系统或从中选择一种的方法？

公司收购了其他使用不同版本控制系统的公司。

对于如何将此类系统集成在一起（例如使用Subverson-GIT桥，甚至决定只使用一种工具而不是另一种工具）以及如何在系统之间进行迁移，是否存在共识？

人们是否使用诸如此类的决策标准，例如等同于软件开发的“ Joel”测试？

要从几次迁移的亲身经历中回答迁移问题：

不要害怕仅仅将软件的当前版本作为新的源代码控制系统作为基准并从那里开始工作。

在绝大多数情况下，您不需要历史记录。这意味着在集成过程中要执行的任务少一件事，而出错的事情也少一件事。

正在积极开发的文件/项目将很快产生新的历史记录。因此，当您需要找出进行更改的原因时，历史记录将在当前存储库中，因为它是最近的更改。

在迁移之前保持稳定的文件/项目（在所有条件相同的情况下）在迁移之后应保持稳定，因此您无需参考历史记录。我们发现，如果我们必须调查这样的具有历史记录的旧文件/项目中的错误，实际上并没有任何好处。只要您将旧存储库保持为每年6个月可用，在这种情况下，您将获得参考。

在管理方面，主要是以下问题：

• 支持：如果出现问题，发布VCS的公司是否仍会存在？
  令人遗憾的是，仍然考虑使用诸如ClearCase之类的过时产品的主要原因之一（ClearCase自2003年以来就是... IBM产品）。
• 许可证成本：即使有免费软件的替代品，有时也可以协商VCS的“组许可证”或将其实际包含在更大的合同中，包括服务器，网络，支持等。费用远低于公共价格。

在项目方面，这也是一个问题：

• 管理：您将在哪个服务器上安装VCS（如果我们谈论的是Git，SVN等，则要安装多个VCS）？有什么备份策略？什么DRP（灾难恢复计划）？
• 本地支持：谁将获得1级支持？2级？
• 市场知识：您确定找到足够的具有适当知识的开发人员和/或管理员来利用此VCS及其所有功能吗？

是否有免费软件，请记住，“免费”软件是免费的，就像“言论自由”（您可以自由选择和部署所需的软件）一样，而不是“免费啤酒”（在服务器上仍然会花费很多钱） ，备份，管理，支持...）

上面提到的标准是确定保留什么VCS，放弃什么的开始。
但是在后一种情况下，您需要考虑：

• 迁移策略：可以将项目历史记录从一个VCS导出/导入到另一个VCS吗？
• 过渡策略：在两个不同的VCS中具有历史记录是否有意义？
• 项目过时：如果项目处于维护/生命周期终止状态，则最好暂时支持旧的VCS。

您是否真的需要集成不同的系统？在我们的团队中，每个项目都位于其自己的存储库中，因此它们的历史是独立的。我们在这里可以毫无问题地处理一些处于颠覆状态的项目，而可以处理一些处于轻浮状态的项目，即使它们之间存在依赖性。

如果选择从一个VCS迁移到另一个，请查看可用的转换工具。根据我的经验，没有任何技术理由放弃项目的历史。

编辑

我想我理解了一些问题和其他答案中所隐含的内容。事实上，VCS也用于管理依赖项。我知道使用VCS功能（例如svn:externals将一个存储库（依赖项）与另一个存储库集成）是很常见的。

我认为我们的团队不需要桥接（或集成）我们的两个不同系统的（技术上的）原因是我们拥有一个单独的工具来管理依赖项。我们的仓库彼此不认识。

有很多好的答案。需要考虑的另一件事是，不要让团队成员认为切换VC如此重要。迁移，学习曲线等都会使您遇到挫折，但是如果他们有太多问题，他们需要质疑他们的能力和/或合作水平。