Лучший способ организовать хранилище Subversion для многих небольших проектов

Question

Для начала я просмотрел следующие страницы и не получил своего ответа: как вы организуете подрывную деятельность-репозиторий для собственных программных проектов и как-сделай вы упорядочивать-ваш-контроля версий-хранилище

Я также рассмотрел главу 8 Прагматический контроль версий с использованием Subversion .

У них всех есть хороший совет, но мне трудно связать его с моими потребностями.

По сути, я хочу организовать код для нашего веб-сервера. У нас есть $ WEBROOT / htdocs и $ WEBROOT / cgi-bin. В нашем каталоге htdocs у нас есть $ WEBROOT / htdocs / js и $ WEBROOT / htdocs / css для сценариев Java и таблиц стилей.

Наши "проекты" на самом деле являются не проектами, а небольшими кусочками кода - может быть, сценарий Perl, файл сценариев Java и таблица стилей. У нас может быть около сотни таких небольших «проектов», которые в значительной степени независимы друг от друга, но все живут под одним и тем же $ WEBROOT на одном веб-сервере.

Наш код еще не находится в подрывной деятельности, но я хочу, чтобы он был - у меня просто проблемы с его эффективной организацией. Мы можем иметь несколько svn-репозиториев, если это необходимо, но если в каждом репозитории всего 3-10 элементов, это кажется пустой тратой.

То, что я думал, может сработать, примерно так: если я напишу скрипт для подсчета запущенных процессов на веб-сервере (для примера). Допустим, у меня есть сценарий perl, файл js и файл css. Я мог бы назвать "project" webserver_processes и проверить его в хранилище как:

/svnrepo/webserver_processes/trunk

Под стволом я мог бы иметь:

htdocs/html/webserver_processes
htdocs/js/webserver_processes
htdocs/css/webserver_processes
cgi-bin/webserver_processes

У меня нет статических html-документов в этом "проекте", но если бы я это сделал, они пошли бы в каталог "html".

Преимущество, которое я вижу в этой структуре, заключается в том, что я могу оформить один «проект» за раз, не оказывая существенного влияния на что-либо еще на веб-сервере. Недостаток (и, возможно, это на самом деле не недостаток) заключается в развертывании. Я должен был бы развернуть 1 проект за один раз из хранилища. Я не понимаю, как можно было бы создать рабочую копию с моей структурой $ WEBROOT / htdocs и $ WEBROOT / cgi-bin, используя этот метод.

Другой вариант:

Я мог бы создать хранилище SVN, как это:

/svnrepo/webcode/trunk

Под транком будет весь код на моем веб-сервере, в этих двух каталогах:

htdocs
cgi-bin

Огромным недостатком было бы то, что для небольшого изменения кода на 1 элемент мне пришлось бы проверять каждый фрагмент кода в моей веб-среде. Выгода (в некоторой степени) состояла бы в том, что я мог бы сделать svn-обновление на нашем веб-сервере, чтобы зафиксировать любые изменения, внесенные в репозиторий.

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

Заранее большое спасибо!

Brian

Answer 1

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

Ваш репозиторий SVN будет выглядеть (ваш первый вариант.)

/svnrepo/project1/trunk
/svnrepo/project1/trunk/htdocs
/svnrepo/project1/trunk/css
...
/svnrepo/project1/branches/branch1
/svnrepo/project1/tags/blah
/svnrepo/project2/trunk
/svnrepo/project3/trunk

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

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

edit: случайно сохранены и добавлены дополнительные каталоги для ясности

Answer 2

Сначала используйте один репозиторий. Для примера того, насколько хорошо может масштабироваться один репозиторий, посмотрите на Apache svn репозиторий . Все это один репозиторий.

Если вы используете одну транк, которая непосредственно развернута на веб-сервере, то вам необходимо убедиться, что транк готов к развертыванию. Это означает, что вся разработка должна сначала происходить в ветви, которая объединяется обратно. Вы не хотите в конечном итоге оказаться в ситуации, когда один проект наполовину завершен, но находится в транке, а другому проекту необходимо выполнить развертывание с исправлением ошибок в транке.

Я бы не стал беспокоиться о том, чтобы люди проверяли весь ствол, но если это реальная проблема, то вы могли бы рассмотреть гибридный подход:

/svnrepo/trunk/project1/...
/svnrepo/trunk/project2/...
/svnrepo/deploy/htdocs
/svnrepo/deploy/cgi-bin

В этом случае разработчики должны сделать svn copy из своего проекта в транке в соответствующее место в каталоге развертывания. После этого вы можете автоматически разблокировать все под deploy.

Answer 3

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

Answer 4

Я думаю, что ваша лучшая ставка - это второй вариант: иметь весь код в одном репо с каталогами htdocs и cgi-bin. Это правда, что вам придется проверить весь ваш код, но вы сделаете это один раз, а остальные изменения будут намного меньше. Если это рабочий сервер, то вам, очевидно, нужно проверить, что весь ваш код готов к работе: так сказать, держите магистральный зеленый.

В будущем это также может помочь в устранении дублирующихся функций.