Почему мой путь рабочей области TFS продолжает повторно отображать себя?

Я считаю, что это не может быть сделано. Поскольку основной целью tf.get_variable() является поиск переменной с тем же именем, а если она не найдена, она создает новую. Поэтому, если вы просто хотите создать новую переменную, используйте tf.Variable() вместо

6
задан SkunkSpinner 6 March 2009 в 13:44
поделиться

4 ответа

Это не нормальное поведение - кажется, что что-то идет забавное. Просто требуемый для проверки - все, что Вы делаете, является простым get's из корректного проводника Управления исходным кодом? Также - все Вы находятся на различных машинах? (Т.е. Вы не добавляете виртуальное изображение ПК или что-либо, где несколько машин имеют то же имя),

Каждый думает, что я проверил бы, должен перейти к Файлу, Управлению исходным кодом, Управлять Рабочими областями и посмотреть на Ваши рабочие отображения папки и прежде и после получения и видеть, изменяется ли что-нибудь. Это не было должно - если это делает это могло бы дать нам ключ к разгадке относительно того, что происходит.

1
ответ дан 10 December 2019 в 02:54
поделиться

Определения Рабочей области хранятся на сервере.

Если Вы перейдете к командной строке и типу "tf рабочая область", то Вы будете видеть определение своей рабочей области.

0
ответ дан 10 December 2019 в 02:54
поделиться

Вы также можете попробовать очистить кеш рабочего пространства и переназначить его:

SET AppDataTF=%USERPROFILE%\Local Settings\Application Data\Microsoft\Team Foundation
SET AppDataVS=%APPDATA%\Microsoft\VisualStudio
IF EXIST "%AppDataTF%\1.0\Cache" rd /s /q "%AppDataTF%\1.0\Cache" > NUL
IF EXIST "%AppDataTF%\2.0\Cache" rd /s /q "%AppDataTF%\2.0\Cache" > NUL
IF EXIST "%AppDataVS%\8.0\Team Explorer" rd /s /q "%AppDataVS%\8.0\Team Explorer" > NUL
IF EXIST "%AppDataVS%\9.0\Team Explorer" rd /s /q "%AppDataVS%\9.0\Team Explorer" > NUL
1
ответ дан 10 December 2019 в 02:54
поделиться

У меня такое случалось, когда я получал при открытии решения. Если решение содержит относительные пути к другим проектам, не находящимся в его папке, которые по-разному отображаются в вашей рабочей области, GET сообщит мне, что это переназначение для учета этого. Проблема в том, что решения, которые он принимает, совершенно неверны.

Единственный способ обойти это - гарантировать, что все разработчики используют ту же структуру, что и элемент управления sourcec, и havev, представленные в каждой рабочей области.

Однако получить это было сложно. . в основном каждый должен был удалить все локальные копии всех файлов, повторить рабочую область, ВЫБРАТЬ НЕТ «ПОЛУЧАТЬ» ПРИ ИЗМЕНЕНИИ РАБОЧЕГО ПРОСТРАНСТВА, закрыть VS, открыть, ПОЛУЧИТЬ ПОСЛЕДНИЕ.

Причина в том, что копии проектов существовали локально, даже если эти проекты НЕ были открыты, GET все равно будет неправильным. Это было неприятно, потому что при проверке различий в этих проектах с последними изменениями не было, но при открытии решения, содержащего этот проект, ссылки dll в этом проекте автоматически изменяются. На данный момент никаких изменений в ЛЮБОМ файле не ожидается. Но после постройки изменения сохранятся и приведут к тому, что следующее снова отключится ...

Я уверен, что все это неправильно, но именно это и произошло с нами на этой неделе.

6
ответ дан 10 December 2019 в 02:54
поделиться
Другие вопросы по тегам:

Похожие вопросы: