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

Ответ 1

Глава Администрирование хранилища в Планирование организации репозитория, в котором описываются различные стратегии и их последствия, в частности последствия размещения репозитория при ветвлении и слиянии.

Ответ 2

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

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

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

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

Ответ 3

Я бы предложил вариант 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 упрощает управление проектами библиотеки кода, которые распределяются между двумя или несколькими проектами приложений.

Ответ 4

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

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

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

Ответ 6

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

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

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

Существует также ответ fooobar.com/info/107343/... о 'Множественных хранилищах SVN и репозиториях одной компании ". Это может быть полезно, если вы рассматриваете этот аспект структурирования репозитория в своем вопросе.