Очень простой обходной путь (если это разрешено в вашем случае) для устранения этой ошибки: (особенно, когда все стоят за вами, чтобы решить эту проблему в срочном порядке):
- Просто изменитефайл buildnumber.txt (файл, в котором содержится последний успешный номер «buildnumber» в нем) и увеличьте число до нового значения, т. е. если вы получаете сообщение об ошибке TFS>.... не может пометить ... файл, и в течение этого времени сборки метка сборки, которую TFS пытался применить (скажем, так): TFS_RELEASE_BUILD_5, затем просто увеличьте номер сборки до 10, 20 или 50, т.е.номер сборки, который будет автоматически сгенерирован вашим сценарием сборки, будет 11, 21 или 51.
Проблема решена.
Мой случай:
Я создал ветку "11.0" где-то 2 недели назад.В этой ветке мы создали сборки от 1 до 10. Метка сборки была в формате: TUD_COR_11.0.0.1 ..to 10.
Вчера я удалила ветку 11.0.
Вчера нам пришлось заново воссоздать эту ветку из новой ветки с исходным кодом, поэтому мы сделали:
a.удалена 11.0 ветка.отметили изменения, чтобы ветка исчезла.
b.Удалил все сборки, которые были созданы по определению сборки, и, наконец, удалил определение сборки (так как другие члены команды хотели, чтобы я снова создал новое определение сборки для новой ветви 11.0 (которая будет создана из новой исходной ветви) с нуля.Создавая определения сборки, я успешно видел метки «галочки» на ярлыках / etc / что-либо связанное с существующими определениями сборки, которые собирались удалить согласно операции удаления.
Теперь я создал новый11.0 снова ветвится из последних данных из исходной ветки на сегодняшний день.
Снова создал определения сборки.
Снова создал сборку COR со сборкойметка TUD_COR_11.0.0.1. Теперь TFS выдала мне сообщение об ошибке, описанное в приведенной выше теме.
Возможное разрешение:
A. Удалите файл"согласно журналу сборки", где операция метки TFS не выполняется. Вы можете использовать команду sidekick -OR TF label. Примечание: Это может занять много времени, что иесли вы удалите метку из файла (ИЛИ удалите этот файл под этой меткой, т.е. эта метка больше не применяется к этой метке).
* ПРИМЕЧАНИЕ. Здесь мы НЕ удаляем файл из системы контроля версий. просто удалив файл из концепции метки
B.ИЛИ просто увеличьте buildnumber.txt .., который использует скрипт сборки для генерации метки сборки, т.е. если мой buildnumber.txt (который находится где-то в дереве ветви управления исходным кодом), он содержал значение «0» и создавал сборку«1» с меткой: TUD_COR_11.0.0.1 (где ветвь - 11.0, а серия сборки - 11.0.0.1), т.е. ... формат.Теперь, если я просто изменю значение этого buildnumber.txt на «10» (почему, так как это был последний номер сборки, который мы успешно создали, когда у нас был HAD 11.0 ветвь ранее (до того, как мы его удалили) .. поэтому я увеличил значение buildnumber до 10т. е. теперь, если я снова запускаю определение сборки (т. е. ставлю очередь на сборку), сценарий сборки сгенерирует новую сборку с номером: 11, то есть с меткой сборки "TUD_COR_11.0.0.11". Проблема решена несколькими секундами.Я не сомневался в этом, поскольку это была ветка разработки, поэтому им было все равно, какой номер сборки мы (команда SCM) им предоставляем. Они просто хотели успешной сборки.