Subversion и зависимости

Question

Я пытаюсь найти жизнеспособную стратегию для решения следующей проблемы.

У нас есть несколько веб-проектов, которые зависят от нашей структуры.Все хранится в нашем SVN и имеет собственный проект со всей необходимой структурой каталогов (ствол, теги, ветки).В примере - у нас есть проекты webprj01 и webprj02 и у нас есть фреймворк frm01.Все они имеют обычную структуру проекта SVN - транк, теги, ветви.

webprj01 и webprj01 зависят от frm01 и в реальной жизни frm01 присутствует как подкаталог webprj01 и webprj02.Чтобы добиться этого в SVN, можно установить свойство svn: external, и мы можем установить frm01 для указания на / frm01 / trunk внутри транка webprj01 и webprj02.

Чтобы выполнить реальное кодирование, нам нужно иметь всетри проекта извлечены как рабочая копия и внесены изменения в конкретную кодовую базу в своей рабочей копии.Невозможно опубликовать изменения из webprj01 / frm01 в SVN.Изменение должно быть выполнено в рабочей копии frm01 и передано через SVN в рабочие копии webprj01 / frm01 и webprj02 / frm01.

Это решение имеет проблему с зависимостями при ветвлении.Я делаю производственную ветку от SVN / webprj01 / trunk до /webprj01/branches/release-1.0.0.Через два дня, работая над вторым проектом webprj02 и frm01, я больше не могу получать стабильную проверку, как через svn: externals в выпуске ветки 1.0.0.директория frm01 уже указывает на новые изменения в frm01 / trunk.

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

Очевидно, что описанная стратегия с использованием svn: externals не работает.Каков будет ваш опыт в этой ситуации?Нет необходимости использовать одну кассу.Здесь может помочь даже использование сценариев сборки или другого решения.Я ищу решение проблемы на долгое время, которое не будет сильно зависеть от действий человека, поскольку мы подвержены ошибкам.

Answer 1

В мире Java я бы не пытался решить эту проблему, используя только систему контроля версий - вместо этого я бы использовал инструмент управления зависимостями, такой как Maven + система контроля версий.

В месте, где я работаю, у нас есть настройка, которая кажется довольно распространенной:

Любой "каркасный" проект живет в своей собственной структуре каталогов (ствол, теги, ветви), как вы, похоже, уже это сделали. Они также управляются с помощью Maven, и всякий раз, когда что-то регистрируется, новая версия компонента (в большинстве случаев JAR-файл) публикуется в нашем локальном репозитории Maven (который находится на сервере Nexus).

Любой проект, которому необходимо использовать «каркасный» проект, будет зависеть от конкретной версии каркасного проекта - Maven затем автоматически извлекает эту версию с сервера Nexus всякий раз, когда проект собирается.

Это позволяет нам выпускать каждый проект и компонент фреймворка отдельно, но при этом отслеживать зависимости между ними. Мы даже можем иметь несколько версий компонентов инфраструктуры, используемых в разных проектах, не теряя при этом всех зависимостей.

Пока что это хорошо сработало для нас - я вижу только два недостатка:

Настройка требует времени, особенно если вы раньше не использовали Maven.

Существуют некоторые издержки при выпуске каждого проекта, так как вы также хотите освободить каждый зависимый компонент, чтобы избежать зависимости от "магистральной" версии других компонентов (то есть версии "SNAPSHOT" в терминологии Maven).

Answer 2

Эрик прав, менеджер зависимостей поможет вам - возможно, захочет разобраться с maven или ant / ivy.

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

В прошлом у меня были js, css & xsl, общие для многих проектов, упакованные в файлы .tgz и опубликованные в репозиторий ivy с помощью простых сценариев ant, затем в проектах были сборки ant (и ivy.xml).файлы), которые разрешают зависимости, а затем упаковывают все это.Это работало, но

• Ребята из переднего конца боролись с управлением исходным кодом, а тем более с управлением зависимостями.Было действительно трудно заставить их «получить его» достаточно, чтобы опубликовать изменения в общем модуле в локальном репозитории, а затем создать проект, который зависел от него, чтобы сохранить их изменения.

• Дополнительный шаг, о котором говорил Эрик, - необходимость выпустить несколько артефактов, чтобы подготовить что-либо к продукту.

• Унаследованный дизайн Cruddy означал большинство изменений, которые фактически были в общем коде, 1 из 10 выпусковУ развертываемого на самом деле были изменения в его коде ... как правило, он был включен в общий код.

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

Если бы мне пришлось делать это снова -Я бы пошел Maven.