Subversion: как создать тег с папками в нескольких ревизиях

Question

У нас есть большой проект, который состоит из одного задания сборки (Maven, через pom.xml, с несколькими дочерними папками и т. Д.).Разработчики дали нам три разных номера ревизии и хотели бы, чтобы мы создали один тег, который мы могли бы использовать для задания сборки (Hudson).

Пример:
/ - на оборот X
/project1 - в версии Y
/ project2 - в версии Z

Мне удалось создать этот тег, синхронизировав всю ветку с rev X, затем «cd project1» и синхронизировав с rev Y, затем"cd .. \ project2" и синхронизируйте с rev Z, затем "cd .." и создайте тег из текущего каталога.

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

Спасибо,
Кен

Answer 1

Я вижу два подхода для удовлетворения вашего требования

Я буду трактовать ваш "/" как "ствол", кстати.иначе было бы бессмысленно создавать теги;)

копия из подхода к пересмотру

• svn copy http://myrepos/trunk/@x http://myrepos/tags/1.0/
• svn copy http://myrepos/project1/@y http://myrepos/tags/1.0/project1/
• svn copy http://myrepos/project2/@z http://myrepos/tags/1.0/project2/

преимущества

• легко понять

недостаток

• накладные расходы на документацию (что находится в этом теге?)
• выбор редакций, возможных источников ошибок
• потолочные линейные шкалы линейные с количеством проектов

пометить как стабильный подход

сделать этот шаг один раз в вашей магистрали:

• создайте файл в редакторе и назовите его «externals»

• добавьте эти две строки:

  project1 http://myrepos/1.0/project1/tags/to-be-released

  project2 http://myrepos/1.0/project2/tags/to-be-released

• svn propset svn: externals -F externals.

Кто бы ни проверял ваше главное приложение, теперь он получит последние версии ваших проектов , когда они былиготов к гelease.

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

• svn delete http://myrepos/1.0/project1/tags/to-be-released

• svn copy http://myrepos/project1/@y http://myrepos/1.0/project1/tags/to-be-released

• svn delete http://myrepos/1.0/project2/tags/to-be-released

• svn copy http://myrepos/project2/@z http://myrepos/project2/tags/to-be-released

в день выпуска / тега:

• svn copy http://myrepos/trunk http://myrepos/tags/1.0

Вы также можете использовать номер ревизии.Проблема здесь в том, что макет вашего приложения указывает, что project1 и 2 находятся внутри вашего основного приложения "/".Если это не так, тегирование и использование фиксированных тегов для релиз-интеграции могут быть очень гладкими.(«/» тоже будет иметь под-теги)

пример из реального мира:

svn propget svn: externals http://svn.silverstripe.com/open/phpinstaller/tags/2.4.2/

преимущества

• документирование немного проще с помощью истории SVN и графика ревизий
• пометка масштабирования накладных расходов и остается неизменным в основной день тегов

недостатки

• сложнее в настройке и понимании (вся команда должна)

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

Answer 2

svnmerge может помочь вам в этом случае.

svnmerge.py wiki говорит: «Специальная поддержка веток релиза с помощью cherry-picking: имя и объединение отдельных ревизийили диапазоны ревизий. "

Я сам не проверял, попробуйте.

Answer 3

Вы всегда можете сделать svn copy вручную, чтобы скопировать материал во вновь созданную папку в tags.Если вы хотите, вы также можете составить простой скрипт, выполняющий эти три номера ревизии.

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