Лучшая практика создания репозиториев subversion?

наша команда (5-10 разработчиков) планирует принять Subversion для наших проектов/решений .NET (Visual Studio) (VisualSVN Server, TortoiseSVN / VisualSVN).

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

наши проекты можно классифицировать таким образом (пример):

  • Главная Номенклатура Товаров
    • Главное Веб-Приложение
      • Библиотека 1
      • библиотека 2
      • ...
    • Клиент Windows
    • Другой Клиент Windows
    • Служба Windows
  • инструменты
    • Инструмент A
    • Инструмент B
  • Линейки 2
    • программное обеспечение 1
    • по 2
  • Линейка Продуктов 3
    • Приложение 1
    • Приложение 2
26
svn visual-studio visualsvn

8 ответов

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

вы хотите все в одном репозитории, если вам не нужен этот уровень контроля доступа, особенно если вам нужно иметь возможность копировать или перемещать файлы между проектами (т. е. проекты могут делиться код.)

поместите разделитель trunk/tags / branch на любом уровне, соответствующем фрагменту кода, который вы можете выпустить как один пакет (т. е. подумайте, где вы бы пометили). Это не критично, чтобы получить право сначала, так как они не отличаются внутренне от любой другой папки, поэтому вы можете просто перемещать вещи позже, хотя, конечно, это аккуратнее, чтобы не иметь эту проблему.

12
17
  • точка зрения управления SVN я предпочитаю 1 хранилище.
  • точка зрения программиста я предпочитаю 1 хранилище.
  • администратор сервера я предпочитаю 1 repostitory.
  • точки зрения безопасности это желательно не ставить все свои яйца в одной корзине.

репозиторий будет несколько уникальных для вашего бизнеса и продукции. Мы храним наши в одном хранилище. Наша структура несколько как этот.

  • /
    • проекты
      • Название Проекта
        • багажник
        • отделения
        • теги
    • документация
        1
  • Общие Библиотеки
    • класс Супер строк
  • небольшой утилиты
    • улучшение vim X
6

мы используем один большой репозиторий и просто структурируем все в подпапках (/project1, /project2 и т. д.), И это, кажется, работает нормально.

проект Apache имеет огромный репозиторий svn и, кажется, все в порядке для них! :)

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

4

У нас есть одно РЕПО, которое структурировано таким образом. Все, что работает более чем несколькими людьми и/ или в активной разработке, настраивается с помощью trunk/ tags/ branch / под главной папкой.

мы, вероятно, поместили бы эти trunk-tags-branch folderset под каждую вложенную папку, которую вы перечислили, за исключением, возможно, библиотеки или двух, которые не находятся в активной разработке.

3

У нас есть отдельные РЕПО для каждого проекта; но основная причина-по причинам доступа плюс, если клиент хочет копию своего источника, мы можем дать ему историю без лишней суеты. Если вы посмотрите на конфигурационные файлы в conf, не так сложно иметь универсальный конфигурационный файл, который будет работать для всех ваших проектов. Мы делаем это так:

[general]
anon-access = none
auth-access = write
password-db = ../../conf/passwd
authz-db = ../../conf/authz

authz:

[groups]
AOS = nathan,mark

[AOS:/]
@AOS = rw
frew = rw

и затем, конечно, passwd:

[users]
frew = password
nathan = awesome
mark = station
1

старайтесь держать регулярно доступный материал (код, скрипты) отдельно от 'write-once and commit to backup' вещи. Необходимость проверки / обновления тысяч jpeg только для изменения нескольких строк кода становится скучным очень быстро.

1

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

Projects
   Project Name
      trunk
      branches
      tags

моя единственная забота-резервное копирование и восстановление. Резервное копирование SVN выполняется на уровне репозитория, поэтому восстановление восстановит все проекты вместо одного.

тело

0