Subversion - откуда взяться svn: externals?

Question

Я собираюсь установить на работе правило, что все ссылки svn: externals должны поступать из одного тега другого проекта, а не из его ствола или из каких-либо его ветвей. Это разумное правило или вы видите проблемы / проблемы с этим подходом? Я пытаюсь создать стабильную среду разработки и задаюсь вопросом, не сделает ли это правило процесс разработки более медленным или более сложным.

Answer 1

Вы обеспокоены тем, что проект с svn: externals может измениться без каких-либо изменений в этом проекте. Это проблема, потому что трудно обнаружить критические изменения или вернуться к хорошей версии.

Так что да, требование, чтобы svn: внешние ссылки были стабильными, является хорошим правилом. Только разрешение ссылки на теги является одним из способов достижения этого. Другой способ - использовать синтаксис -r, чтобы прикрепить внешнюю версию к фиксированной ревизии. Пример из книги подрывной деятельности :

сторонний / скины -r148 http://svn.example.com/skinproj

Это также защитит вас от изменений в тегах, плохая практика, которая встречается чаще, чем мне нравится.

При этом все еще существует компромисс между стабильностью и непрерывной интеграцией . Часто вам все равно нужны изменения и исправления ошибок во внешних зависимостях. В этом случае вы хотите, чтобы ваш CI-сервер как можно быстрее уведомил вас о том, что некоторые изменения в зависимостях сломали ваш проект, чтобы проблему можно было решить как можно скорее. Большинство серверов непрерывной интеграции поддерживают проверку внешних элементов.

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

Answer 2

Зависит от того, насколько стабильным вы считаете ствол.

1. Если ваш ствол всегда готов к выпуску, вам не нужно, чтобы ваши внешние линии указывали на ствол.
2. Если у вас есть ветки релиза, которые изменяются только путем слияния ревизий из ствола, то вы действительно не хотите, чтобы ваши внешние элементы указывали на ствол.
3. Если по какой-либо причине вы хотите ревизию в транке, которая говорит: «Я сейчас использую эту версию этого внешнего», таким образом, принимая на себя все изменения в коде вашего проекта, то вы не хотите, чтобы ваши внешние ссылки указывали на транк .

Тем не менее, разработчик может переключить рабочие копии своих внешних компонентов на транк. Также хорошо указывать на транк внутри ветки разработки. Вполне возможно указывать на trunk перед первым стабильным выпуском проекта.

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

Запоминание изменить все ваши ссылки на конкретные ревизии, когда вы переходите из транка, может быть пробным. Благодаря поддержке тегов Hudson может сделать вещи более заметными, но мало что помогает.

Указание на ствол также может привести к проблеме « неприкасаемая библиотека ».

Когда дело доходит до CI, нет никаких причин, почему вы не можете выполнять CI для всех компонентов, а также для окончательных интегрированных проектов. Выбирая, когда объединить последнюю библиотеку, вы выбираете, когда хотите выполнить интеграцию.

Однако было бы неплохо иметь какой-то механизм, который говорит: «Ваш проект использует устаревшую библиотеку, последняя версия - X». В настоящее время это невозможно.

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

Answer 3

А решение реально разрешить внешнее? Уверен, что вы делаете это по правильным причинам. Часто лучше просто извлекать из исходного места и или, проверять зависимости в нескольких местах. Я был сожжен внешними ссылками в прошлом. Если вы собираетесь разветвляться, они станут настоящей проблемой, если вы не «заморозите» внешнее, когда вы это сделаете.

Но чтобы ответить на ваш вопрос, имеет смысл иметь конкретное место, где все внешние элементы размещены и на них есть ссылки. Это означает, что вы можете контролировать содержимое этого местоположения, и люди знают, что когда они помещают что-то туда, оно будет использоваться как внешнее и, следовательно, зависит от многих проектов.

Answer 4

Я думаю, все зависит от того, насколько зрелы ваши методы разработки программного обеспечения. У вас есть процессы управления изменениями? Автоматизированные сборки и отчетность? И т.д. Самое безопасное, что нужно сделать - это создать ссылку на тег-сборку проекта (т. Е. Lib, dll, jar и т. Д.).

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

На относительно стабильных проектах это хорошая идея. Единственная проблема заключается в том, что не все IDE дают понять, что исходный каталог является внешней ссылкой. В этом случае разработчикам становится очень легко регистрировать изменения в этом теге. Насколько я помню, Subversion еще не реализовал «только чтение», хотя я использовал более старую версию.