Cvs中大约有200个项目，而vss中至少有100个项目。有些在维护模式下是无效代码。有些是旧版应用程序。有些是不再使用的旧应用程序。约有10％处于积极发展中。该计划是为了使一切都顺利进行，直到2009年年底。

有没有人做过这样的大迁移？

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

解决方案

回答

原谅我对一个问题的回答，但是Perforce不能为此提供工具吗？或者至少是文档？我会殴打我的Perforce销售人员...

回答

我不必做这种规模的事情，但是我有一些想法。首先，首先进行一个不重要的小项目，然后进行移植。这将使我们了解迁移其余项目将需要多少麻烦。之后，我们应该立即选择一个中等规模的项目，因为迁移较大的项目(例如分支机构)可能会出现问题，而在小型项目中可能看不到。

确保花些时间看看将cvs项目转换为vss是多么容易，或者反之亦然。如果从vss转换为perforce确实很痛苦，则可以将vss转换为cvs，然后再转换为perforce。不要花很多时间，但是它可以使我们摆脱困境。我认为这里的关键是渐进式。

备份很好。时期。

考虑一个截止日期，所有闲置且早于该日期的项目都应予以搁置。签出最终修订版并将其存储在Perforce中。我们真的需要15年的视觉基本代码吗？

回答

在VSS端，有一些转换工具可用来帮助迁移。他们大多可以维护版本历史记录(自述文件和文档中有一些警告)。我已经使用VSS Perforce工具将50多个VSS项目迁移到了perforce中。从VSS提取数据可能有点棘手，而且速度不是很快，但是可以正常工作。如果我们可以直接访问VSS存储库中的磁盘(即不通过网络共享)，则转换可以更快。我们可以在此处找到有关脚本的信息。

尽管我没有直接的经验，但这里有一个类似的页面可供CVS进行转换。这些链接是开始的好地方。我们也可以在此处的Perforce知识库中搜索Perforce邮件列表。我很确定我们可能会在邮件列表档案中找到一些转换信息。

首先迁移旧项目。我们可以确保过程正常运行。当我们将活动代码迁移到Perforce时，我花了一个周末基本上取消了对服务器的访问，并将代码移至Perforce。老实说，这是一个非常容易的迁移，当人们星期一返回时，他们准备出发了。开始迁移后，我们可能会考虑为员工准备Perforce速查表。

实际上，最大的陷阱可能是使员工准备使用Perforce。如果我再做一次，我将首先迁移我们较小的活动项目，并准备让较少的人立即使用Perforce。照原样，迁移后的第一天我必须训练120多人，这有点多。另外，请确保在第一天，也没有超过100人在服务器上进行新的同步。在最初的几天里，我们多次关闭服务器。我们使用了Windows 32位服务器，我不建议这样做。我们现在有一个Windows 64位服务器，功能更加强大。如果可以，我实际上将Linux用作perforce服务器的操作系统。同样，在Perforce站点上应该有关于性能的良好信息。

回答

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

如果某个未迁移的项目在将来的某个时间复活，则可以使用文档作为参考轻松地进行迁移。

回答

无论我们做什么，都将旧存储库保留在只读模式下的某个位置。

回答

我们使用编写的工具迁移了svn存储库，并刚刚完成了starteam项目的主修订版。

注意单文件检入(CVS)和多文件变更集(Perforce)之间的区别。

注意分支是独立空间(CVS)，而不是文件路径空间(Perforce)中的分支。