Структура хранилища SVN

Question

Я готов настроить SVN-репозиторий и задавался вопросом, есть ли у кого-нибудь хороший пример структуры репо. Сейчас я думаю:

Разработка
.. Приложения
.... App1
...... ствол
...... ветви
...... теги
.. База данных
.. Третья партия

Хотя эта структура могла бы, вероятно, держать все, что нужно, я хотел бы сделать он немного более гранулирован. Есть предположения?

Answer 1

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

Вместо этого мы рассматривали схему, как следующее:

trunk 
    app1 
    app2 
    lib1 
    lib2 
    branches 
    rc-2.0 
     app1, app2, lib1, lib2... 
    some-devs-branch 
     app1, lib2 
    tags 
    release-1.0 
     app1, app2, lib1, lib2... 

Я люблю, когда отдельный репозиторий исключительно для третьих сторон материала. Если вы не планируете реализовать полностью vendor-branching strategy от red bean book, это будет хорошо работать.

Answer 2

SVN предоставляет теги для получения «моментального снимка во времени» исходного дерева в определенное время (которое вы можете использовать для выпусков и т. Д.).

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

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

Answer 3

Мы тоже боремся с этим.

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

У всех конфигураций есть pro и con, но имея 1 полный репозиторий, вы можете быть (почти) уверены, что у вас есть все файлы вместе в правильной версии. Если вы работаете с несколькими туловищами, есть трюки с виртуальными папками или ссылками (я забыл термин), чтобы связать их друг с другом, но вернуться к тому, где вы были, очень сложно.

Просто помните, что у каждой конфигурации есть pro и con, но для не крупной компании я бы предложил разместить все в одном репо с одной родительской папкой.

Answer 4

Мой нынешний подход разбивает системы на логические границы приложений под одним хранилищем.

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

/project1/application1/ 
         trunk/ 
          Src 
          Test 
          Database 
         tags/ 
         branches/ 
     application2/ 
         trunk/ 
          Src 
          Test 
         tags/ 
         branches/      

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

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

Answer 5

Мы всегда создаем отдельный SVN-репозиторий для каждого отдельного «решения». Этот репозиторий тогда просто имеет простую структуру стволов, ветвей и тегов.

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

Answer 6

Наличие единого репо для всего означает, что у вас есть довольно хороший шанс оказаться в огромном хранилище довольно быстро. Это означает, что все может замедляться и немного сложно отслеживать. Очевидно, это зависит от вашего конкретного варианта использования, но лично я бы выбрал репозитории для каждого проекта и использовал svn: externals, где это необходимо.

На самом деле, я выбрал бы для распределенной VCS над SVN, если это возможно, но каждому свое ...