tfs2012 - 我在TFS的主要分支刚刚消失 - 为什么？

可能发生的事情

我可以想到一些事情，在这种情况下最合乎逻辑的是有人发出tf destroy $/project/Branch/* /recursive，这会产生观察到的影响。

除非你打开＆＃34;显示已删除的项目＆＃34;否则可能有人重命名了分支，这在历史记录本身中是不可见的。 Team Foundation Source控件选项选项中的选项。

您的应用程序层的版本控制缓存可能已损坏，发生这种情况的可能性非常小，但可能导致此问题。确保您拥有良好的数据库备份，即使可能出现这种情况，如果您不需要数据库备份并且数据库备份越旧，则标记为删除数据的可能性就越小仍然会在那里。

检查项目集合数据库中的tbl_command或access the hidden _oi activity log page on the web access server。您可能能够找到导致删除的命令。

如果没有告诉您，请分析SQL Server的事务日志（如果您的服务器配置为保留这些日志）。

备份您的TFS服务器或保护您拥有的TFS服务器

如果版本控制缓存是清除它的罪魁祸首（在应用程序层机器上）可以解决您的问题，缓存位置显示在TFS管理控制面板上：

解决此问题的最佳方法是暂时停止TFS服务器，然后删除此文件夹的内容。

似乎有几种出路：

忘记它，获取最新分支的内容并使用它来重新填充缺失的数据。只需将它们添加到空文件夹，检入它们然后重新合并所有其他分支并解决所有冲突。
- Pro：快速
- 骗局：你失去了历史，解决冲突将是一项艰巨的任务。
将项目集合数据库恢复到之前的某个时间点（警告！可能需要将所有项目集合还原到以前的某个时间点）
- 亲：你得到了所有历史记录
- Con：您自上次已知的良好备份以来所做的更改很少，需要大量工作，会影响同一集合中的所有项目，可能还会影响同一服务器上的所有项目。
将整个服务器还原到临时服务器，并将包含缺失数据的集合还原到上次已知的正确配置。使用OpsHub或Team Foundation Migration Toolkit等工具重播自灾难以来的更改。
- Pro：您回到最新的时间点
- Con：在TFS迁移中花费了大量时间和专业知识
恢复收集数据库并使用事务日志重播对集合的更改，然后跳过执行销毁的事务。但要小心，通常destroy操作会将文件标记为已删除，但作业会在后台执行实际删除。
- Pro：您回到最新的时间点
- Con：在SQL中花费了大量时间和专业知识
与Microsoft支持部门联系，并获得一名现场专家。如果没有立即触发清理作业，它们可能能够恢复删除。
- 亲：你会回到最好的状态
- Con：费用很高

无论您做什么，请确保备份当前情况，这样您就可以尝试不同的策略，如果您的第一次尝试失败。

考虑拆分项目集合以允许其他项目继续工作。如果这个项目最终在一个独立的项目集合中结束，你将最终处于这种情况，但它将允许你快速前进。

好的 - 这是一本记录簿，因为莫名其妙的项目在当天晚些时候再次出现。所有这些历史都回来了。我本以为这里的DBA可能会进行数据库恢复，但这是不可能的，因为所有已经发生的全天候签到的仍然存在。

所以，如果将来发生这种情况，只需交叉手指等几个小时！

P.S。我确实查看了SQL日志但找不到任何东西。奇异！