我正在使用 VS2013 Update 4 和 TFS 2013 Update 4。在源代码管理资源管理器中，每当我将文件从一个文件夹移动到另一个文件夹时，我都可以看到文件的历史记录保存在新位置。但是，当我签入待处理的更改时，该历史记录就消失了。当我尝试运行“tf move”命令时也会发生同样的事情。那么，如何在 TFS 中移动文件并仍然保留文件的历史记录？
【问题讨论】：
标签： visual-studio-2013 move history tfvc
正确重命名文件后，历史记录不会“消失”，而是与“旧名称”相关联。以正确方式完成的重命名（作为重命名而不是作为删除+添加进行跟踪）具有查看“较旧”历史记录的向下钻取选项：
当在源代码管理资源管理器之外（或从非常旧版本的源代码管理资源管理器（例如 VS 2008））或在解决方案资源管理器之外完成重命名时，更改将被检测为两个单独的操作，一个删除和一个添加。您可以使用“Pending Changes”窗口将这些升级为重命名，以便保留历史记录：
在命令行上，这只能使用“tf rename”和“tf move”来完成。使用标准的“mv”和“ren”命令将无法保存历史记录。
以下是使用所有不同方法的进一步示例，并通过查看当前文件名的历史记录清楚地显示历史记录：
如 cmets 中所述，历史存储在包含项目修订的团队项目中。当跨项目分支/移动时，您的历史将分布在这些项目中。如果您删除团队项目，那么该项目中累积的所有历史记录都将丢失。
【讨论】：
我是从这个question 来到这个问题的。
该问题自 TFS2010 以来就存在，不仅是重命名或移动文件的问题，重命名或移动文件夹也是如此。 最糟糕的是，如果您重命名了分支，然后查看文件夹历史记录。然后你只会找到你的重命名变更集。
Here你可以看到MS对这个任务的反应。基本上他们说他们没有这样做，因为它需要大量工作并且会使历史变慢。
我无法忍受这个事实，并为此编写了一个修复程序。递归历史选择发生在 SP dbo.prc_QueryHistory 中。我更改了 SP 并添加了以下功能：
效果是较慢的历史记录（特别是如果您在深层文件夹树的根目录上执行此操作），但问题已修复。我宁愿生活在缓慢的历史中，也不愿生活在不完整的历史中。
我可以向您提供我编写的 SP，但我不确定是否可以在此处发布它，因为它包含受 MS 保护的代码。 （当然我不能保证更新系统时修复会持续存在。-我在 TFS 2013 SP3 上编写了我的 SP。）
更新：我请求 MS 允许发布我的修复（我的帖子中的第二个链接）
【讨论】：
我认为 jessehouwing 修复不适用于文件夹。事实上，如果您使用 VS 2012+ 的源代码管理资源管理器，文件夹的移动会保留文件历史记录（在 VS 中显示递归），但不会保留文件夹。文件夹历史是平的。
这个问题的解决办法：
【讨论】：
请找到我的tf move 体验
TFS 中有 main 分支。我在与 main 相同的层次结构级别上创建了 main-rest。然后我尝试将main-rest 移动到另一个子文件夹（将实验分支从 $ 根目录移动到子文件夹。
我已删除本地文件夹映射并执行
tf move $/projectName/main-rest $/projectName/experimental/main-rest
该命令在输出中列出了分支中的所有文件。然后我提交了我的更改。
看起来不错，但是 * 不再有分支文件夹历史 * merge 看不到要合并的变更集
有可能在移动之前从main-rest 合并到main 分支。它仍然可用，但在合并时没有可供选择的变更集。
“仅合并选定的变更集”选项中只有一个“已移动”的变更集。在将main-rest 移动到experimental 子文件夹之后发生这种情况。
我希望可以合并整个master-rest分支（但现在还不是测试的时候）
我使用了 VS2017 附带的 tf.exe 命令行实用程序（已修补今天可用的最新更新）。源码托管在云端tfs(https://dev.azure.com)
问候
【讨论】：