视觉源安全 --> TFS迁移
在这里，我们已经与许多 Visual Source Safe 存储库合作了大约 10 年左右。
现在我想摆脱 sourcesafe 并转向 Team Foundation Server。
在我开始迁移之前，您有什么提示或技巧可以给我吗？ 我需要注意哪些事项？
我确信这种迁移将意味着我们的工作习惯必须以某种方式改变。 您认为这些变化会给组织带来问题吗？ 想象一下在一个站点中大约有 20 名 .NET 开发人员的团队。
Around here we have been working with a bunch of Visual Source Safe repositories for about 10 years or so.
Now I want to get rid of sourcesafe and move on to Team Foundation Server.
Do you have any tips or tricks for me before I embark on this migration? What are the things I have to be careful about?
I am sure this migration will mean that our working habits have to be modified in some way. Do you think that these changes could be a problem for the organization? Think about a group of about 20 .NET developers in a single site.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我以前的同事盖伊·斯塔巴克（Guy Starbuck）给了我很好的指导。 使用该方法需要添加的另一件事 - 随着时间的推移，您可能已经决定要重构应用程序的组织方式（文件夹等），这将为您提供这样做的机会。
我曾经遇到过这样的情况：我们不经思考就随意组织了一个解决方案（更不用说对应用程序进行重大更改），这导致我们希望以不同的方式组织事物 - 从 VSS 迁移到 TFS 是这样做的一个很好的机会。
至于原来的问题：
我会说 - 是的，您的工作习惯会改变，但会变得更好。
至于您的体验将如何改变的详细信息，我的另一位前同事（团队系统 MVP）Steve St. Jean 写了一篇关于差异的详细文章：从 VSS 到 TFS
Good guidance there from my former colleage Guy Starbuck. Another thing to add with that approach - you may have decided over time that you want to refactor the way your application is organized (folders etc) and this will give you an oppurtunity to do so.
I've been in situations where we organized a solution haphazardly without thought (let alone major changes in the application) which led to a desire to organize things differently - and the move from VSS to TFS is a great oppurtunity to do so.
As far as the original question:
I would say - yes your working habits will change but much more for the better.
As far as details on how your experience will change, another former colleague of mine (and Team System MVP) Steve St. Jean wrote a detailed article on the differences: From VSS to TFS
TFS转换工具 <-- 使用这个
我用过的这个工具已经使用了一段时间了，结果非常令人满意，因为如果您也愿意的话，它带有来自 SourceSafe 的变更集历史记录。
无论如何，使用这个工具时，您应该始终注意日志中的错误和警告，并检查一切是否构建正常/通过正常。
建议在运行此命令之前对 SS 运行分析。
希望能帮助到你
TFS conversion tool <-- Use this
I've used this tool for some times already, the results are pretty satisfatory as it comes with the history of changesets from SourceSafe if you desire too.
Anyway, using this tool you should always pay attention to errors and warnings in the log, and check if everything built okay / passed okay.
It's recomended to also run an Analysis on SS before running this.
Hope it helps
我们目前正在我的日常工作中这样做。 实际上，我们将在大约一个月内进行转换。 我是迁移的主要部分，也是我们摆脱 SourceSafe 的重要原因。 为了帮助迁移，我使用了 Visual Studio® Team System 2008 Team Foundation Server 和 Team Suite VPC 映像。 这非常有用。 立即，该映像包含完整的工作 TFS 安装供您播放和演示。 它还包括动手实验室，其中一个实验室正在运行 VSS -> TFS迁移工具。 如果您有 MSDN 订阅，一旦您使用了该图像，下一步就是安装您的订阅附带的 TFS Small Team 版本。
需要注意的一件事是确保您获得了 Visual Studio 2008 的最新 Service Pack 以及映像上安装的 .NET Framework。 该服务包修复了一些恼人的错误，这无疑提高了系统的可用性。 我们有一个非常大的 SourceSafe 数据库，包含大约 90 多个项目，迁移工具大约需要 32 小时才能完成。 首先，我对我们的源安全数据库进行了备份以进行测试。 然后我在测试源安全数据库上进行了迁移。 之后，我检查了 TFS 中的源代码树，一切都传输正常。 我们保留了 VSS 源文件的所有历史记录，这很棒。 在我们上线后，无需保留那个令人讨厌的 VSS 数据库。
我们正在逐步进行迁移。 首先是源代码控制，让我们的开发人员习惯使用它。 之后，我们将迁移 QA 和业务分析师以使用工作项跟踪功能。
我的建议是分步进行迁移。 一次不要做太多。 为将要使用该系统的人员提供培训时间。
We are currently in the process of doing this at my day job. We are actually making the switch over in about a month. I am a main part of the migration and a big part of why we are getting off of SourceSafe. To help in the migration, I used the Visual Studio® Team System 2008 Team Foundation Server and Team Suite VPC Image. It was very useful. Right off the bat, the image contains a full working TFS installation for you to play and demo with. It also includes Hands on Labs and one of the labs is running the VSS -> TFS migration tool. If you have an MSDN subscription, once you have played with the image, the next step would be to install the TFS Small Team edition that comes with your subscription.
One thing to note is to make sure you get the latest Service Packs for Visual Studio 2008 and the .NET Framework installed on the image. The service packs fixed some annoying bugs and it definately increased the usability of the system. We have a farely large SourceSafe database with about 90+ projects and the migration tool took about 32 hours to complete. First I made a backup of our sourcesafe database for testing. Then I made the migration on the test sourcesafe database. Afterwards, I checked the source tree in TFS and everything transferred fine. We kept all the history for our source files from VSS which was great. No need to keep that stinking VSS database around after we go live.
We are taking the migration in steps. First the source control and letting our developers get use to using it. Then after that we will be migrating the QA and Business Analysts over to use the Work Item tracking features.
My advice is to take the migration in steps. Don't do too much at one time. Give time for people who will be using the system to train up.
VSS Converter 是一个远非完美的解决方案。 并且2005和2008SP1版本的转换器之间存在显着差异。
例如，在一个使用了很长时间的VSS DB中，会有大量的用户为VSS做出贡献。 其中许多用户很久以前就离开了组织，因此将不再拥有域帐户。 TFS 需要将 VSS 用户映射到域帐户，因此您必须决定是将旧用户映射到单个“虚拟”域帐户还是当前团队成员。
此外，VSS Converter 2008 要求这些域帐户是有效的 TFS 帐户。 而 2005 转换器不强制执行此操作。
如果您的 VSS 历史记录包含重要的文件夹 Move，那么您可能会丢失此 Move 之前的所有历史记录。 例如，如果您将文件夹移动到新位置，然后删除以前的父文件夹，您将丢失所有历史记录。 请参阅这篇文章以获取更多解释：
http://msdn.microsoft.com/en-us/library/ms253166。 。
在我参与的一次迁移中，我们有一个已有 10 年历史的 VSS 数据库，该数据库丢失了 6 个月前的所有历史记录 这是由于 6 个月前进行的一次重大清理工作。
VSS Converter is a far from perfect solution. And there are significant differences between the 2005 and the 2008SP1 version of the converter.
For example, in a VSS DB that's been in use for a long time, there will have been a large number of users contributing to VSS. Many of these users will have left the organisation a long time ago and therefore will no longer have domain accounts. TFS requires mapping VSS users to domain accounts, so you will have to decide whether you map old users to a single 'dummy' domain account or to a current team member.
In addition, VSS Converter 2008 requires these domain accounts to be valid TFS accounts. Whereas the 2005 converter does not enforce this.
If your VSS history contains significant folder Moves, then it's likely you will loose all history before this Move. For example, if you Move a folder to a new location, then Delete the previous parent, you will loose all history. See this article for more explanation:
http://msdn.microsoft.com/en-us/library/ms253166.aspx
In one migration I was involved with, we had a 10 year old VSS database that lost all history prior to 6 months ago. This was due to a significant tidy up that took place 6 months ago.
我刚刚用谷歌搜索，但是这个演练看起来像一个很好的参考，它提到了 VSSConverter 工具，它应该可以帮助您尽可能轻松地进行迁移。
不过我想推荐一件事：备份。 在执行此操作之前备份所有内容。 如果出现任何问题，安全总比后悔好。
我的链接没有显示。 这是地址：http://msdn.microsoft。 com/en-us/library/ms181247(VS.80).aspx
I just googled, but this walkthrough seems like a good reference, and it mentions the tool VSSConverter which should help you make the migration as painless as possible.
I would like to recommend one thing though: Backup. Backup everything before you do this. Should anything go wrong it's better to be safe than sorry.
My links aren't showing up. This is the address: http://msdn.microsoft.com/en-us/library/ms181247(VS.80).aspx
您可以通过几种不同的方式进行迁移。 该工具将拉取您的历史记录等，但更实用和简单的方法是将 VSS 锁定为历史存档并重新开始：
对于转换之前的任何历史记录，请注意需要去 VSS，但一两周后，实际上不太可能经常发生。 而且您知道 VSS 中的历史记录是准确的，并且不会因转换过程而损坏。
There are a few different ways you can migrate. The tool will pull your history, etc. over, but the more pragmatic and simple way is to lock VSS as a history archive and start fresh:
For any history prior to the conversion, folks need to go to VSS, but after a week or two it's realistically unlikely to happen all that often. And you know that the history in VSS is accurate and not corrupted by the conversion process.
请注意，TFS 不支持在不同项目之间共享文件，而 VSS 则支持。 如果您有任何此类共享文件，它们之间的链接将在迁移过程中被破坏，从而导致每个项目中的文件最初相同，但现在不同。 TFS 中这些文件之一的更新将不再传播到其他项目中的副本。
Be aware that TFS does not support sharing files between different projects, as VSS does. If you have any such shared files the link between them will be broken during the migration, resulting in initially identical, but now distinct files in each project. Updates to one of these files in TFS will no longer propagate to the copies in the other projects.
如果您选择使用 Visual Studio Team Foundation Server 附带的 VSSConverter.exe 工具，则应安装 TFS 2008 SP1 首先，因为它包含许多详细的改进 迁移工具团队在此博客上。
If you do choose to use the VSSConverter.exe tool that ships with Visual Studio Team Foundation Server, then you should install TFS 2008 SP1 first as it includes a number of improvements as detailed on this blog by the migration tools team.