16

在这里，我们已经使用一堆 Visual Source Safe 存储库大约 10 年了。

现在我想摆脱 sourcesafe 并继续使用 Team Foundation Server。

在我开始迁移之前，您有什么建议或技巧吗？我需要注意哪些事项？

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

4

8 回答 8

11

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

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

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

于 2008-08-27T18:29:53.250 回答
8

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

于 2008-08-27T18:58:12.743 回答
6

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

该版本的一些主要功能包括：

消除命名空间冲突。我之前在博客中将此称为“重命名问题”，我们已修复转换器以正确迁移具有重叠命名空间的文件。对于大多数尝试使用该工具早期版本的用户来说，这是最大的痛点。

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

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

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

于 2008-09-16T07:14:00.430 回答
2

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

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

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

于 2008-08-27T10:20:38.153 回答
2

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

需要注意的一件事是确保您获得最新的 Visual Studio 2008 服务包和安装在映像上的 .NET Framework。服务包修复了一些恼人的错误，它肯定增加了系统的可用性。我们有一个相当大的 SourceSafe 数据库，其中包含大约 90 多个项目，迁移工具大约需要 32 小时才能完成。首先，我备份了我们的 sourcesafe 数据库以进行测试。然后我在测试 sourcesafe 数据库上进行了迁移。之后，我检查了 TFS 中的源代码树，一切正常。我们保留了来自 VSS 的源文件的所有历史记录，这很棒。上线后无需保留那个臭名昭著的 VSS 数据库。

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

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

于 2008-08-27T19:05:49.153 回答
2

VSS Converter 是一个远非完美的解决方案。并且2005和2008SP1版本的转换器有很大区别。

例如，在一个已经使用了很长时间的 VSS 数据库中，会有大量用户为 VSS 做出贡献。其中许多用户很久以前就离开了组织，因此将不再拥有域帐户。TFS 需要将 VSS 用户映射到域帐户，因此您必须决定是将旧用户映射到单个“虚拟”域帐户还是当前团队成员。

此外，VSS Converter 2008 要求这些域帐户是有效的 TFS 帐户。而 2005 转换器不强制执行此操作。

如果您的 VSS 历史记录包含重要的文件夹 Move，那么您可能会丢失此 Move 之前的所有历史记录。例如，如果您将文件夹移动到新位置，然后删除以前的父级，您将丢失所有历史记录。有关更多说明，请参阅本文：http: //msdn.microsoft.com/en-us/library/ms253166.aspx

在我参与的一次迁移中，我们有一个使用了 10 年的 VSS 数据库，它丢失了 6 个月前的所有历史记录。这是由于 6 个月前进行的一次重大清理。

于 2008-12-17T14:10:35.727 回答
2

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

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

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

建议在运行之前对 SS 进行分析。

希望能帮助到你

于 2015-07-29T12:11:15.013 回答
1

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

我曾经遇到过这样的情况，我们在没有考虑的情况下随意组织了一个解决方案（更不用说应用程序中的重大变化），这导致了以不同方式组织事物的愿望——从 VSS 到 TFS 的转变是一个很好的机会。

至于原来的问题：

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

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

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

至于您的体验将如何改变的细节，我的另一位前同事（也是 Team System MVP）Steve St. Jean 写了一篇关于差异的详细文章：从 VSS 到 TFS

于 2008-09-07T14:04:09.147 回答