TF203015 Элемент $ / путь / файл содержит несовместимые ожидающие изменения. Пытаясь расстегнуть - PullRequest
47 голосов
/ 10 мая 2010

Я использую Visual Studio 2010 Pro против Team Server 2010, и мой проект был открыт (очевидно) в качестве решения из репозитория, но я должен был открыть его как «веб-сайт». Я узнал об этом во время компиляции, поэтому я пошел на полку своих новых изменений и удалил проект с локального диска, затем снова открыл проект из исходного кода (на этот раз как веб-сайт), и теперь я не могу отменить удаление своих файлов.

Есть ли способ обойти это? Я что-то взорвал? Нужно ли проводить техническое обслуживание на сервере?

Я нашел этот вопрос на SO # 2332685 , но я не знаю, о каких кеш файлах он говорит (я на XP: \) РЕДАКТИРОВАТЬ: Нашел эту ссылку после публикации вопроса, извините за задержку в исследовании, все еще не решил мою проблему

Конечно, я нигде не могу найти код ошибки для TF203015, так что никакого разрешения тоже нет (отсюда и мое включение числа в заголовок, да?)

EDIT: Я должен вероятно упомянуть, что эти файлы никогда не были проверены в первую очередь. Это имеет значение? Можете ли вы положить на полку непроверенный предмет? Это то, что я сделал не так?

EDIT: WHAP - НАЙДЕНО ЭТО !!! Используйте "Отменить" на элементах, которые не существуют, потому что они отображаются в ожидающих изменениях как проверки.

Ответы [ 8 ]

49 голосов
/ 12 мая 2010

Я удалил файлы, пытаясь перезагрузить рабочее пространство, хотя я отложил изменения. Затем VS2010 подумал, что эти файлы еще не сохранены. Мне это не было нужно, поэтому я должен был выяснить, как «отменить» изменения в «Ожидающих изменениях».

Тогда я мог бы отрешиться.

Мне показалось, что у меня одновременно работали две операции (без полки, при коммите для добавления), и я подумал, что у меня только одна операция (без полки).

43 голосов
/ 06 марта 2012

Это немного в стороне от вопроса ОП

Вы можете получить TF203015 при попытке пакетного объединения нескольких наборов изменений из одной ветви в другую без должной заботы.

Рассмотрим ситуацию, когда у вас есть магистральная магистраль и ветка DEV. Вы разветвляли DEV из MAIN и усердно работали над функцией в DEV; проверяя работу обратно в DEV, как вы прогрессировали. Теперь перенесемся на неделю или две. Теперь вы готовы к завершению и хотите вернуться в MAIN.

Здесь один из наших разработчиков нажал эту ошибку.

Он работал над одним решением в течение нескольких недель и периодически проверял наборы изменений в DEV, поэтому хотел объединить несмежную серию наборов изменений в MAIN. Таким образом, он выбирает вариант слияния, выбирает первый набор изменений; сливается без проблем, затем сразу же идет слияние следующей ревизии; и взрыв TF203015, и его очень бесполезный тест в окне вывода; несовместимые ожидающие изменения.

После небольшой суеты мы теперь понимаем, что здесь происходит; первое слияние создало ожидающее изменение в MAIN для решения для разработчиков. Следующей попыткой слияния были также изменения в том же решении, что потребовало бы от TFS «поставить в очередь» второй набор ожидающих изменений в тех же файлах. Это не может сделать это.

Таким образом, в этом сценарии TF203015 означает; «В целевой ветви уже есть ожидающие изменения некоторых файлов, которые были изменены в этом наборе изменений. Пожалуйста, разрешите и передайте изменения целевой ветви перед выполнением этой операции слияния»

Решение; после каждой операции слияния наш разработчик проверяет рабочее пространство на MAIN и фиксирует ожидающее изменение, вызванное слиянием, затем возвращается к DEV и повторяет.

На самом деле разумный и простой, но замаскированный очень тупым сообщением об ошибке.

5 голосов
/ 30 июня 2011

