TFS API Get Deletes file - различное поведение после обновления до новой версии (с 14xx до 16xx) - PullRequest
Новая
       64

TFS API Get Deletes file - различное поведение после обновления до новой версии (с 14xx до 16xx)

3 голосов
/ 15 октября 2019

Я обновил 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 для получения.

Есть идеи?

edit:

После некоторого исследования кажется, что оно предназначено. Используя tf.exe VS 2017, появляется строка replacing ... (moved from xx). Похоже, так и должно быть. Однако мне это не очень помогает.

Edit 2:

Я нашел причину проблемы (или, скорее, ожидаемое поведение). В 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, чтобы мой исходный файл не удалялся. Я скоро посмотрю на это.

1 Ответ

0 голосов
/ 18 октября 2019

Как и предполагалось, я поставлю свое окончательное редактирование в качестве ответа.

Я нашел причину проблемы (или, скорее, ожидаемое поведение). В 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, так что мой оригинальный файл не удаляется. Я посмотрю на это и обновлю свой ответ, если смогу найти лучшее решение.

...