在版本控制系统之间移动的最佳实践是什么？

Question

cvs中有大约200个项目，vss中至少有100个项目。有些是维护模式下的非活动代码。有些是遗留应用。有些是不再使用的旧应用程序。大约10％正在积极开发中。计划是在2009年底完成所有工作。

有人做过像这样的大型迁移吗？

有没有人遇到过从cvs转到perforce的最佳做法？或类似的迁移。有什么需要注意的吗？

Answer 1

在VSS方面，有一些转换工具可用于帮助迁移。他们可以主要维护版本历史记录（有些注意事项在自述文件和文档中有解释）。我使用VSS强制工具将50多个VSS项目迁移到perforce中。从VSS获取数据可能有点挑剔，而且速度不是很快，但它确实有效。如果您可以直接访问VSS存储库中的磁盘（即不通过网络共享），则转换速度可以更快。您可以找到有关脚本here的信息。

CVS有一个类似的页面来强制转换here，虽然我没有直接经验。这些链接是开始的好地方。您还可以在位于here的Perforce知识库中搜索Perforce邮件列表。我很确定您可以在邮件列表档案中找到一些转换信息。

首先迁移旧项目。您可以确保您的流程有效。当我们将活动代码迁移到Perforce时，我花了一个周末，基本上取消了对服务器的访问，并将代码移到了Perforce上。老实说，这是一个非常容易的迁移，当人们周一回来时他们已经准备好了。在开始迁移之后，您可能会考虑使用Perforce备忘单为员工做好准备。

最大的陷阱可能实际上是让你的员工准备使用Perforce。如果我再次完成它，我会首先迁移我们较小的活动项目，并准备少数人一次使用Perforce。事实上，我必须在迁移后的第1天培训120多人，这有点多了。此外，请确保您在第1天没有100多人到您的服务器进行全新同步。我们在最初的几天里多次关闭我们的服务器。我们使用Windows 32位服务器，我不推荐。我们现在有一个Windows 64位服务器，它更强大。如果可以，我实际上会使用Linux作为您的perforce服务器的操作系统。同样，Perforce网站上应该有关于性能的良好信息。

Answer 2

我没有必要做这种规模的事情，但我有一些想法。首先，从一个小的，不重要的项目开始，然后迁移它。这将让您了解迁移其余项目将花费多少麻烦。在此之后，您应该立即选择一个中等规模的项目，因为迁移一个较大的项目（比如分支机构）可能会出现问题，而这个项目在一个小项目中可能并不明显。

确保花一点时间看看将cvs项目转换为vss是多么容易，或者反过来。如果从vss转换为perforce是一个真正的痛苦，你可以将vss转换为cvs，然后转换为perforce。不要沉沦几天，但它可以让你摆脱困境。我认为这里的关键是增量。

备份很好。周期。

考虑一个截止日期，任何不活跃的项目，以及那些早于该项目的项目都应该被封存。查看最终修订版并将其存储在Perforce中。你真的需要15年的视觉基本代码吗？

Answer 3

无论你做什么，都要将旧存储库保持在只读模式的某些位置。

Answer 4

原谅我回答了一个问题，但Perforce没有为此提供工具？或者，至少，文档？我会打败我的Perforce销售人员......

Answer 5

考虑不迁移死亡和非活动项目。只需将其存储库置于只读模式即可。如果需要，数据仍然可用，您可以节省迁移它们的时间。只需迁移正在使用的10％即可。彻底记录过程。

如果其中一个未迁移的项目将来某个时候复活，您可以使用文档作为参考轻松迁移它。

Answer 6

我们使用我们编写的工具迁移了我们的svn存储库，并且刚刚对我们的starteam项目进行了主要修订。

注意单文件签入（CVS）和多文件更改集（Perforce）之间的差异。

注意分支是独立空间（CVS）与文件路径空间中的分支（Perforce）。