在这里，我们一直在使用一堆Visual Source Safe存储库大约10年左右。
现在我想摆脱sourcesafe并继续使用Team Foundation Server。
在我开始迁移之前，您有任何提示或技巧吗？有什么事我要小心？
我确信这种迁移意味着我们的工作习惯必须以某种方式进行修改。你认为这些变化对组织来说可能是一个问题吗？在一个站点中考虑一组约20个.NET开发人员。
答案 0 :(得分：11)
您可以通过几种不同的方式进行迁移。该工具将提取您的历史记录等，但更实用和简单的方法是将VSS锁定为历史存档并重新开始：
对于转换之前的任何历史记录，人们需要去VSS，但在一两个星期之后，实际上不太可能经常发生这种情况。而且您知道VSS中的历史记录是准确的，并且不会被转换过程破坏。
答案 1 :(得分：8)
请注意，TFS不支持在VSS之间共享不同项目之间的文件。如果您有任何此类共享文件，那么它们之间的链接将在迁移期间中断，从而导致每个项目中最初相同但现在不同的文件。 TFS中其中一个文件的更新将不再传播到其他项目中的副本。
答案 2 :(得分：6)
如果您确实选择使用Visual Studio Team Foundation Server附带的VSSConverter.exe工具，则应首先安装TFS 2008 SP1，因为它包含一些详细的on this blog by the migration tools team改进。
的一些关键特征 发布包括：
消除名称空间冲突。一世 以前在博客上写过这个“ 重命名问题“我们已经修好了 转换器以正确迁移文件 具有重叠的命名空间。这是 对大多数用户来说最大的痛点 试图使用以前的版本 工具。
自动解决方案重新绑定。 在这个最新版本中，VS解决方案 文件将自动升级 到9.0版本并重新签入 版本控制。以前的用户 需要手动完成此操作。
更正时间戳 不一致即可。使用客户端 VSS的时间戳可以导致 修改记录在 与他们实际相反的顺序 发生在。工具现在识别出来 这个问题并继续迁移 改变以前的地方 失败。
改进了日志记录。虽然 我们已经解决了很多问题 更好，更详细的日志记录 帮助遇到问题的用户 诊断问题。
答案 3 :(得分：2)
我只是用谷歌搜索，但this walkthrough似乎是一个很好的参考，它提到了VSSConverter工具，它可以帮助你尽可能轻松地进行迁移。
我想推荐一件事：备份。在执行此操作之前备份所有内容如果出现任何问题，最好是安全而不是抱歉。
我的链接没有显示出来。这是地址：http://msdn.microsoft.com/en-us/library/ms181247(VS.80).aspx
答案 4 :(得分：2)
我们目前正在从事日常工作。我们实际上是在大约一个月内完成切换。我是迁移的主要部分，也是我们离开SourceSafe的重要原因。为了帮助迁移，我使用了Visual Studio® Team System 2008 Team Foundation Server and Team Suite VPC Image。这非常有用。马上，图像包含一个完整的TFS安装，供您玩和演示。它还包括Hands on Labs，其中一个实验室正在运行VSS - ＆gt; TFS迁移工具。如果您有MSDN订阅，一旦您使用了图像，下一步就是安装订阅附带的TFS Small Team版本。
需要注意的一件事是确保为Visual Studio 2008安装最新的Service Pack，并在映像上安装.NET Framework。服务包修复了一些恼人的错误，它肯定增加了系统的可用性。我们有一个非常大的SourceSafe数据库，包含大约90多个项目，迁移工具大约需要32个小时才能完成。首先，我备份了我们的sourcesafe数据库进行测试。然后我在测试sourcesafe数据库上进行了迁移。之后，我检查了TFS中的源代码树，一切都转好了。我们保留了来自VSS的源文件的所有历史记录，这非常棒。我们上线后无需保持那个发臭的VSS数据库。
我们正在逐步进行迁移。首先是源代码控制，让我们的开发人员可以使用它。之后，我们将迁移质量保证和业务分析师，以使用工作项跟踪功能。
我的建议是逐步进行迁移。一次不要做太多。为将要使用该系统的人提供时间训练。
答案 5 :(得分：2)
VSS Converter是一个远非完美的解决方案。 2005年和2008SP1版本的转换器之间存在显着差异。
例如，在长期使用的VSS数据库中，会有大量用户参与VSS。其中许多用户很久以前就离开了该组织，因此将不再拥有域帐户。 TFS要求将VSS用户映射到域帐户，因此您必须决定是将旧用户映射到单个“虚拟”域帐户还是映射到当前团队成员。
此外，VSS Converter 2008要求这些域帐户是有效的TFS帐户。而2005年的转换器并未强制执行此操作。
如果您的VSS历史记录包含重要的文件夹移动，那么您可能会在此移动之前丢失所有历史记录。例如，如果将文件夹移动到新位置，然后删除上一个父级，则将丢失所有历史记录。有关更多说明，请参阅此文章： http://msdn.microsoft.com/en-us/library/ms253166.aspx
在我参与的一次迁移中，我们有一个10岁的VSS数据库，在6个月前丢失了所有历史记录。这是因为6个月前发生了显着的整理。
答案 6 :(得分：2)
TFS conversion tool＆lt; - 使用此
我已经使用过这个工具已经有好几次了，结果非常令人满意，因为如果你愿意的话，还会附带来自SourceSafe的变更集的历史。
无论如何，使用这个工具你应该始终注意日志中的错误和警告，并检查所有内容是否正常/通过。
建议在运行之前对SS进行分析。
希望有所帮助
答案 7 :(得分：1)
我的前任大师盖伊星巴克给了我很好的指导。使用这种方法添加的另一件事 - 您可能已经决定了您希望重构应用程序的组织方式（文件夹等），这将使您有机会这样做。
我一直处在这样的情况下，我们在没有想到的情况下随意组织解决方案（更不用说应用程序中的重大变化），这导致了以不同方式组织事物的愿望 - 从VSS到TFS的转变是一个很好的机会
就原来的问题而言：
而且：这种迁移肯定意味着我们的工作习惯必须以某种方式进行修改。你认为这种变化对组织来说可能是个问题吗？在一个站点中想想一组约20个.net开发人员
我会说 - 是的，你的工作习惯会发生变化，但会变得更好。
至于你的经历如何变化的细节，我的另一位前同事（和团队系统MVP）Steve St. Jean写了一篇关于差异的详细文章：From VSS to TFS