Вы можете использовать Team Foundation Server Power Tools, март 2011 г. (http://msdn.microsoft.com/en-us/vstudio/bb980963.aspx), который включает команду tfpt unshelve.

После установки Power Tools откройте командную строку Visual Studio, перейдите в каталог, в котором находится интересующий вас проект, и выполните команду tfpt unshelve. Он откроет и отобразит диалоговое окно слияния, чтобы вы могли разрешить конфликты.

Я благодарю этот пост за помощь в поиске решения: http://fluentbytes.com/the-how-and-why-behind-tf203015-file-has-an-incompatible-change-while-unshelving-a-shelve-set

2 голосов
/ 25 июня 2015

Может также случиться так, что после того, как вы создадите папку, скажем, «Test» и захотите объединиться с dev в test, у вас не будет этой вновь созданной структуры папок, зарегистрированной в TFS, - вы также можете получить сообщение об ошибке.

Таким образом, это сообщение об ошибке МОЖЕТ произойти, не имея ничего общего с SHELVESETS, а также с другими, приходящими из Google и находящими эту страницу.

2 голосов
/ 28 января 2011

У меня возникла та же проблема, но я создал ветвь после хранения своих изменений, и я хотел отменить эти изменения в новой ветке.

TFS не может отсоединиться от пути, отличного от путина котором была создана полка.

Решение: я вернул обратно в исходную ветвь, а затем использовал вне всякого сравнения для объединения изменений из моей первоначальной ветки в новую ветвь и зарегистрировался.

1 голос
/ 09 марта 2018

Возможно, это то же самое, что и ответ Джколебранда, но, боюсь, я нашел фразу там немного заумной. Приношу искренние извинения, если я просто повторяю.

В моем сценарии было представлено сообщение incompatible pending change, потому что я пытался откатить несколько наборов изменений, и на один и тот же файл повлияло более одного из этих наборов изменений.

В моем случае я не хотел фиксировать, пока все изменения не будут отменены. Я полагаю, что если бы я смог выполнить коммит после отката каждого набора изменений, ошибка бы не произошла.

Метод, который работал для меня, был следующим:

  • Я решил откатывать по одной ревизии за раз. Я обнаружил, что использование командной строки было на самом деле более информативным способом сделать это, потому что он перечисляет все конфликты, тогда как я думаю, что откат VS UI просто перечисляет первый.
  • При откате набора изменений, если был incompatible pending change, мне пришлось отменить ожидающие изменения в моей рабочей области для затронутых файлов.
  • Когда все наборы изменений были откатаны, мне пришлось вручную возвращать файлы, которые имели incompatible pending change. В основном это может быть достигнуто просто путем получения определенной версии файла («последняя известная-хорошая» версия перед началом всех неудачных проверок). Но для некоторых файлов, в которых произошли как желаемые, так и нежелательные изменения, я получил «последний известный-хороший» и вручную применил к нему хорошие изменения.
0 голосов
/ 16 марта 2016

Если у вас есть две ветви: MAIN (цель) и DEV (источник), теперь вы хотите объединить DEV с MAIN, тогда все файлы, которые вы хотите объединить из вашего источника, не должны быть старше, чем аналогичные файлы в целевой ветви. 1001 *

Например: у вас есть измененный файл test.cs в вашей ветке DEV, измененный 14.03.2016. В вашей ГЛАВНОЙ ветке у вас test.cs изменился на 15.03.2016. Таким образом, цель новее исходного файла и у вас есть TF203015.

Решение: перейдите в TFS Explorer к файлу конфликта и явным образом объедините его. TFS откроет менеджер конфликтов, и вы можете объединить конфликты вручную. После вы можете объединить выбранный набор изменений.

Замечания: Если у вас больше конфликтов, вы должны перейти к каждому файлу конфликта и слить его явно, чтобы TFS открыла Менеджер конфликтов, и вы можете объединить его вручную.

0 голосов
/ 29 октября 2015

Эта ссылка решила мою проблему:

https://blogs.infosupport.com/the-how-and-why-behind-tf203015-lt-file-gt-has-an-incompatible-change-while-unshelving-a-shelve-set/

Причина, по которой ожидающие изменения в той же рабочей области создают несовместимые изменения. Так что отмените ожидающие изменения и попробуйте отменить. Это должно решить проблему.

...