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

Question

Что лучше?

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

Что структура хранилища вы используете и почему?

Answer 1

В главе Repository Administration главы SVN book содержится раздел о Planning Your Repository Organization, в котором излагаются различные стратегии и их значения, в частности the implications of the repository layout on branching and merging.

Answer 2

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

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

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

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

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

Answer 4

Мы используем настройку B. Из-за этого проще просто проверить/отметить несколько проектов. В 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 

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

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