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

Question

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

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

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

Answer 1

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

CVS有一个类似的页面可以在这里进行转换，虽然我没有直接经验。 这些链接是开始的好地方。 您还可以在此处的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）。