在这里，我们一直在使用大量Visual Source Safe存储库，大约有10年左右的时间。

现在，我要摆脱Sourcesafe并转到Team Foundation Server。

在我开始迁移之前，我们对我有什么提示或者技巧吗？我要注意些什么？

我确信这种迁移将意味着我们的工作习惯必须以某种方式进行修改。我们是否认为这些更改对组织可能是个问题？考虑在一个站点中由大约20个.NET开发人员组成的小组。

解决方案

回答

我只是在Google上搜索，但是本演练似乎是一个很好的参考，它提到了VSSConverter工具，该工具应该可以使迁移尽可能轻松。

我想推荐一件事：备份。备份所有内容，然后再执行此操作。万一出了什么问题，安全要比后悔更好。

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

回答

我们可以通过几种不同的方式进行迁移。该工具将拉开历史记录等，但是更实用和更简单的方法是将VSS锁定为历史记录存档并重新开始：

• 让每个人都检查对VSS的所有更改，确保一切都构建好，等等。
• 将所有VSS数据库设置为"锁定"(所有用户的只读权限)
• 将整个VSS数据库上的"最新"存储到工作站上的一组"干净"文件夹中
• 从工作站将所有文件检入TFS

对于转换之前的任何历史，人们都需要使用VSS，但是一两周之后，实际上不可能经常发生这种情况。而且我们知道VSS中的历史记录是准确的，并且没有被转换过程破坏。

回答

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

回答

目前，我们正在日常工作中进行此操作。实际上，我们将在大约一个月内完成转换。我是迁移的主要部分，也是我们为什么要脱离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。该Service Pack修复了一些令人讨厌的错误，并确定地增加了系统的可用性。我们拥有庞大的SourceSafe数据库，其中包含约90多个项目，并且迁移工具花费了大约32个小时来完成。首先，我备份了源安全数据库以进行测试。然后，我在测试源安全数据库上进行了迁移。之后，我检查了TFS中的源树，一切都正常了。我们保留了来自VSS的源文件的所有历史记录，这很棒。上线后，无需保留发臭的VSS数据库。

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

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

回答

我的前同事盖伊·星巴克(Guy Starbuck)在那里提供了很好的指导。通过这种方法可以添加的另一件事是，随着时间的推移，我们可能已经决定要重构应用程序的组织方式(文件夹等)，这将使我们有机会这样做。

我遇到过这样的情况，我们无意间随意地组织了一个解决方案(更不用说应用程序中的重大更改)了，这导致了人们希望以不同的方式组织事物，而从VSS到TFS的转变是一个很大的机会。

至于原始问题：

And: this migration will for sure mean that our working habits have to be modified in some way. Do you think that this changes could be a problem for the organization? Think to a group of about 20 .net developers, in a single site

我会说是的，工作习惯将会改变，但情况会变得更好。

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

关于体验将如何变化的详细信息，我的另一位前同事(和Team System MVP)Steve St. Jean撰写了一篇详细的文章，介绍了它们之间的区别：从VSS到TFS

回答

如果确实选择使用Visual Studio Team Foundation Server附带的VSSConverter.exe工具，则应首先安​​装TFS 2008 SP1，因为它包含迁移工具团队在此博客上详细介绍的许多改进。

Some of the key features of the
  release include:
  
  Elimination of namespace conflicts.  I
  previously blogged about this as "the
  rename problem" and we have fixed the
  converter to correctly migrate files
  with overlapping namespaces.  This was
  the biggest pain point for most users
  trying to use previous versions of the
  tool.
  
  Automatic solution rebinding. 
  In this latest version, VS solution
  files will be automatically upgraded
  to the 9.0 version and checked back in
  to version control.  Previously users
  were required to do this manually. 
  
  Correcting of timestamp
  inconsistencies.  The use of client
  timestamps by VSS can lead to
  revisions being recorded in the
  opposite order that they actually
  occurred in.  The tool now recognizes
  this issue and continues migrating
  changes where it would previously
  fail.
  
  Improved logging.  Although
  we've fixed a lot of issues, providing
  better, more detailed logging will
  help users that do run into issues
  diagnose the problems.

回答

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个月前的所有历史记录。这是由于六个月前进行的大量整理。