![]() |
1
11
有几种不同的迁移方法。该工具将结束您的历史记录等,但更实用、更简单的方法是将VSS锁定为历史记录存档并重新开始:
对于转换之前的任何历史记录,人们都需要去VSS,但在一两周后,实际上不太可能经常发生这种情况。您知道VSS中的历史记录是准确的,并且不会被转换过程损坏。 |
![]() |
2
8
请注意,TFS不像VSS那样支持在不同项目之间共享文件。如果您有任何此类共享文件,则它们之间的链接将在迁移过程中中断,从而在每个项目中产生最初相同但现在不同的文件。对TFS中其中一个文件的更新将不再传播到其他项目中的副本。 |
![]() |
3
6
TFS 2008 SP1 首先,因为它包括许多详细的改进 on this blog by the migration tools team .
|
![]() |
4
2
我们目前正在我的日常工作中这样做。事实上,我们将在大约一个月内完成转换。我是迁移的主要部分,也是我们脱离SourceSafe的主要原因。为了帮助迁移,我使用了 Visual Studio® Team System 2008 Team Foundation Server and Team Suite VPC Image . 这是非常有用的。使用TFS进行完整安装,并使用TFS进行右侧播放。它还包括动手实验室,其中一个实验室正在运行VSS->TFS迁移工具。如果您有一个MSDN订阅,一旦您使用了该映像,下一步将是安装订阅附带的TFS Small Team edition。 需要注意的一点是,确保您在映像上安装了最新的Visual Studio 2008 Service Pack和.NET Framework。该服务包修复了一些恼人的bug,并无疑提高了系统的可用性。我们有一个非常大的SourceSafe数据库,其中包含大约90多个项目,迁移工具大约需要32小时才能完成。首先,我备份了我们的sourcesafe数据库进行测试。然后,我在测试sourcesafe数据库上进行了迁移。之后,我检查了TFS中的源代码树,一切都正常。我们保留了VSS中源文件的所有历史记录,这非常棒。在我们上线后,不需要保留那个臭烘烘的VSS数据库。 我们正在逐步进行迁移。首先是源代码控制,让我们的开发人员习惯使用它。然后,我们将迁移QA和业务分析师,以使用工作项跟踪特性。 我的建议是分步进行迁移。一次不要做太多。给将使用该系统的人员留出时间进行培训。 |
![]() |
5
2
VSS转换器远不是一个完美的解决方案。2005和2008SP1版本的转换器之间存在显著差异。
此外,VSS Converter 2008要求这些域帐户是有效的TFS帐户。而2005年的转换器没有强制执行这一点。 http://msdn.microsoft.com/en-us/library/ms253166.aspx 在我参与的一次迁移中,我们有一个有10年历史的VSS数据库,它在6个月前丢失了所有历史记录。这是因为6个月前进行了一次重大清理。 |
![]() |
6
2
我只是在谷歌上搜索,但是 this walkthrough 似乎是一个很好的参考,它提到了工具VSSConverter,它应该帮助您尽可能轻松地进行迁移。 不过我想推荐一件事:备份。在执行此操作之前备份所有内容。万一出了什么差错,与其说抱歉,不如说安全。 我的链接没有显示。这是地址: http://msdn.microsoft.com/en-us/library/ms181247(VS.80).aspx |
![]() |
7
2
TFS conversion tool <——用这个 我已经使用这个工具很多次了,如果您愿意的话,结果非常令人满意,因为它附带了SourceSafe的变更集历史记录。
建议在运行此之前也对SS进行分析。 希望能有帮助 |
![]() |
8
1
我以前的同事星巴克给了我很好的指导。使用这种方法还需要补充的一点是,随着时间的推移,您可能已经决定要重构应用程序的组织方式(文件夹等),这将给您一个这样做的机会。 我曾经遇到过这样的情况:我们随意地组织了一个解决方案,而没有考虑(更不用说应用程序中的重大更改),这导致了我们希望以不同的方式组织事情——而从VSS到TFS的转变是这样做的一个绝好机会。 关于原来的问题:
我会说——是的,你的工作习惯会改变,但会越来越好。
关于你的经历将如何改变的细节,我的另一位前同事(也是团队系统MVP)Steve St.Jean写了一篇关于差异的详细文章: From VSS to TFS |