Отметка проверки SVN с внешними компонентами в ветвях разработки

В большинстве наших проектов используется много общего кода. Мы (наконец) движемся к системе, в которой мы единым образом управляем общим кодом. Мы рассматриваем общий код как отдельный проект в SVN, а затем ссылаемся на него как на внешний. Тем не менее, мы склонны указывать внешние библиотеки на ветвях развития или даже на туловище во время разработки проекта из-за неизбежных сбоев в переносе библиотек из одного использования в другое.

В результате мы делали ошибки при пометке файлов для выпуска или внутренних этапов. Время от времени мы будем отмечать проект без обеспечения того, чтобы все внешние элементы были отмечены первыми. Как мы можем решить эту проблему? Я ищу способы уменьшить вероятность ошибки или восстановить/восстановить после создания неаккуратного тега, подобного этому. В идеале решение было бы способом заставить SVN применять текущую политику, но меня интересует любой опыт, связанный с такими проблемами.

Ответ 1

Я бы использовал две стратегии для решения этой проблемы

автоматизировать тегирование. Создайте оболочку script, которая изменит все svn: externals на фиксированный тег версии/выпуска перед созданием тега в проекте.
имеет script, который проверяет существующие теги на согласованность. Фактически возможно восстановить состояние при времени тегирования, даже когда вы подключаете внешнее соединение к соединительной линии: поскольку вы знаете дату и время создания тега, вы также можете узнать, какая версия сундука была активной в этой точке, и либо изменить внешний для указания на конкретную ревизию магистрали или на выпуск, который был текущим в момент создания тега.

Кроме того, вы также можете найти крюк pre-commit, который проверяет, создается ли тэг, и указывают ли все внешние ссылки на исправленные исправления, отклоняя фиксацию, если это не так.

Ответ 2

Клиент Subversion версии 1.9 имеет параметр --pin-externals для svn copy, который выглядит так, как будто он будет делать именно то, что здесь требуется.

Благодаря danielsh (Daniel Shahaf) на канале IRC freenode #svn для этого ответа.

Ответ 3

Это звучит банально, но, безусловно, лучшее, что нужно сделать, это не ссылки на ветки библиотек. Вы бы этого не сделали, если это была сторонняя библиотека, и это тоже не рекомендуется делать с вашими собственными библиотеками.

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

Если вы действительно должны ссылаться на ветки библиотек разработки, вы можете использовать привязку pre-commit script, которая определяет, когда вы делаете тег, и гарантирует, что все ссылки, на которые ссылаются внешние, также помечены версиями: затем script может заблокировать фиксацию, если это не так. Это довольно удачный случай, когда вы делаете фиксацию, хотя.

Ответ 4

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

Идея заключается в том, что крюк pre-commit использует команду svnlook с номером транзакции для проверки любого места назначения "теги/" в копии. В случае хита свойства должны быть проверены и найдены для любого svn:externals. Возможно, другие свойства позволят переопределить политику.

Очевидным вопросом является загрузка на сервере и какой язык для этого хоста. Обычно SVN поставляется с лучшими связями Python Ctypes, к сожалению, в прошлый раз, когда я проверил, он недоступен для Windows (ни для компиляции, как для этой цели). Но для модуля pysvn может быть достаточно, чтобы это сделать. Помимо этого языка скрипты bash могли бы работать, но были бы грязными и не столь переносимыми. Или чистый C...

Ответ 5

не обрабатывая ваши внутренние библиотеки так же, как ваши внешние? Если вы Apache Ivy (соответственно Maven), было бы довольно легко публиковать ваши библиотеки в центральном репозитории (с номером версии 1.0 или SNAPSHOT_20091005) и просто импортировать их с помощью стандартного механизма Ivy (соответственно Maven).

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

Ответ 6

Я согласен с Мартином против Лёвиса, но думал, что хочу указать, что если вы только указали номер версии в своих svn: externals, вы просите о проблемах, если ваши внешние пользователи также определяют свои собственные svn: externals!

В вашем случае вы не захотите пойти и установить внешние соединительные линии разработки для указанной ревизии, так как это будет блокировать ваши репозитории разработки. Вы также не можете игнорировать рекурсивные внешние. Лучший вариант - рекурсивно пометить все внешние элементы, это позволяет продолжить разработку, но вы создаете свой собственный тег/ветвь для ВСЕГО.

У меня есть script, который делает это, но немного очистит его, прежде чем опубликовать его:)