我们可以迁移到新的 TFS 流程模板并保留历史记录吗？
我们目前正在使用 TFS 2008 和 Conchango 的 Scrum for Team System 模板，并进行了一些细微的调整。我们正在考虑升级到 TFS 2010，并且正在考虑迁移到 MSF for Agile 模板。
迁移到新流程模板并保留历史记录的最佳方法是什么？我希望能够在 TFS 2010 服务器上创建一个新的团队项目，签入所有内容，并将我们的源代码移至新项目。如果我们能够以某种方式保留签入注释历史记录，甚至可能导航回与旧项目中的变更集关联的工作项历史记录，那就太好了。我什至愿意将旧项目按原样迁移到 2010 年，然后将源代码移动到新项目，仅在 2010 年保留旧项目和工作项。
是否有人经历过这个过程，可以提供一些建议？
We are currently using TFS 2008 with the Scrum for Team System template from Conchango, with a few minor tweaks. We are looking at upgrading to TFS 2010 and we are considering moving to the MSF for Agile template.
What is the best way to move to a new process template and keep history? I'd like to be able to create a new team project on the TFS 2010 server, get everything checked-in, and move our source to the new project. It would be nice if we could somehow keep the check-in comment history and possibly even be able to navigate back to the work item history associated with a changeset in the old project. I'd even be willing to migrate the old project as-is over to 2010 and then move the source to a new project, retaining the old project with work items only in 2010.
Has anyone gone through the process that can over some advice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们经历了这个痛苦的过程。以下是一些有用的信息：
We have been through this painful process. Here is some useful information:
以防万一其他人来到这里，我发布了一些关于如何执行此操作的分步说明（尽管针对不同的模板）此处。
Just in case anyone else comes here, I posted some step by step instructions on how to do this (for different templates though) here.
尽管我们现有的 Team Foundation Server 实例中只有源代码，但我们的情况与您类似（具体到我们使用的模板与我们想要使用的模板）。我们计划从 Team Foundation Server 2008 迁移到 Team Foundation Server 2010，而不是升级。尽管我们还没有这样做，但您确实有您概述的两种选择。
正如您提到的，您可以使用此工具将源代码和工作项跟踪迁移到新的团队项目。它将“压缩”历史日期，因为 TFS 需要添加自己的时间戳。据我了解，会有一些潜在的历史问题。具体来说，在 TFS 2010 中，您在比较预迁移源代码管理中的版本时可能会遇到问题。至少，到目前为止，我在我们的测试实验室进行了实验。我对这个问题的理解是，它与项目模式与槽模式作为两个版本之间的默认值有关。我可以查看各个版本并可以查看历史记录 - 这样就满足了我们的要求。
另一种选择是一个项目中的源代码控制和另一个项目中的工作项。我没有尝试过这一点，因为我想象变更集关系将在现有工作项目上被破坏，并且不会继续生成。这对您来说可能是大问题，也可能不是大问题。
此外，最好在 Codeplex 项目的讨论区中描述您的情况。作者来自 Microsoft 的 TFS 迁移团队，并依赖与我们志同道合的人员的反馈。到目前为止，我已经与他们交换了几封电子邮件，他们非常有帮助。
根据我们与 Microsoft 非常乐于助人的人员的讨论，我们可能会备份数据库并按照 Bryan Krieger 的博客文章（路径 2：迁移升级）。我希望最早在下周就可以使用较旧的备份进行升级测试。
祝你好运！我知道这很吓人。幸运的是，我在实验室中全新安装 TFS 2010 的安装和配置体验比我最初接触 TFS 2008 过程要顺利得多。希望您会发现同样的情况。
We are in a simalar situation that you are (right down to the templates we are on versus the one we want to be on), although we only have source code in our existing Team Foundation Server instance. We are planning to do a migration from Team Foundation Server 2008 to Team Foundation Server 2010, as opposed to an upgrade. Although we have not done so yet, you do have the have two options you have outlined.
Like you mention, you can migrate the source code and Work Item Tracking to a new Team Project using this tool. It will "compress" the history dates, as TFS will want to add its own timestamp. There will be some potential history issues, from what I understand. Specifically, in TFS 2010, you might have issues comparing versions from the pre-migrated source control. At least, so far, I have in my experiments in our test lab. My understanding of this issue is that it relates to item-mode vs. slotted-mode as the defaults between the two versions. I can look at individual versions and can see history - so that meets our requirements.
The other option is source control in one project and work items in another. I have not tried this, because I would imagine that the changeset relationships would be broken on existing work items and would not be generated going forward. This may or may not a be a big deal to you.
Also, it might be a good idea to describe your situation in the discussion area of the project on Codeplex. The authors are on the TFS Migration Team at Microsoft and depend on feedback of people in the same boat we are. I have been exchanging a couple of emails with them so far, and they have been quite helpful.
Based upon our discussions with the very helpful folks at Microsoft, we are likely going to backup the databases and follow the directions on Bryan Krieger's blog post (Path 2: Migration Upgrade). I am hoping to make a test run at the upgrade using an older backup as early as next week.
Best of luck! I know it is intimidating. Luckily, my installation and configuration experiences with a fresh TFS 2010 install in the lab have been much more smooth than my initial exposure to the TFS 2008 process. Hopefully, you find the same is true.