Сборка сервера сборки TFS ответвления?

Хорошо, результаты есть - я нашел обходной путь.

Из-за наших устаревших процессов сборки (сборка, копирование, обфускация, сборка пользовательских установщиков, копирование в папку для перетаскивания) я не могу легко разместить ветка рядом с основной ветвью. Ему необходимо заменить его .

Итак, если у меня есть Main и NewFeature, я хочу отключить отображение Main и сопоставить NewFeature вместо него (т.е. использовать "c: \ Main" на сервере сборки и просто измените исходный код, который там появляется)

Решение №1 (наиболее простое, очевидное и логичное решение) - использовать следующие сопоставления:

• $ / NewFeature -> c: \ Main

Ожидается результат: структура кода NewFeature просто заменяет Main, и сервер сборки не знает, что он находится в другой ветке.

Фактический результат: Ошибка с сообщением «вы не сопоставили $ / Main, хотя вы» Теперь мы реорганизовали всю структуру нашего кода, так что все (все ветви) находятся под общим корнем в одном командном проекте, и создание ветвлений / построение больше не является проблемой - теперь легко делать все, что нам нужно. Хитрость заключается в том, чтобы вставить корневую папку в иерархию, чтобы вы могли ветвиться на любом уровне, который вам нравится. Я добавил небольшую настройку в сценарий сборки, чтобы мы могли передать ветку для сборки в качестве параметра в MSBuild, так что теперь легко создать любой вариант. Любые ветки, над которыми мы не хотим работать, можно просто замаскировать, и сервер сборки останется довольным.)

Резюме Хитрость заключается в том, чтобы вставить корневую папку в иерархию, чтобы вы могли ветвиться на любом уровне, который вам нравится. Я добавил небольшую настройку в сценарий сборки, чтобы мы могли передать ветку для сборки в качестве параметра в MSBuild, так что теперь легко создать любой вариант. Любые ветки, над которыми мы не хотим работать, можно просто замаскировать, и сервер сборки останется довольным.)

Резюме Хитрость заключается в том, чтобы вставить корневую папку в иерархию, чтобы вы могли ветвиться на любом уровне, который вам нравится. Я добавил небольшую настройку в сценарий сборки, чтобы мы могли передать ветку для сборки в качестве параметра в MSBuild, так что теперь легко создать любой вариант. Любые ветки, над которыми мы не хотим работать, можно просто замаскировать, и сервер сборки останется довольным.)

Резюме Все эти решения (если использовать технический термин) - отстой. Вам необходимо переназначить рабочую область (в данном случае это непросто: требуется 9 записей сопоставления, поэтому это может быть утомительно и чревато ошибками), отредактировать TFSBuild.proj, удалить весь исходный код и запустить сборку с / p: ForceGet = true, чтобы переключать сборку между ветвями. Таким образом, переключение веток занимает около часа. Невероятно - это займет самое большее несколько минут!

Я понимаю, что наш проект далек от идеальной настройки, но не могу поверить, что в TFS должно быть так сложно разветвляться (это было несложно в SourceSafe, Accurev и Perforce, так почему же так мучительно в TFS?).

Как все остальные организуют свои ветки TFS? Как вы переключаете разработчиков между ветвями? Как вы переключаете сборки серверов между ветвями? Неужели это должно быть так больно?

Новое обновление:

Как сообщается в другом ответе, я нашел обходной лад, который был бы в порядке для недолговечной ветви функций, но он действительно не очень хорошо работал. С тех пор я вернулся к проблеме, и полное решение до смешного простое:

В TFSBuild.proj путь был основан на $(BuildProjectFolderPath). Этот путь разрешается в серверную (путь к управлению версиями), например $/Main, а не в локальный путь (D:\ServerBuildFolder\Main).

К сожалению, по историческим причинам наш исходный код разделен на несколько командных проектов, что означает, что одна «ветвь» фрагментирована на несколько разветвленные папки в source Control (т.е. $/Main/Code и $/Libraries/Code). Нельзя создать ветвь, содержащую $/Main и $/Libraries). Таким образом, мы должны повторно собрать эти разрозненные фрагменты из системы управления версиями обратно в согласованную иерархию с помощью сопоставлений рабочих областей.

Это означает, что Ричард был на месте - относительный путь от файла TFSBuild.proj к файлу .sln был неправильным,поскольку MSBuild/TFS предполагает, что .sln находится в пределах одной иерархии командного проекта и системы управления версиями (поэтому искал $/Main/Libraries.sln вместо $/Libraries/Libraries.sln).

Решение простое: я заменил $(BuildProjectFolderPath) локальным путем (например, D:\ServerBuildFolder\Main) для файлов, так что относительная ссылка была разрешена в «локальном пространстве» (после применения сопоставлений), и MSBuild теперь работает сладко.

Мораль рассказа: 1) НИКОГДА не используйте более одного командного проекта, если есть вероятность, что вы когда-либо захотите иметь какую-либо ссылку между этими кодовыми базами. Не обманывайте себя, думая, что новый командный проект предложит какое-то безболезненное логическое различие между приложениями и библиотеками. Дополнительные проекты оказались просто кошмаром администрации - множество дополнительных проблем для абсолютно нулевой выгоды. (Это все одна большая общая куча под капотом,таким образом, все рабочие элементы и папки системы управления версиями по-прежнему видны во всех проектах (!), но это добавляет несколько кирпичных стен, которые делают межпроектные ссылки очень проблематичными)

2) Всегда создавайте одну папку корневого уровня в своей системы управления версиями team Project, а затем поместите все остальное под эту папку. Например, для проекта "$/Main" создайте "$/Main/Root", а затем поместите все из исходной иерархии в Root.

Следуя этим правилам, вы сможете в будущем разветвлять одну папку «Root», и тогда потребуется только одна ветвь и одно дополнительное сопоставление рабочей области. Это поможет вам избежать преждевременного облысения.

(В свою защиту, я бы сделал это таким образом для начала - я работаю с устаревшей установкой. В защиту устаревшей установки это звучит хорошо на бумаге, но просто не является подходом, поддерживаемым Microsoft!)