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