Структура репозитория SVN

У нас есть тоже боролся с этим.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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