Предложения по настройке хранилища Subversion

Question

Наша команда только начинает использовать систему контроля версий через SVN. В настоящее время мы используем некоторые тестовые репозитории для привыкания к процессу.

Мы почти готовы использовать это на постоянной основе.

Мы создаем только малые или средние / большие веб-приложения, большинство из которых имеют одно и то же ядро ​​(но отличаются от LAMP / Win), но настроены каким-то образом. У нас, вероятно, будут сотни проектов в хранилище. Кроме того, мы обычно делаем более одного проекта для одной организации.

У нас есть разработчики LAMP и Windows. (Я думаю, что это несколько отличает вопрос от Лучшая практика для создания репозиториев Subversion? )

Есть ли у вас какие-либо предложения о том, как структурировать хранилище?

Answer 1

Я думаю, что достаточно одного хранилища (конечно же, с резервной копией) с отдельными каталогами проектов под ним:

/usr/share/code_repository
   /base
      /trunk
      /branches
      /tags
   /project1
      /trunk
      /branches
      /tags
   /project2
      /trunk
      /branches
      /tags
   ...

Таким образом, base - это основной код, а project1, project2, ... projectN будет содержать варианты базы. Когда вы извлекаете projectN, вы также проверяете базу и имеете ссылки на базу из Project1.

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

Это больше похоже на архитектуру упаковки кода, чем на структуру контроля версий.

Answer 2

Как вы структурируете репо, вероятно, будет зависеть от цикла выпуска. Когда вы создадите новую версию своего общего ядра, вы разовьете ее сразу всем своим клиентам? Или вы будете выполнять постепенное развертывание, поскольку каждому клиенту нужны новые функции (и, следовательно, им нужны новые функции в ядре)?

Если вы обновляете свое ядро ​​для всех, то вам, вероятно, понадобится один набор веток / тегов / ствола:

branches/
tags/
trunk/
    core/
    customer1/
        project1/
        project2/
    customer2/
        project1/
        project2/

Недостатком этого является то, что, если для каждого клиента есть много кода, ваши заказы будут огромными, и вам придется проверять все, чтобы иметь возможность что-либо делать (хотя SVN 1.6 дает вам возможность проверить подмножество дерева).

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

core/
    branches/
    tags/
    trunk/
customer1/
    branches/
    tags/
    trunk/

Если вы сделаете это, вам, вероятно, захочется заглянуть в svn:external, чтобы вы получали копию общего ядра всякий раз, когда проверяли исходное дерево customer1. Это вызывает некоторые проблемы, когда вы хотите разветвить или пометить, хотя. (Что может быть причиной для предпочтения первого варианта.)

Если вы еще этого не сделали, прочитайте « Прагматический контроль версий с использованием Subversion ». У них есть несколько примеров использования внешних устройств, которые могут помочь уточнить, какую схему вы хотите использовать.

Answer 3

Создание разных проектов в разных репозиториях (на одной машине). Так что вы можете контролировать изменение списка рассылки для каждого проекта отдельно:)

Answer 4

Самое замечательное в подрывной деятельности состоит в том, что вам не нужно особо заботиться об этом в начале.

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

Если нет, его можно изменить позже без особых проблем.

Answer 5

Это субъективный вопрос, поэтому вы можете захотеть изменить теги.

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

Традиционная структура SVN, унаследованная от CVS, состоит в том, чтобы trunk, branches и tags находились в стороне от основного каталога проекта. Это будет дублироваться для каждого отдельного каталога проекта.

Для взаимозависимых проектов я лично предпочитаю

root/somepath
  trunk
    myproject
  branches
    branch1
      myproject
    branch2
      myproject
  tags
    tag1
      myproject
    tag2
      myproject

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

Но это сильно зависит от ваших скриптов сборки и того, как вы планируете, чтобы разработчики или пользователи проверяли. Что лучше, так это то, что логично и эффективно для ваших проектов.

Answer 6

Правильный ответ: «Все, что работает лучше для вас».

Есть люди, которые расскажут вам о преимуществах этого способа по сравнению с этим способом, но в конце концов, имея проект -> {ствол, теги, ветви} или {ствол, теги, ветви} -> проект или если у вас есть ветка выпусков, или вы переименовываете их во что-то еще, или у вас есть другие именованные элементы или удаляете некоторые из названных элементов, все зависит от того, как вы и ваши коллеги работаете и что лучше всего подходит для вашего цикла разработки. 1003 *

Однако из того, что вы сказали, я бы предложил следующее:

repository
    core
        trunk
        branches
        tags
    project1
        trunk
        branches
        tags
    project3
        trunk
        branches
        tags

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