可视化源代码安全-->TFS迁移

有几种不同的方式可以迁移。该工具将提取您的历史记录等,但更实用和简单的方法是将VSS锁定为历史档案并重新开始:

1. 让每个人都检查VSS中的所有更改,确保所有内容都已构建等。
2. 将所有VSS数据库设置为“锁定”(所有用户的只读权限)
3. 将整个VSS数据库的最新信息保存到工作站上的一组“干净”文件夹中
4. 从工作站将所有文件检入TFS

对于转换之前的任何历史记录,人们都需要去VSS,但一两周后,这种情况实际上不太可能经常发生。您知道VSS中的历史记录是准确的,不会被转换过程破坏。

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

如果选择使用Visual Studio Team Foundation Server附带的VSSConverter.exe工具,则应安装 TFS 2008 SP1 首先,它包括一些详细的改进 on this blog by the migration tools team .

的一些关键特征 发布内容包括:

消除命名空间冲突 一、 之前在博客中曾这样写道“ 重命名问题”,我们已经修复了 转换器以正确迁移文件 名称空间重叠。这是 大多数用户最大的痛点 尝试使用以前版本的 工具。

自动溶液重新绑定。 在这个最新版本中,VS解决方案 文件将自动升级 转到9.0版本并重新签入 版本控制。以前的用户 需要手动执行此操作。

时间戳的修正 不一致 .客户端的使用 VSS的时间戳可能导致 正在记录的修订 相反的顺序,他们实际上 发生在中。该工具现在可以识别 此问题并继续迁移 改变了以前的样子 失败。

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

我只是在谷歌上搜索,但是 this walkthrough 这似乎是一个很好的参考,它提到了VSSConverter工具,该工具可以帮助您尽可能轻松地进行迁移。

我想推荐一件事:备份。在执行此操作之前,请备份所有内容。如果出了什么问题,安全总比后悔好。

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

我们目前正在我的日常工作中做这件事。实际上,我们将在大约一个月后进行转换。我是迁移的主要参与者,也是我们退出SourceSafe的重要原因。为了帮助迁移,我使用了 Visual Studio® Team System 2008 Team Foundation Server and Team Suite VPC Image 。它非常有用。一开始,该映像包含一个完整的TFS安装,供您播放和演示。它还包括动手实验室,其中一个实验室正在运行VSS->TFS迁移工具。如果您有MSDN订阅,一旦您使用了该映像,下一步将是安装订阅附带的TFS Small Team版本。

需要注意的一件事是确保您获得Visual Studio 2008和的最新Service Pack。NET Framework已安装在映像上。服务包修复了一些恼人的错误,它无疑提高了系统的可用性。我们有一个非常大的SourceSafe数据库,包含大约90多个项目,迁移工具大约需要32个小时才能完成。首先,我备份了我们的源安全数据库进行测试。然后,我在测试源安全数据库上进行了迁移。之后,我检查了TFS中的源代码树,一切都转移得很好。我们从VSS保留了源文件的所有历史记录,这很棒。上线后,无需再保留那个糟糕的VSS数据库。

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

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

VSS转换器远非完美的解决方案。并且转换器的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个月前进行的一次重大清理。

TFS conversion tool <--使用这个

我已经使用过这个工具好几次了,结果非常令人满意,因为如果你愿意的话,它还附带了SourceSafe的变更集历史。

无论如何,使用此工具时,您应该始终注意日志中的错误和警告,并检查所有构建/通过是否正常。

建议在运行此程序之前也对SS进行分析。

希望能有所帮助

我以前的同事盖伊·斯塔巴克给了我很好的指导。使用这种方法需要添加的另一件事是,随着时间的推移,您可能已经决定重构应用程序的组织方式(文件夹等),这将为您提供这样做的机会。

我曾经遇到过这样的情况,我们不假思索地组织了一个解决方案(更不用说应用程序中的重大更改了),这导致了以不同的方式组织事物的愿望——从VSS到TFS的转变是一个很好的机会。

关于最初的问题:

而且:这种迁移肯定意味着我们的工作习惯必须以某种方式改变。你认为这种变化会给组织带来问题吗?想象一下,在一个网站上,大约有20名.net开发人员

我会说——是的,你的工作习惯会改变,但会变得更好。

1. 您不应该使用“退房”锁和“退房时获取最新信息”。
2. 您现在可以有效地进行分支和合并
3. 现在,您将拥有“变更集”,所有同时签入的文件将被分组在一起。这使得历史更改跟踪更容易,但更重要的是,回滚更容易(即同时查找所有签入的文件并回滚)
4. 将签入与工作项关联。不要忽视工作项目!您可能犯的最大错误是只使用TFS作为VSS的替代品。构建和项目管理功能非常出色-您为此付费-使用它们!

至于你的经历将如何改变的细节,我的另一位前同事(也是团队系统MVP)Steve St.Jean写了一篇关于差异的详细文章: From VSS to TFS