TFS 2012未检测到挂起更改中的已删除文件

Question

我们团队中有多名开发人员。除了一个开发人员之外，这适用于所有人，但我们似乎无法找到它对这个人不起作用的原因。我们都安装了VS premium +，TFS 2012电动工具。

我们有一个分支。我们从分公司获得最新版本。转到Windows资源管理器并删除文件夹“sdk”中的所有文件（sdk /中没有子目录）。然后我们将一堆文件复制到其中。 （与删除的文件相比，这有效地将一些文件保留为新文件，更新文件，相同文件或删除文件。）

当我们进行挂起更改时，这些更改会显示在“排除的更改 - 添加51，删除（3）”下。

除一位开发人员外。他的系统无法识别这些变化。什么可能导致这对他不起作用？

如果它有助于排除故障，他也是唯一的开发人员，如果他通过Windows资源管理器中的电子工具删除选项删除这些文件，他的.dll文件将被锁定。其他任何人都不会这样做。

这是我们到目前为止所检查的内容：

编辑：找到解决方案 - 谢谢大家的回复！它确实是本地vs服务器工作区选项。将他的工作空间设置为本地解决了这些以及他显然遇到的其他一些问题。

Answer 1

确保开发人员使用“本地工作区”而不是“服务器工作区”。

这是TFS 2012中引入的一个概念，它可以帮助开发人员脱机工作，而不是早期版本中不允许这样做的服务器工作区。 TFS 2012更改了工作区选项。服务器工作区仍然可用，并且在以前的版本中具有完全相同的功能。但是，TFS 2012现在包含一种新类型的工作空间，称为“本地”工作空间。同样，这是过于简单化，但在本地工作空间中，所有文件都是读/写，而不是只读。有关文件的元数据存储在工作区根目录中的隐藏文件夹中，允许在本地完成编辑，重命名和删除操作，而无需与服务器进行任何通信。

这显着改善了TFS的离线故事，因为您不再遇到编辑只读文件的问题。它还可以更轻松地使用其他工具（如记事本）来编辑代码文件。使用记事本更改代码文件仍会将该文件标记为已编辑，下次连接时将由TFS选取。

LINK

Answer 2

只有当用户篡改源控件的本地视图（无论是否是本地工作空间）时，才会发生这种情况。如果您所做的一切都是从TFS获得最新信息，那么这将永远不会发生，相反，TFS中的内容的本地视图将始终得到妥善管理。

听起来也像是糟糕的合并，例如获取最新版本（文件不再存在）然后复制旧内容（引入未跟踪的文件。）您可能尝试做的一件事就是在尝试合并之前删除本地工作区内容后，尝试从TFS强制获取。这将确保本地工作空间是最新的准确与TFS服务器认为是真实的，如果它仍然发生在内容合并之后，那么问题几乎肯定在用户正在经历的合并过程中（即PEBKAC，或关于他们正在做什么的知识差距。）

如果您将旧内容（预删除）取消保存到本地工作区（已经执行了删除，根据SCC，因此在本地由于同步/获取最新），那么未被保留的文件将有效地变为未跟踪，由用户清理混乱。这与将松散文件复制到TFS从未了解过的工作空间的用户完全相同。 TFS不会为你修剪未跟踪的文件，我相信其他一些源代码控制工具可能会将其作为可配置的默认值，而TFS则没有。

这只发生在团队中的一位开发人员身上，这表明其他开发人员一次只能与这位开发人员坐在一起，并使用“他们的流程”来查看是否仍然会出现这些问题。通常情况下，这归结为用户采用的糟糕过程，并且让不同的人坐在椅子上可以帮助突出其发生的原因并帮助结束它。纪律严明的构建/源代码管理器和/或开发人员不应该遇到这个问题。

非常有兴趣知道问题的结果。