В отличие от «нормальной» структуры каталогов svn, я использую следующую структуру:
хобот/ project1 / project2 / project3 / ... ветви/ project1-филиал / project1 / project2 / ... project2-филиал / project1 / project2 / ... теги / project1 / V1 V2 ...
Как видите, у меня нет отдельных троек (ствол / ветви / теги) для каждого проекта.
Для разработки я делаю извлечение ствола (иногда разреженное извлечение), содержащее все проекты, которые мне нужны (есть зависимости между проектами, а некоторые проекты являются просто библиотеками).
Преимущества, которые я вижу в этом:
Обновление и регистрация просты, потому что у меня есть общий корневой каталог (транк) всех проектов. Один простой
svn update
илиsvn commit
все это делает.Создать тег или ветку просто, потому что для этого мне нужен только ствол
svn copy
. (На самом деле ветки и теги содержат больше проектов, чем необходимо, но этоsvn copy
дешево, и я все еще могу делать редкие проверки на ветке или теге, если это необходимо.)Перемещение ресурсов из одного проекта в другой легко, потому что все они находятся в одном репозитории.
Глобальный рефакторинг (например, изменение пакета часто используемого класса) очень прост, когда я работаю над полной проверкой транка, потому что я могу быть уверен, что не пропущу проект.
Объединить легко, потому что я всегда могу объединить всю ветку сразу, даже если был рефакторинг, переходящий из одного проекта в другой.
Я собираюсь перейти на Maven и разделить все проекты от магистральных до Maven. Я хотел бы извлечь выгоду из управления зависимостями maven и из доступных плагинов (сейчас я использую огромные пользовательские файлы ant).
Теперь мои вопросы:
Нужно ли менять структуру каталогов svn, чтобы каждый проект имел свою тройку (trunk / branch / tags)? Я думаю, что ответ «да».
Если я изменю структуру, то какие из упомянутых выше преимуществ я потеряю (я имею в виду, что будет сложнее сделать с Maven)?
Каковы эквивалентные способы сделать это с Maven?
Нет такой вещи, как "нормальная" структура каталогов svn. Существуют различные подходы , как это обсуждалось в разделе «Планирование Repository организации» от контроля версий с Subversion книгой (даже /trunk
, /tags
, /branches
названия только конвенция и нет никакой разницы между меткой и филиалом, за исключением вашего восприятия из них) ,
- Нужно ли менять структуру каталогов svn, чтобы каждый проект имел свою тройку (trunk / branch / tags)? Я думаю, что ответ «да».
Нет, ты не обязан . Посмотрите, например, дерево исходников Apache ServiceMix : это многомодульный проект maven, но модули находятся под одним trunk
. С другой стороны, XWiki, который является не единственным продуктом, а экосистемой продуктов и проектов, как подробно описано на его странице репозитория исходного кода , имеет множество стволов / ветвей / тегов. Вы можете просмотреть его хранилище здесь, чтобы получить представление о макете.
Но выбор того или иного подхода - это не просто вопрос вкуса, он зависит от вашего цикла выпуска (подробнее об этом mvn release
позже). Если бы компоненты вашего проекта имели одинаковую версию (а-ля ServiceMix), я бы использовал только одну магистраль. Если бы у них был независимый цикл выпуска (а-ля XWiki), я бы использовал множественную структуру "trunk / tags / branch", подобную той, которая описана в этой теме :
myrepo + .links (2) + trunks + pom.xml + parent-pom (1) + trunk + pom.xml + project-A + trunk + pom.xml + project-B + trunk + pom.xml
1) Родительское ПОМ проекта имеет собственный цикл выпуска. POM каждого компонента будет использовать его как родительский (на который ссылаются просто с
groupId
иartifactId
, нетrelativePath
). Для выпуска вы должны будете сначала выпустить родительский POM.2) Это конструкция, позволяющая легко проверять конкретную ветку проекта, то есть, как правило, ствол. Пользователь Subversion проверяет myrepo / .links / trunk, чтобы получить основную ревизию всех источников. Хитрость в том, что этот каталог содержит внешние ссылки (то есть со
svn:externals
свойством) на соединительные линии всех других модулей этого проекта (parent-pom, project-A, project-B). Файл pom.xml в этом каталоге никогда не выпускается, он содержит просто раздел модулей для трех модулей, чтобы включить многомодульную сборку. С помощью этой конструкции вы можете легко настроить ветви, например:myrepo + .links + branch-2.x + pom.xml
Я использовал эту настройку много раз, она работает довольно хорошо.
- Если я изменю структуру, то какие из упомянутых выше преимуществ я потеряю (я имею в виду, что будет сложнее сделать с Maven)?
Позвольте мне ответить на каждый вопрос по одному.
Обновление и регистрация легко благодаря SVN Externals . Один простой
svn update
илиsvn commit
все это делает.Создать тег или ветку просто, потому что плагин релиза maven будет обрабатывать это для вас (а теги и ветви будут чище).
Перемещение ресурсов из одного проекта в другой не выглядит сложнее.
Глобальный рефакторинг (например, изменение пакета обычно используемого класса) прост, потому что вы все еще можете работать над полной проверкой транка.
Слияние может быть менее простым. Но действительно ли вы часто перемещаете классы из одного проекта в другой?
- Каковы эквивалентные способы сделать это с Maven?
При необходимости используйте плагин релиза maven и один из предложенных макетов с svn externals.
Если вы хотите использовать Maven только для управления зависимостями и думаете, что структура вашего проекта уже достаточно хороша / работает для вас, вот полезный совет: забудьте Maven.
Maven - это гораздо больше, чем просто инструмент управления зависимостями, он называет себя « инструментом управления и понимания программных проектов », который, очевидно, охватывает зависимости, но также и множество других основ. Поскольку вы хотите иметь только управление зависимостями, вы должны хотя бы взглянуть на такой инструмент, как Ant Ivy, который существует исключительно для управления зависимостями.
Реальное преимущество Ivy заключается в том, что вы можете справляться с управлением зависимостями намного лучше и более детально, чем с Maven, сохраняя при этом существующие структуры проекта, сценарии сборки и практически все, что вы уже построили на его основе. Плющ не усиливает структуру проекта или шаблоны конфигурации, он позволяет вам определить, что вы хотите получить от инструмента управления зависимостями, а затем добавить его в свой проект, вместо того, чтобы заставлять ваш проект конструктивно становиться чем-то, о чем некоторые люди говорят в слоновой кости ,
Чтобы еще больше помочь вам принять решение, вот сравнение между собой обеих сторон:
- Сравнение Ivy / Maven2 от разработчиков Ivy
- Сравнение Maven / Ivy (плюс другие) от разработчиков Maven - не забудьте прочитать комментарии тоже