Visual Source Safe - > TFS迁移

在这里，我们已经使用了大量的Visual Source Safe存储库大约10年左右。Visual Source Safe - > TFS迁移

现在我想摆脱sourcesafe并转到Team Foundation Server。

在我进行此迁移之前，您有任何提示或技巧吗？我必须注意哪些事情？

我确信这种迁移将意味着我们的工作习惯必须以某种方式进行修改。你认为这些变化可能会给组织带来问题吗？在一个站点上考虑一组大约20位.NET开发人员。

来源

2008-08-27 ila

我刚刚搜索了一下，但this walkthrough看起来是一个很好的参考，它提到了VSSConverter这个工具，它应该可以帮助您尽可能轻松地完成迁移。

我想推荐一件事：备份。在做这件事之前备份所有东西。如果出现任何问题，最好安全，而不是抱歉。

我的链接没有显示出来。这是地址：http://msdn.microsoft.com/en-us/library/ms181247(VS.80).aspx

来源

2008-08-27 10:20:38 deadtime

迁移到TFS2010过程在http://msdn.microsoft.com/en-us/library/ms253060.aspx – benophobia 2010-08-07 09:59:08

有几种不同的方法可以迁移。该工具会拉你的历史记录等结束了，但更加务实和简单的方法就是锁定VSS为历史存档和新鲜的开始：

让每个人都检查所有变为VSS，确保一切建立，等
将所有VSS数据库，以“锁定”（对所有用户只读权限）
获取最新的整个VSS数据库变成“干净”的文件夹集的工作站上
检查所有的文件从工作站转换为TFS

对于转换之前的任何历史记录，人们需要转到VSS，但是在一两周后，它实际上不太可能经常发生。而且您知道VSS中的历史记录是准确的并且不会被转换过程破坏。

来源

2008-08-27 18:29:53

请注意，TFS不支持在不同项目之间共享文件，就像VSS一样。如果您有任何这样的共享文件，它们之间的链接将在迁移过程中被破坏，从而导致每个项目中最初相同但现在不同的文件。对TFS中这些文件之一的更新将不再传播到其他项目中的副本。

来源

2008-08-27 18:58:12

详述真的错过了这一壮举。 :( – 2013-10-01 02:58:05

我们目前正在做我的日常工作。我们实际上正在大约一个月内完成切换。我是迁移的主要部分，也是我们为什么要脱离SourceSafe的重要组成部分。为了帮助迁移，我使用了Visual Studio® Team System 2008 Team Foundation Server and Team Suite VPC Image。这非常有用。就在蝙蝠身上，图像包含一个完整的TFS安装，供您玩和演示。它还包括Hands on Labs，其中一个实验室正在运行VSS - > TFS迁移工具。如果您有MSDN订阅，一旦您使用了该映像，下一步就是安装您的订阅附带的TFS小团队版本。

需要注意的一件事是确保获取Visual Studio 2008的最新Service Pack以及映像上安装的.NET Framework。该服务包修复了一些烦人的错误，并明确提高了系统的可用性。我们有一个非常大的SourceSafe数据库，大约有90多个项目，迁移工具大约需要32个小时才能完成。首先，我对我们的sourcesafe数据库进行了备份以进行测试。然后我在测试sourcesafe数据库上进行迁移。之后，我检查了TFS中的源代码树，并且一切正常。我们保留了来自VSS的源文件的所有历史，这非常棒。我们上线后不需要保留那个发臭的VSS数据库。

我们正在逐步进行迁移。首先是源代码控制，让我们的开发人员使用它。之后，我们将把QA和业务分析师迁移到使用工作项目跟踪功能。

我的建议是逐步进行迁移。不要一次做太多。为将要使用该系统的人员提供时间进行培训。

来源

2008-08-27 19:05:49

从我以前的同事Guy Starbuck那里得到了很好的指导。还有一件事要用这种方法来补充 - 你可能会随着时间的推移决定重构应用程序的组织方式（文件夹等），这会给你一个机会来做到这一点。

我一直处于无意识地组织解决方案（更不用说应用程序发生重大变化）的情况下，这导致了对组织方式有不同要求的渴望 - 从VSS到TFS的转变是一个非常棒的机会所以。

至于原题：

和：这个迁移将肯定意味着我们的工作习惯必须以某种方式修改。你认为这种变化可能是该组织的问题吗？想想一组20个.net开发者，在一个单一的网站

我会说 - 是的，你的工作习惯会改变，但更多的更好。

你不应该使用“签出”锁和“取得最新签出”。
您现在可以有效地分支和合并
您现在将具有“更改集”，同时签入的所有文件将被组合在一起。这使得历史更改跟踪变得更容易 - 但更重要的是 - 回滚更容易（即同时查找所有文件并将其回滚）
将签入与工作项目相关联。不要忽视工作项目！您可以犯的最大错误是仅将TFS用作VSS替代品。构建和项目管理功能非常出色 - 您为它们付费 - 使用它们！

至于你的经验将如何改变的细节，矿山（和团队系统MVP）的另一位前同事史蒂夫圣让写上的差异详细的文章：From VSS to TFS

来源

2008-09-07 14:04:09 fuzzbone

如果你选择使用Visual Studio Team Foundation Server附带的VSSConverter.exe工具，那么您应该首先安装TFS 2008 SP1，因为它包含许多改进，详情如下：on this blog by the migration tools team。

一些版本的主要功能包括：

命名空间的冲突消除。我之前在博客的博客中将此作为“ 重命名问题”，我们修复了转换器以正确迁移具有重叠名称空间的文件。这是对于大多数用户试图使用以前版本的工具的最大痛点。

自动解决方案重新绑定。 在这个最新版本中，VS解决方案文件将自动升级到到9.0版本并在中检查到版本控制。以前用户需要手动完成此操作。

更正时间戳不一致性。使用客户端的时间戳通过VSS可以导致被记录在相反的顺序修订，他们其实发生在该工具现在可以识别这个问题，并继续迁移变化的地方原先会失败。

改进的日志记录。虽然我们已经修复了很多问题，提供了更好的，更详细的日志记录将帮助遇到问题的用户诊断问题。

来源

2008-09-16 07:14:00

VSS Converter是一个非常完美的解决方案。 2005年和2008SP1版本的转换器之间存在显着差异。

例如，在长期使用的VSS DB中，会有大量用户参与VSS。其中许多用户很早以前就会离开该组织，因此将不再拥有域帐户。 TFS要求将VSS用户映射到域帐户，因此您必须决定将旧用户映射到单个“虚拟”域帐户还是映射到当前团队成员。

此外，VSS Converter 2008要求这些域帐户是有效的TFS帐户。而2005转换器不强制执行此操作。

如果您的VSS历史包含重要的文件夹移动，那么很可能您在此移动之前将放弃所有历史记录。例如，如果您将文件夹移动到新位置，然后删除上一个父文件夹，则会丢失所有历史记录。看到这篇文章的更多解释： http://msdn.microsoft.com/en-us/library/ms253166.aspx

在我参与的一个迁移，我们有一个10岁的VSS数据库，在6个月前失去了所有的历史。这是由于6个月前发生的重大整顿所致。

来源

2008-12-17 14:10:35 RichB

TFS conversion tool < - 使用此

我用这个工具，有些时候已经，结果是相当satisfatory因为它与变更集从SourceSafe的历史，如果你的愿望了。

无论如何，使用这个工具你应该一直注意日志中的错误和警告，并检查一切构建好还是传递好。

建议在运行之前运行SS分析。

希望它可以帮助

来源

2015-07-29 12:11:15

Visual Source Safe - > TFS迁移

回答

相关问题