Организация проектов SVN: по модулям или по проектам

У меня есть репозиторий subversion, который содержит несколько подпапок, соответствующих различным приложениям, файлам конфигурации, библиотекам DLL и т. д. (я буду называть их «модулями»), составляющим мой проект. Сейчас мы начинаем «разветвляться» на несколько связанных проектов. То есть каждый высокоуровневый проект будет использовать несколько модулей, которые, возможно, немного изменятся от проекта к проекту. Количество проектов меньше (~5), чем количество модулей (~20)

Теперь я пытаюсь понять, как организовать репо. Имеет ли смысл сохранять вложенные папки верхнего уровня для каждого модуля с подпапками для каждого проекта? Или верхний уровень должен быть для каждого проекта, причем каждый проект имеет свои собственные подпапки модуля:

репо:

module 1
    Project 1
    Project 2
    ...

    Project 5
module 2
    Project 1
    ....
    Project 5
....
module 20
    Project 1
    ...
    Project 5

-or-

репо:

Project 1
   module 1
   module 2
   ...
   module 20
Project 2
   module 1
   module 2
   ...
   module 20
...
Project 5
   module 1
   module 2
   ...
   module 20

svn project-organization
person eglaser    schedule 25.09.2008    source источник

Ответы (5)


arrow_upward
3
arrow_downward

Лучше организовать по Проекту на верхнем уровне, поскольку вам нужно будет получить всю ветку и получить рабочую копию для проекта. Если вы организуете по модулям, вам придется сделать несколько проверок (по одной для каждого модуля, который вы используете), чтобы построить свой проект до такой степени, что его можно будет использовать.

Может иметь смысл разделять проекты и модули, например:

Projects
   Project 1
   Project 2
   ...
Modules
   Module 1
   Module 2
   ...

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

person Adam Bellaire    schedule 25.09.2008

arrow_upward
1
arrow_downward

Я бы организовал по проектам, ТОГДА по модулям (ваш второй пример). Основная причина этого в том, что управление проектом требует больше усилий, по крайней мере для меня, чем управление модулями.

Для каждого отдельного проекта требуется своя собственная настройка сценария сборки, файл свойств и т. д., и намного проще отслеживать 5 рабочих копий на вашем компьютере, чем 20.

person Gilligan    schedule 25.09.2008

arrow_upward
1
arrow_downward

Я предпочитаю 1-й.

Хотя поддержка каждого репозитория требует дополнительных усилий, я предпочитаю, чтобы номера версий имели смысл для проекта.

т.е. наш флагманский продукт имеет ревизию 48123, наш новый проект имеет ревизию 31. Если у вас есть межрепозитарные зависимости, то вы можете использовать svn externals.

person Ben Scheirman    schedule 25.09.2008
comment
+1 Эти номера сборки полезны в средах непрерывной сборки. - person JMP; 14.10.2010

arrow_upward
0
arrow_downward

Я думаю, что ваше использование «высокого уровня» для описания проекта предполагает, что у вас должна быть настройка проектов/модулей.

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

person JeeBee    schedule 25.09.2008

arrow_upward
0
arrow_downward

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

Между прочим: вы, кажется, ожидаете работать в одном большом репозитории, что я считаю разумным, потому что это означает лучшую обработку истории: как только вы перемещаете материал между репозиториями, вы теряете историю. Другими словами, я не согласен с советом Бена Шейрмана по этому поводу.

person Troels Arvin    schedule 25.09.2008