Является ли это правильным шагом и организацией для создания репозитория SVN с несколькими проектами и поставщиками?

Question

Я прочитал довольно много из SVN Book о Red Bean Software, и некоторые вопросы здесь, на SO, но я хочу убедиться, что я иду об этом правильно с первого раза, шаг за шагом шаг, прежде чем я начну его использовать. Это правильно?

1. Установить SVN.

2. Создать SVN-репозиторий в / usr / local / svn. Структура каталогов выглядит следующим образом:

   -- conf
   -- db
   -- format
   -- hooks
   -- locks
   -- README.txt
   

3. Создание папок через командную строку для организации хранилища (включая проекты и поставщиков).

   -- conf
   -- db
   -- format
   -- hooks
   -- locks
   -- projects
      -- project_name
         -- vendor
         -- trunk
         -- branches
         -- tags
      -- project_name
         -- vendor
         -- trunk
         -- branches
         -- tags
   -- README.txt
   

4. Извлечь код поставщика в папку поставщика под правильным именем проекта.

5. Экспорт кода поставщика в транк под правильным именем проекта (слияние не требуется, поскольку у меня еще нет файлов транка проекта).
6. Создание пользователей / разрешений в / svnroot / conf / passwd и /svnroot/conf/svnserve.conf.
7. Убедитесь, что svnserve работает, и на моем локальном SVN-клиенте (TortoiseSVN) извлеките транк для проекта, который мне нужен.

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

EDIT:

Полагаю, я в замешательстве, потому что у меня нет кода или проекта для начала, поэтому я начинаю заново с кода поставщика. Нужно ли создавать структуру каталогов где-нибудь на сервере, которая включает мои подпапки имя_проекта с вендором, стволом, ветвями и тегами, импортировать их в мое хранилище, а затем импортировать код от поставщика в папку поставщика? Идея заключается в том, что я могу получать обновления от поставщика, а затем объединять эти обновления с любыми изменениями, которые я внес в свой ствол.

Answer 1

Создание папок через командную строку для организации хранилища (включая проекты и поставщиков).

Вы имеете в виду создание структуры хранилища путем создания каталогов внутри каталога установки subversion? Это очень неправильно.

Вам необходимо создать необходимые папки с помощью команды svn mkdir, а не через файловую систему.

В /usr/local/svn у вас есть физическая реализация хранилища Subversion, и вы должны обращаться к нему только через клиента и никогда не трогать его «вручную».

Например, используя файл: // URL схема

svn mkdir file:///usr/local/svn/projects -m "Parent dir for projects created"

Answer 2

Похоже, у вас в основном правильная идея, но ваша терминология немного ошибочна. Это действительно запутает людей SVN, так как вы используете слова, которые имеют определенное значение в контексте SVN. Чтобы расширить то, что сказал Давиде:

2) создайте свой репозиторий, выполнив что-то вроде svnadmin create /usr/local/svn.

3) создайте свои папки. Вам не нужны (или не нужны) части вашего списка, которые не ниже projects/. Эти другие каталоги используются SVN для отслеживания изменений, но на самом деле их нет в хранилище. Если вы создадите иерархию каталогов где-нибудь в вашей системе, которая содержит поддерево project_name/, вы можете запускать svn import на нем столько раз, сколько хотите, по одному разу для каждого проекта (каждый раз давая другое имя для назначения). Это создаст вашу структуру каталогов.

4) Вместо «checkout», я думаю, вы имеете в виду «import» или «checkin» (обычно на языке SVN называется «commit», но «checkin» будет понятен). Импорт добавит файлы поставщика в хранилище. Оформление заказа означает «создать локальную копию этой версионной директории для меня, с которой можно работать», известную как Рабочая копия. Каждый разработчик в вашей команде должен иметь свою собственную рабочую копию. После того, как разработчик внес изменения в свою рабочую копию, он затем svn commit отправляет изменения в хранилище. Другие разработчики в команде запустят svn update, чтобы перенести эти изменения из хранилища в свои рабочие копии.

5) В последнее время я не читал книгу SVN, но я думаю, что она советует вам копировать версию ветки поставщика в ствол, а не экспортировать ее. Экспорт в терминах SVN означает отмену версии дерева каталогов, что явно не то, что вам нужно.

Вам может быть проще, если вы выполните шаги 6 и 7 сразу после шага 2, с тех пор вы можете использовать протокол svn:// для доступа к вашему хранилищу для оставшихся шагов вместо file://, как предложено Davide, которое только работает на локальной машине.