Subversion - откуда взяться svn:externals?
Здесь я собираюсь установить правило, согласно которому все ссылки на svn: externals должны исходить из тега другого проекта, а не из его ствола или из каких-либо его ветвей. Это разумное правило или вы видите проблемы / проблемы с этим подходом? Я пытаюсь создать стабильную среду разработки, и мне интересно, будет ли это правило замедлять или усложнять разработку.
4 ответа
Вы обеспокоены тем, что проект с svn:externals может измениться без каких-либо изменений в этом проекте. Это проблема, потому что трудно обнаружить критические изменения или вернуться к хорошей версии.
Так что да, требование, чтобы svn: внешние ссылки были стабильными, является хорошим правилом. Только разрешение ссылки на теги является одним из способов достижения этого. Другой способ - использовать синтаксис -r, чтобы прикрепить внешнюю версию к фиксированной ревизии. Пример из книги подрывной деятельности:
сторонний / скины -r148 http://svn.example.com/skinproj
Это также защитит вас от изменений в тегах, плохая практика, которая встречается чаще, чем мне нравится.
При этом все еще существует компромисс между стабильностью и непрерывной интеграцией. Часто вам все равно нужны изменения и исправления ошибок во внешних зависимостях. В этом случае вы хотите, чтобы ваш CI-сервер как можно быстрее уведомил вас о том, что некоторые изменения в зависимостях сломали ваш проект, так что проблема может быть решена как можно скорее. Большинство серверов непрерывной интеграции имеют поддержку для проверки внешних устройств.
По этой причине я думаю, что все в порядке, чтобы внешние компоненты в магистрали отслеживали заголовок магистрали ваших зависимостей (если у вас есть CI-сервер). Просто прикрепите свои внешние элементы к фиксированным ревизиям при пометке и при создании стабильных веток обслуживания
А решение реально разрешить внешнее? Уверен, что вы делаете это по правильным причинам. Часто лучше просто извлекать из исходного места и или, проверять зависимости в нескольких местах. Я был сожжен внешними ссылками в прошлом. Если вы собираетесь разветвляться, они становятся настоящей проблемой, если только вы не "заморозите" внешнее.
Но чтобы ответить на ваш вопрос, имеет смысл иметь конкретное место, где все внешние элементы размещены и на них есть ссылки. Это означает, что вы можете контролировать содержимое этого местоположения, и люди знают, что когда они что-то кладут туда, оно будет использоваться как внешнее и, таким образом, зависит от многих проектов.
Я думаю, что все зависит от того, насколько зрелы ваши методы разработки программного обеспечения. У вас есть процессы управления изменениями? Автоматизированные сборки и отчетность? И т.д. Самое безопасное, что нужно сделать - это создать ссылку на тег-сборку проекта (т.е. библиотеки lib, dll, jar и т. Д.).
Если внешний проект имеет еженедельные выпуски с частыми исправлениями ошибок, это может быть как полезным, так и помехой. Я обнаружил, что без хорошей политики управления конфигурацией ссылки на теги упрощают пропуск критических обновлений. И к тому времени, когда вы приступите к "обновлению" этой зависимости, может появиться множество небольших изменений, которые в совокупности приведут к большой работе.
На относительно стабильных проектах это хорошая идея. Единственная проблема заключается в том, что не все IDE дают понять, что исходный каталог является внешней ссылкой. В этом случае разработчикам становится очень легко регистрировать изменения в этом теге. Из того, что я помню, Subversion еще не реализовал "только чтение", хотя я использовал более старую версию.
Это зависит от того, насколько стабильным вы считаете ствол.
- Если ваш ствол всегда готов к выпуску, вам не нужно, чтобы ваши внешние стороны указывали на ствол.
- Если у вас есть ветки релизов, которые изменяются только путем слияния ревизий из ствола, то вы действительно не хотите, чтобы ваши внешние компоненты указывали на ствол.
- Если по какой-либо причине вам нужна ревизия в стволе, которая говорит: "Я сейчас использую эту версию этого внешнего", таким образом, принимая на себя все изменения в коде вашего проекта, то вам не нужно, чтобы ваши внешние компоненты указывали на ствол.
Тем не менее, разработчик может переключить рабочие копии своих внешних компонентов на транк. Также хорошо указывать на транк внутри ветки разработки. Это может быть нормально указывать на транк до первой стабильной версии проекта.
Моя личная задача - очень бережно относиться к багажнику, поскольку он имеет для меня особое значение - это полная история проекта. Все, что освобождается, должно пройти через ствол по определению. Если вы можете изменить ствол, не записав ревизию с изменением (что фактически происходит, если вы указываете на внешнюю по отношению к стволу), вы потеряете контроль над выпуском этой ревизии и включением этой ревизии в свой проект.,
Запоминание изменить все ваши ссылки на конкретные ревизии, когда вы переходите из транка, может быть пробным. Хадсон может сделать вещи более заметными благодаря поддержке тегов, но мало что помогает.
Указание на ствол также может привести к проблеме " неприкасаемой библиотеки".
Когда дело доходит до CI, нет никаких причин, почему вы не можете выполнять CI для всех компонентов, а также для окончательных интегрированных проектов. Выбирая, когда слить в последнюю библиотеку, вы выбираете, когда вы хотите выполнить интеграционную работу.
Тем не менее, было бы неплохо иметь какой-то механизм, который говорит: "Ваш проект использует устаревшую библиотеку, последняя версия - X". Это невозможно в данный момент.
Кроме того, если у вас есть вложенные внешние элементы, перенос изменений из базовой библиотеки через 5 слоев ссылок до достижения основного проекта является проблемой.