Как вы структурируете свой SVN-репозиторий? - PullRequest
Новая
       18

Как вы структурируете свой SVN-репозиторий?

13 голосов
/ 30 сентября 2008

Что лучше?

A: 

server:1080/repo/projectA/trunk/...
                          branches/branch1
                          branches/branch2
                          branches/branch3
                          tags/tag1/...
                          tags/tag2/...
server:1080/repo/projectB/trunk/...
                          branches/branch1
                          branches/branch2
                          branches/branch3
                          tags/tag1/...
                          tags/tag2/...

B 

server:1080/repo/trunk/projectA/...
                 branches/projectA/branch1
                 branches/projectA/branch2
                 branches/projectA/branch3
                 tags/projectA/tag1/...
                 tags/projectA/tag2/...
server:1080/repo/trunk/projectB/trunk/...
                 branches/projectB/branch1
                 branches/projectB/branch2
                 branches/projectB/branch3
                 tags/projectB/tag1/...
                 tags/projectB/tag2/...

Какую структуру хранилища вы используете и ПОЧЕМУ?

Ответы [ 6 ]

19 голосов
/ 30 сентября 2008

Мы используем А, потому что другой не имеет для нас смысла. Обратите внимание, что «проект» в отношении SVN - это не обязательно один проект, но может быть несколько проектов, которые принадлежат друг другу (то есть то, что вы бы поместили в решение в Visual Studio). Таким образом, у вас есть что-нибудь связанное вместе. Все ветки, теги и ствол конкретного проекта. Имеет смысл для меня.

Группировка по ветке / тегу вместо этого не имеет смысла для меня, потому что ветви разных проектов не имеют ничего общего, кроме того, что они все ветви.

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

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

17 голосов
/ 30 сентября 2008
8 голосов
/ 30 сентября 2008

Я бы предложил вариант C: 

server:1080/projectA/trunk/...
                     branches/branch1
                     branches/branch2
                     branches/branch3
                     tags/tag1/...
                     tags/tag2/...
server:1080/projectB/trunk/...
                     branches/branch1
                     branches/branch2
                     branches/branch3
                     tags/tag1/...
                     tags/tag2/...

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

1 голос
/ 30 сентября 2008

Мы используем настройку B. Так как проще извлекать / отмечать несколько проектов одновременно. В SVN 1.5 это возможно посредством разреженной проверки, но не одним щелчком мыши. Вы хотите использовать настройку B, если некоторые проекты имеют скрытые зависимости между ними.

0 голосов
/ 31 декабря 2011

Лично я использую следующую структуру хранилища: 

/project
    /trunk
    /tags
        /builds
            /PA
            /A
            /B
        /releases
            /AR
            /BR
            /RC
            /ST
    /branches
        /experimental
        /maintenance
            /versions
            /platforms
        /releases

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

Существует также мой ответ на вопрос о «Несколько хранилищ SVN против хранилища одной компании». Это может быть полезно, если вы затронули этот аспект структурирования репозитория в своем вопросе.

0 голосов
/ 30 сентября 2008

Мы используем 

/repos/projectA/component1/trunk - branches - tags
/repos/projectA/component2/trunk - branches - tags
/repos/projectB/component3/trunk - branches - tags
/repos/projectB/component4/trunk - branches - tags

О чем я начинаю сожалеть. Это должно быть более плоским. Это было бы лучше. 

/repos/projectA/trunk - branches - tags
/repos/projectB/trunk - branches - tags
/repos/component1/trunk - branches - tags
/repos/component2/trunk - branches - tags
/repos/component3/trunk - branches - tags
/repos/component4/trunk - branches - tags

Почему? Продукты (компоненты, готовое программное обеспечение) вечны. Проекты приходят и уходят. В прошлом году всего одна команда разработчиков создала продукт QUUX. В следующем году эта команда рассредоточена, и один или два человека поддержат QUUX. В следующем году будет два больших проекта расширения QUUX.

Учитывая эту временную шкалу, должен ли QUUX появляться в трех репозиториях проектов? Нет, QUUX не зависит от какого-либо конкретного проекта. Это правда, что проекты имеют рабочие продукты (документы, журналы и т. Д.), Которые являются частью выполнения работы, но не являются реальной целью работы. Следовательно, репозитории "projectX" для этого материала - вещи, которые никому не понадобятся после завершения проекта.

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

...