TFS从Source Safe迁移大量项目的策略

Question

我工作的公司有超过1000个我们维护的应用程序。其中许多都是旧技术，如VB6，或差技术（Access）。

我们希望远离Source Safe。我们正在运行TFS，我们正在将dot.net项目移至TFS。其他项目没有与TFS集成，也不需要门户或任何其他TFS功能（源代码控制除外）。

由于产品不可靠，我担心将其他项目留在Source Safe中。

据我所见，有两种选择：

1）在TFS中创建一个名为“VB6”的空项目（例如）。为VSS中的每个VB6应用程序分支它。这将把所有VB6应用程序放在该子文件夹中。这样，所有应用都可以使用TFS。

2）将点网项目放入TFS。创建一个CVSNT存储库并将所有其他VSS项目放在那里。

3）将点网项目放入TFS。将所有其他项目保留在VSS中。在所有VSS数据库上运行每周一次的压缩和修复。

人们认为哪种选择最好？还有其他人处于类似情况吗？

Answer 1

这三个选项中没有一个对我有意义。如果你想要远离SourceSafe，并且已经决定转移到TFS（至少对于你的.NET项目），那么基本上你要问的是，是否有一种很好的方法来迁移1000的源代码旧技术应用到TFS？

我的建议是简单地使用Source Control Explorer作为TFS的SCC客户端。它的工作原理类似于SourceSafe GUI。任何不起作用的理由？

Answer 2

问题恕我直言是你对“项目”的定义。 Team Project是一个用于定义进程和隔离的高级容器。没有理由不使用具有复杂源树的VB6团队项目。对于每个VB6应用程序，无需为分支和合并创建实际的“分支”（在分支和合并中）。与SCC中的文件夹结构相同。

基本上我没有看到任何理由不做你的第一个选择 - 只是不要担心分支的开销（除非你真的需要它）

Answer 3

选项3似乎是这种情况下最经济的赌注，假设VSS存储库的大小保持在<1-2GB（我的理解是，当它们变大时它们更容易发生腐败 - 这个但是，现在是关闭记忆，所以我可能是错的）。将VSS的备份保存在物理上独立的位置以进行保险，否则保持原样。在一般情况下，像你描述的那样进行移动的投资回报率相对较低。

Answer 4

Git＆gt; TFS，改为使用它。