我已经将Microsoft.TeamFoundation.VersionControl.Client.dll从版本14(.98.25331.0(升级到版本16(.149.28804.2(，并注意到一个奇怪的行为。我不确定这是预期的还是错误。
请考虑以下情况：
用户具有映射到本地路径的服务器工作区。
用户对文件执行签出，意识到它不是故意的，并执行撤消。然后，他将该文件与另一个文件进行比较(这是通过在appdata 上创建一个新的工作文件夹、映射它并将文件获取到该位置来实现的(。这以前工作正常，本地路径上的初始文件没有被触及并保留在那里。
升级到版本 16 (.149.28804.2( 后，将本地文件夹中的"旧"文件在将文件获取到新的临时路径后立即删除。
这是有意的还是错误？
我不确定代码在这种情况下是否有帮助，无论如何我都会提供它
workSpace.Undo(undoFiles, RecursionType.OneLevel, false);
用于撤消的相关 MSDN 文档。
workSpace.Get(getFiles, VersionSpec.Latest, RecursionType.OneLevel, GetOptions.None);
获取的相关 MSDN 文档。
有什么想法吗？
<小时 />编辑：
经过一番调查，它似乎是有意为之的。使用 2017 VS 的tf.exe，将显示行replacing ... (moved from xx)。好像是这样。不过，这并没有真正帮助我。
我已经找到了问题的原因(或者更确切地说是预期的行为(。 在Microsoft.TeamFoundation.VersionControl.Client中.dll有这段代码。
if (asyncGetFileState.m_existingLocalExists && asyncGetFileState.m_action.CurrentLocalItem != null && !FileSpec.Equals(asyncGetFileState.m_action.CurrentLocalItem, asyncGetFileState.m_action.TargetLocalItem))
{
asyncGetFileState.m_client.DeleteSource(asyncGetFileState.m_action, asyncGetFileState.m_existingLocalAttrs);
}
请注意属性CurrentLocalItem和TargetLocalItem。 由于CurrentLocalItem仍引用原始位置，而TargetLocalItem引用临时文件夹，因此将删除原始位置中的文件。这两个版本都会发生这种情况，似乎我们从未在以前的版本中注意到它。
但是，可能有一种方法可以更新缓存，以便CurrentLocalItem也引用TargetLocalItem引用的同一位置，以便我的原始文件不会被删除。我很快就会调查一下。
按照建议，我将把我的最终编辑作为答案。
我已经找到了问题的原因(或者更确切地说是预期的行为(。 在Microsoft.TeamFoundation.VersionControl.Client中.dll有这段代码。
if (asyncGetFileState.m_existingLocalExists && asyncGetFileState.m_action.CurrentLocalItem != null && !FileSpec.Equals(asyncGetFileState.m_action.CurrentLocalItem, asyncGetFileState.m_action.TargetLocalItem))
{
asyncGetFileState.m_client.DeleteSource(asyncGetFileState.m_action, asyncGetFileState.m_existingLocalAttrs);
}
请注意属性CurrentLocalItem和TargetLocalItem。 由于CurrentLocalItem仍引用原始位置，而TargetLocalItem引用临时文件夹，因此将删除原始位置中的文件。这两个版本都会发生这种情况，似乎我们从未在以前的版本中注意到它。
一个有效的解决方案是重命名原始文件并在将其发送到临时文件夹后恢复名称。
但是，可能有一种方法可以更新缓存，以便CurrentLocalItem也引用TargetLocalItem引用的同一位置，以便我的原始文件不会被删除。我会研究一下，如果我能找到更好的解决方案，我会更新我的答案。