Search code examples
c#.netazure-devopstfs

TFS API Get Deletes file - Different behavior after update to new version (from 14xx to 16xx)

I've upgraded the Microsoft.TeamFoundation.VersionControl.Client.dll from version 14 (.98.25331.0) to 16 (.149.28804.2) and noticed a strange behavior. I'm not sure if it's expected or a bug.

Consider this situation:

The user has a server-workspace which is mapped to a local path.

The user does a check-out on a file, realizes that it wasn't intentional and performs an undo. He then compares the file to another file (this happens by creating a new workfolder on appdata, mapping it and getting the file to that location). This previously worked fine, the initial file on the local path didn't get touched and remained there.

After upgrading to version 16(.149.28804.2), the 'old' file on the local folder will be deleted right after getting the file to the new, temporary path.

Is that intended or is that a bug?

I'm not sure if code helps in this case, I'll provide it anyway

workSpace.Undo(undoFiles, RecursionType.OneLevel, false);

Related MSDN documentation for undo.

workSpace.Get(getFiles, VersionSpec.Latest, RecursionType.OneLevel, GetOptions.None);

Related MSDN documentation for get.

Any ideas?

edit:

After some investigation it seems like it's intended. Using the tf.exe of the 2017 VS, the line replacing ... (moved from xx) appears. Seems like it's meant to be like that. Doesn't really help me, though.

Edit 2:

I've found the cause of the problem (or rather expected behavior). In the Microsoft.TeamFoundation.VersionControl.Client.dll there's this piece of code

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);
}

Note the properties CurrentLocalItem and TargetLocalItem. Because of the fact that CurrentLocalItem still refers to the original location and TargetLocalItem refers to the temp-folder, the file in the original Location is being deleted. That happens with both versions, it just seems like we've never noticed it with the previous version.

However, there might be a way to update the cache so that CurrentLocalItem also refers to the same location TargetLocalItem is referring to, so that my original file doesn't deleted. I'll look into that soon.

Solution

  • As suggested, I'll put my final edit as an answer.

    I've found the cause of the problem (or rather expected behavior). In the Microsoft.TeamFoundation.VersionControl.Client.dll there's this piece of code

    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);
}

    Note the properties CurrentLocalItem and TargetLocalItem. Because of the fact that CurrentLocalItem still refers to the original location and TargetLocalItem refers to the temp-folder, the file in the original Location is being deleted. That happens with both versions, it just seems like we've never noticed it with the previous version.

    A working solution is to rename the original file and restore the name after getting it to the temp folder.

    However, there might be a way to update the cache so that CurrentLocalItem also refers to the same location TargetLocalItem is referring to, so that my original file doesn't deleted. I'll look into that and update my answer if I can find a better solution.