Team Foundation Server - 移动带有历史记录的源代码

回到手头的问题...这不像说tf rename $/projectA $/projectB那么简单.源代码控制树中的顶级文件夹是为团队项目创建向导保留的；你不能对它们运行标准的 tf 命令.你需要的是一个像这样的脚本:Get-TfsChildItem $/ProjectA |选择 - 跳过 1 |# 跳过根目录foreach{tf 重命名 $_.serveritem $_.serveritem.replace("$/ProjectA", "$/ProjectB")}[当然，如果$/ProjectA下的孩子不多的话，你可以自己动手]至于我提到的问题，我现在将详细说明一个问题，因为查找旧历史对您来说似乎非常重要.一旦您签入重命名，tf history $/ProjectA/somefile.cs 将不起作用.默认情况下，tf 命令假定 version = "latest".这些替代方案中的任何一个都将获得您想要的完整历史记录:tf history $/ProjectA/somefile.cs;1234 移动前变更集 1234 所在的位置tf history $/ProjectB/somefile.cs;5678 移动后变更集 5678 所在的位置.或者您可以省略版本.完整性的最终替代方案调试目的:tf 历史记录 $/ProjectA/somefile.cs -slotmode.您只会看到移动之前发生的更改；但是，您还会看到在您移动到 ​​B 下方的项目之前或之后可能存在于 $/ProjectA/somefile.cs槽"中的任何其他项目的历史记录.(在 TFS 2010 中，slot 模式"是默认行为；有一个 -ItemMode 选项，可以请求像 2008 年那样跨历史跟踪您的查找，而不是基于路径.)编辑 - 不，分支不是一个很好的选择.虽然分支确实在系统中留下了足够的元数据以将完整历史记录到 &来自 ProjectB，它在 2008 年不是非常用户友好.计划花大量时间学习 tf merges 命令(没有等效的 UI).2010 显着提高了跨多个分支可视化更改的能力，但它仍然不是您从重命名中获得的干净统一的体验.I was wondering what the best approach might be in moving source code, with history, from one Team Project to another Team Project. I am not concerned with work items, reporting, or SharePoint sites, as the system we are going to be restoring from did not use these functionalities. The reason for wanting to move to a different Team Project also is driven by the fact that the original implementation (being restored from a backup that was maintained by a third party) were using a third-party process template that we do not wish to use going forward. We want to start utilizing work item tracking and reporting after the migration is complete.The TFS Integration Platform seems to be one likely scenario. It can be used to change the process template, according to the documentation. However, I was curious if the tf.exe move syntax might work? Something like:tf.exe move $/ProjectA $/ProjectBIt is my understanding that this command operates much like a rename operation, whereas moving with the "Move" context menu item in Source Control Explorer is more like a delete and add operation. Also, would the tf.exe move path actually associate the code under the folders with the appropriate Team Project, assuming that $/ProjectA is the root source control folder for one project and $/ProjectB is the root source control folder for the other? The key is to be able to preserve the history, if possible.Any advice or tips would be greatly appreciated!Edit - Could branching to another project handle this scenario - much like Microsoft discusses in the Branching Guidance documentation? I think that this could be the answer, since the history would likely be preserved with the branch. However, I do not have access to a Team Foundation Server 2008 instance at the moment to test it. 解决方案 Move and Rename are aliases. There is absolutely no difference, in any version of TFS, from the command line or the UI.Both of them preserve history. At least in 2005/2008, you keep the same physical item in the VersionedItem table no matter how often or how drastically the name and/or parent path changes. There is actually no way to get a "fake" rename (delete + add) without a lot of manual work on your part.However, while this versioning model is very pure in a theoretical sense, it has some practical gotchas. Because different items can occupy the same name at different points in time, TFS needs the full name + version to uniquely identify any inputs you send it. Normally you don't notice this restriction, but once have you renamed items in the system, if you say tf [doSomething] $/newname -version:oldversion then it will get confused and either throw an error or operate on an item you may not have intended. You have to be careful to pass valid combinations (newname+newversion or oldname+oldversion) to ensure commands behave the way you want.TFS 2010 changes the story somewhat: it's a branch+delete under the covers, causing the itemID to change. Even so, everyday commands like Get and History are "faked" very well; old clients are about 95% compatible. The advantage is that when you have multiple renames in the system and path-based item lookups start to become ambiguous as alluded to above, the server will simply accept the name you specify and run with it. This improves overall system performance and eliminates several traps that unfamiliar users often fell into, at the cost of not being quite as flexible and not preserving history with 100% precision (eg when there are name collisions during a Merge of two branches).Returning to the problem at hand...It's not as simple as saying tf rename $/projectA $/projectB. Top level folders in the source control tree are reserved for the Team Project Creation Wizard; you can't run standard tf commands against them. What you need is a script like:Get-TfsChildItem $/ProjectA | select -Skip 1 | # skip the root dir foreach { tf rename $_.serveritem $_.serveritem.replace("$/ProjectA", "$/ProjectB") }[of course, you can do it by hand if there aren't too many children under $/ProjectA]As far as the gotchas I mentioned, I'll elaborate on one right now since looking up old history seems very important to you. Once you checkin the rename, tf history $/ProjectA/somefile.cs will NOT work. By default, tf commands assume version = "latest." Any of these alternatives will the full history you want:tf history $/ProjectA/somefile.cs;1234 where changeset 1234 was before the movetf history $/ProjectB/somefile.cs;5678 where changeset 5678 was after the move. Or you could just omit the version.A final alternative for completeness & debugging purposes:tf history $/ProjectA/somefile.cs -slotmode. You will only see the changes that happened prior to the move; however you'll also see the history of any other items that may have lived in the $/ProjectA/somefile.cs "slot" prior to or subsequent to the item you moved underneath B.(In TFS 2010, "slot mode" is the default behavior; there's an -ItemMode option to request that your lookup be traced across history like it was 2008 rather than path-based.)EDIT - no, branching is not a great alternative. While branching does leave enough metadata in the system to trace the full history to & from ProjectB, it's not terribly user friendly in 2008. Plan to spend a lot of time learning the tf merges command (no UI equivalent). 2010 dramatically improves your ability to visualize changes across multiple branches, but it's still not the clean unified experience you'd get from a Rename. 这篇关于Team Foundation Server - 移动带有历史记录的源代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！