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

Question

Что лучше?

А:

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/...

Б:

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/...

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

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/...

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

Answer 4

Мы используем установку Б.Потому что легче проверить/пометить несколько проектов одновременно.В svn 1.5 это возможно посредством разреженной проверки, но не в один клик.Вы хотите использовать настройку B, если между некоторыми проектами есть скрытые зависимости.

Answer 5

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

/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» для этого материала — вещи, о которых никто не будет заботиться после завершения проекта.

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

Answer 6

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

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

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

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