视觉源安全 --> TFS 迁移

StackOverflow https://stackoverflow.com/questions/29838

题

在这里，我们已经与许多 Visual Source Safe 存储库合作了大约 10 年左右。

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

在我开始迁移之前，您有什么提示或技巧可以给我吗？我需要注意哪些事项？

我确信这种迁移将意味着我们的工作习惯必须以某种方式改变。您认为这些变化会给组织带来问题吗？想象一下在一个站点中大约有 20 名 .NET 开发人员的团队。

有帮助吗？

解决方案

我刚刚用谷歌搜索过，但是 本演练 似乎是一个很好的参考，它提到了 VSSConverter 工具，它应该可以帮助您尽可能轻松地进行迁移。

不过我想推荐一件事：备份。在执行此操作之前备份所有内容。如果出现任何问题，安全总比后悔好。

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

其他提示

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

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

对于转换之前的任何历史记录，人们都需要访问 VSS，但在一两周后，这种情况实际上不太可能经常发生。而且您知道 VSS 中的历史记录是准确的，并且不会因转换过程而损坏。

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

如果您选择使用 Visual Studio Team Foundation Server 附带的 VSSConverter.exe 工具，那么您应该安装 TFS 2008 SP1 首先，因为它包含了许多详细的改进 迁移工具团队在这个博客上.

发行版的一些关键功能包括：

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

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

纠正时间戳不一致之处. 。VSS使用客户端时间戳可能会导致修订以与实际发生的相反顺序记录。该工具现在识别此问题，并继续迁移更改以前失败。

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

我们目前正在我的日常工作中这样做。实际上，我们将在大约一个月内进行转换。我是迁移的主要部分，也是我们摆脱 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 和业务分析师以使用工作项跟踪功能。

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

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 个月前进行的一次重大清理工作。

TFS转换工具 <-- 使用这个

我已经使用这个工具一段时间了，结果非常令人满意，因为如果您也愿意的话，它还附带来自 SourceSafe 的变更集历史记录。

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

建议在运行此命令之前对 SS 运行分析。

希望能帮助到你

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

我曾经遇到过这样的情况：我们不经思考就随意组织了一个解决方案（更不用说对应用程序进行重大更改），这导致我们希望以不同的方式组织事物 - 从 VSS 迁移到 TFS 是这样做的一个很好的机会。

至于原来的问题：

和：这种迁移肯定意味着我们的工作习惯必须以某种方式改变。您认为这种变化会给组织带来问题吗？考虑在一个站点中由大约 20 名 .net 开发人员组成的团队

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

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

至于您的体验将如何改变的详细信息，我的另一位前同事（团队系统 MVP）Steve St.Jean 写了一篇关于差异的详细文章： 从VSS到TFS

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top