我想从 2005 年的明星团队迁移到具有 HISTORY 的 TFS 2010。有什么工具或任何方法可以让我经济高效地做到这一点。我知道及时迁移工具，但它太贵了。
问问题
419 次
1 回答
2
没有工具可以做到这一点。您只能为 Timely Migration 付费或自己编写。从 StarTeam 获取历史记录非常复杂。其原因是因为该视图在历史上的样子。您可以将视图回滚到某个时间点，仅此一项就可以很好地工作，但是使用 API 几乎不可能回滚到视图发生更改的每个时间点。这是因为 1) 并非所有内容都有审核记录，因此您不能使用审核，并且 2) 审核记录被清除，3) 有一个特殊功能可以“回放”视图的历史以生成侦听器事件（需要 MPX），但这会错过许多事件，4）当项目被共享、配置、分支等时，这些不会在项目中生成任何审计，5）即使它们生成了，获取每一个更改都需要遍历视图历史记录到第二个，以通过分析差异来获取所有更改。这意味着如果您的项目已经活动了一个月，并且每次您分析两个视图配置以区分它们需要 5 秒，那么实际迁移您的项目将需要 5 个月，同时它会被锁定。
因此，下一个方法是建立“基线”进行比较。如果您的项目中有夜间或连续构建，甚至只是某些经过 QA 认证的构建，则使用构建标签是一个很好的起点。这样，您可以将这些基线用作差异/比较点，然后以这种方式引入历史记录。虽然这不像完整的历史记录那样细化，但根据定义，它可以迁移最重要的差异。
但是，请记住，即使这样做也不会维护跨不同分支/视图的分支/合并点之间的链接。这样做的唯一方法是直接进入 StarTeam 数据库以获取此信息。
我经历了所有这些步骤来尝试编写自己的工具套件，以从 StarTeam 迁移到 Subversion。它很有趣，很有趣，也很不完美，但有一些希望，但最终没有完成。部分原因是因为所涉及的时间远远超过我从中获得的价值。
这不可避免地给你带来了最重要的问题：保持完整历史的商业价值是什么？在作为 StarTeam 管理员与项目团队一起经历了很多次之后，超过 90% 的时间很明显更好的方法是切换。腾出时间，您可以开始在新系统中进行新工作，并在旧系统中冻结工作。对于项目团队来说，它通常可以在很少的停机时间内完成。您甚至可以从引入生产版本的历史开始，在新系统中创建一个粗略的时间表。使用您现有的比较工具（在 TFS 或 BeyondCompare 或其他地方）重现您的项目源代码、文档等的每个状态，并通过根据需要签入或删除文件将其与您的 TFS 项目相协调，并为您带来的每个构建标记您的 TFS 项目。排列所有 TFS 构建、工作项、用户、角色等，并确保一切准备就绪。然后在切换时，从 StarTeam 获取最新的开发快照，并对您的 TFS 项目再进行一次更新。将您的 Starteam 用户锁定在项目之外（无论如何都要签入），然后开始在 TFS 中工作。您的 TFS 项目将拥有最重要基线的粗略历史记录，并且您将能够保持您的 StarTeam 存储库对用户开放，以防需要更多历史记录。将您的 Starteam 用户锁定在项目之外（无论如何都要签入），然后开始在 TFS 中工作。您的 TFS 项目将拥有最重要基线的粗略历史记录，并且您将能够保持您的 StarTeam 存储库对用户开放，以防需要更多历史记录。将您的 Starteam 用户锁定在项目之外（无论如何都要签入），然后开始在 TFS 中工作。您的 TFS 项目将拥有最重要基线的粗略历史记录，并且您将能够保持您的 StarTeam 存储库对用户开放，以防需要更多历史记录。
要考虑的另一件事是如何创建项目的永久存档。如果您的存储库足够小，它是可行的，但您的项目越大，时间越密集。首先，将整个数据库和保管库复制到一个单独的实例，然后启动并运行该副本。然后删除所有其他项目，除了您要归档的项目。运行在线清除并确保运行完成。您可能需要重新启动服务器并清除几次。完成后，整个存储库应仅包含项目所需的文件和数据库记录。此时，您可以备份您的数据库和保管库并无限期地保留它们。这会减小现有 StarTeam 存储库的大小。
3 年多没有使用 StarTeam，但那是一次有趣的时光倒流。希望你发现它有用。
于 2015-07-11T04:33:35.023 回答