Пометка оформления SVN с помощью внешних элементов в ветках разработки

Question

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

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

Answer 1

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

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

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

Answer 2

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

Благодарю danielsh (Даниэль Шахаф) на IRC-канале freenode #svn за этот ответ.

Answer 3

Я согласен с Martin v. Löwis, но подумал, что хотел бы указать, что если вы жестко закодируете номер ревизии в вашем svn: externals, вы напрашиваетесь на неприятности, если ваши внешние также определяют свои собственные svn: externals!

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

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

Answer 4

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

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

Answer 5

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

Идея заключается в том, чтобы ловушка перед фиксацией использовала команду svnlook с номером транзакции для проверки наличия любого «тега /» назначения в копии. В случае попадания, свойства должны быть проверены и найдены любые svn:externals. Возможно, другие свойства позволят переопределить политику.

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

Answer 6

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

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

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