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

Question

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

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. код поставщика Checkout в папку поставщика под правильным названием проекта.

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

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

EDIT:

Я предполагаю, что я смущен, потому что у меня нет кода или проект, чтобы начать с, так что я начинаю свежий от кода поставщика. Нужно ли мне создавать структуру каталогов где-то на сервере, которая включает в себя мои подкаталоги project_name w/vendor, trunk, филиалы и теги, импортировать их в мое репо, а затем импортировать код из поставщика в папку поставщика? Идея состоит в том, что я могу получать обновления от поставщика, а затем объединять эти обновления с любыми изменениями, внесенными мной в мой багажник.

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», я думаю, вы имеете в виду либо «импорт», либо «checkin» (обычно называемый «commit» на языке SVN, но «checkin» будет понят). Импорт добавит файлы поставщика в репозиторий. Checkout означает «создать локальную копию этого каталога версий для меня, чтобы работать с», называемой рабочей копией. Каждый разработчик вашей команды должен иметь свою собственную рабочую копию. После того, как разработчик вносит изменения в свою рабочую копию, они затем отправляют изменения в репозиторий svn commit. Другие разработчики в команде запустится svn update, чтобы получить эти изменения из репозитория в свои собственные рабочие копии.

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

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