Подверсия и зависимости
Я пытаюсь найти жизнеспособную стратегию к следующей проблеме.
У нас есть несколько веб-проектов, которые зависят от нашей платформы. Все хранится в нашем 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 рабочие копии.
Это решение имеет проблему с зависимостями при ветвлении. Я делаю производство branche от SVN/webprj01/trunk до/webprj01/branches/release-1.0.0. Через два дня при работе над вторым проектом webprj02 и frm01 я больше не могу иметь стабильный контроль как через svn:externals в выпуске 1.0.0 ответвления. каталог frm01 уже указывает на новые изменения frm01/trunk.
Описанный просто упрощенная версия проблемы. В наших реальных ситуациях зависимости иногда идут пять уровней глубоко. Я хотел бы смочь получить стабильный код из SVN в любое время. В различных словах. Когда я перешел/отметил webprj01 как выпуск 1.0.0. Я хочу получить стабильный код для того конкретного тега через год от создания.
Это очевидно, который описал стратегию с помощью svn:externals, не делает работы. Каков был бы Ваш опыт с этой ситуацией? Не необходимо использовать один контроль. Даже использование сценариев сборки или другого решения помогло бы здесь. Я смотрю в течение долгого времени решение проблемы, которая не зависела бы в большой степени от человеческих поступков, поскольку мы подвержены ошибкам.
1 ответ
В мире Java я бы не пытался решить это, используя только систему контроля версий - вместо этого я бы использовал инструмент управления зависимостями вроде Maven + систему контроля версий.
В месте, где я работаю, у нас есть система, которая кажется довольно обычной:
Любой проект "framework" живет в своей собственной структуре каталогов (ствол, теги, ветви), как вы уже, кажется, сделали. Они также управляются с помощью Maven, и каждый раз, когда что-то проверяется, новая версия компонента (в большинстве случаев JAR-файл) публикуется в нашем локальном репозитории Maven (который находится на сервере Nexus).
Любой проект, который должен использовать проект "фреймворка", будет иметь зависимость от определенной версии проекта фреймворка - Maven затем автоматически берет эту версию с сервера Nexus всякий раз, когда проект собирается.
Это позволяет нам выпускать каждый проект и компонент фреймворка отдельно, но при этом отслеживать зависимости между ними. Мы даже можем иметь несколько версий компонентов фреймворка, используемых в разных проектах, не теряя полностью контроль над зависимостями.
Пока что это работает довольно хорошо для нас - я вижу только два недостатка:
Требуется некоторое время для настройки, особенно если вы не использовали Maven раньше.
Есть некоторые накладные расходы при выпуске каждого проекта, поскольку вы хотите выпустить каждый зависимый компонент, чтобы избежать зависимостей от "trunk" версии других компонентов (т.е. "SNAPSHOT" версии в терминологии Maven).