我工作的公司有超过 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 数据库运行每周压缩和修复。
人们认为哪个选项最好？有没有其他人遇到过类似的情况？
这三个选项对我来说没有任何意义。如果您希望从 SourceSafe 迁移，并且已经决定迁移到 TFS（至少对于您的 .NET 项目），那么您基本上要问的是是否有一种好方法可以迁移 1000 的源旧技术应用到 TFS？
我的建议是简单地将源代码管理资源管理器用作 TFS 的 SCC 客户端。它的工作方式类似于 SourceSafe GUI。有什么不可行的理由吗？
恕我直言，问题是您对“项目”的定义。团队项目是用于定义流程和隔离的高级容器。没有理由不拥有具有复杂源代码树的 VB6 团队项目。无需为每个 VB6 应用程序创建实际的“分支”（在分支和合并中）。与 SCC 中的文件夹结构相同。
所以基本上我看不出有任何理由不做你的第一个选择——只是不要为分支的开销而烦恼（除非你真的需要它）
在这种情况下，选项 3 似乎是最经济的选择，假设 VSS 存储库的大小保持在 <1-2GB 以内（我的理解是，当它们变大时，它们更容易损坏——这超出了记忆力，但是，所以我可能是错的）。将 VSS 备份保存在物理上独立的位置以备不时之需，否则请保持原样。像您在一般情况下描述的那样采取行动的投资回报率相对较低。
Git > TFS，改用它。