Хорошо, результаты есть - я нашел обходной путь.
Из-за наших устаревших процессов сборки (сборка, копирование, обфускация, сборка пользовательских установщиков, копирование в папку для перетаскивания) я не могу легко разместить ветку рядом с основной ветвью. Его необходимо заменить.
Итак, если у меня есть Main и NewFeature, я хочу отменить отображение Main и сопоставить NewFeature на его месте (т.е. использовать «c: \ Main» на сервере сборки и просто изменить исходный код, который там появляется)
Решение №1 (наиболее простое, очевидное и логичное) - использовать следующие сопоставления:
- $ / NewFeature -> c: \ Main
Ожидаемый результат: структура кода NewFeature просто заменяет Main, а сервер сборки не знает, что она находится в другой ветке.
Фактический результат: сбой с ошибкой «вы не сопоставили $ / Main, хотя и не используете его».
Решение №2 заключается в следующем:
- $ / Main -> c: \ IgnoreThisFolder
- $ / NewFeature -> c: \ Main
Это работает (оно подавляет предупреждение и, таким образом, позволяет продолжить сборку с MSBuild, не подозревая, что она строится в ветке). Однако это некрасиво, и сборка без надобности получает весь исходный код основной ветки.
Решение №3 (непроверенное, слишком дорогое, чтобы пробовать, если я не знаю, что оно будет работать намного лучше, чем №2):
- Переместите весь исходный код (из $ / Main, $ / Branches / Feature) в $ / Branches / Main и $ / Branches / Feature, чтобы получить согласованную глубину иерархии, и перепишите сценарий MSBuild для работы с этими новыми путями.
Надеюсь, что тогда я смогу отобразить только нужную мне ветку и отредактировать TFSBuild.proj, чтобы перенаправить его для сборки в этой ветке.
(Edit: Да, это работает хорошо. Теперь мы реорганизовали всю структуру нашего кода, так что все (все ветки) находятся под общим корнем в одном командном проекте, и создание ветвлений / построение больше не проблема - это просто делать все, что нам нужно сейчас. Хитрость заключается в том, чтобы вставить корневую папку в иерархию, чтобы вы могли ветвиться на любом уровне, который вам нравится. Я добавил небольшую настройку в сценарий сборки, чтобы мы могли передать ветку для сборки как параметр MSBuild, так что теперь легко создать любой вариант. Любые ветки, над которыми мы не хотим работать, можно просто замаскировать, а сервер сборки останется довольным.)
Резюме Все эти решения (если использовать технический термин) - отстой. Вам необходимо переназначить рабочую область (в данном случае это непросто: требуется 9 записей сопоставления, поэтому это может быть утомительно и чревато ошибками), отредактировать TFSBuild.proj, удалить весь исходный код и запустить сборку с / p: ForceGet = true для переключения сборки между ветвями. Таким образом, переключение веток занимает около часа. Невероятно - это займет самое большее несколько минут!
Я понимаю, что наш проект далек от идеальной настройки, но не могу поверить, что в TFS должно быть такое сложное ветвление (это было несложно в SourceSafe, Accurev и Perforce, так почему же так мучительно в TFS?).
Как все остальные организуют свои ветки TFS? Как вы переключаете разработчиков между ветвями? Как вы переключаете сборки серверов между ветвями? Неужели это должно быть так больно?
person
Jason Williams
schedule
03.12.2009
