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

Ответ 1

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

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

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

Ответ 2

Мой источник вдохновения:

• Управление версиями с Subversion
• Макет репозитория Subversion
• Единый репозиторий или много
• Несколько репозиториев Subversion

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

Мы бы, вероятно, поместили те патч-стрит-теги-ветки-ветки в каждую подпапку, которую вы указали, за исключением, возможно, библиотеки или двух, которые не находятся в активной разработке.

Ответ 6

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

Ответ 7

У нас есть отдельные репозитории для каждого проекта; но главная причина - причины доступа плюс, если клиент хочет получить копию своего источника, мы можем дать ему историю без излишней суеты. Если вы посмотрите на конфигурационные файлы в 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

Ответ 8

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

Projects
   Project Name
      trunk
      branches
      tags

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

Цзижун