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

Question

Для начала, я посмотрел на следующих страницах и не совсем у меня ответ: how-would-you-organize-a-subversion-repository-for-in-house-software-projects и how-do-you-organize-your-version-control-repository

Я также посмотрел на главу 8 от Pragmatic Version Control using Subversion.

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

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

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

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

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

/svnrepo/webserver_processes/trunk 

Под стволом, я мог бы:

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

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

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

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

я мог бы создать репозиторий SVN вроде этого:

/svnrepo/webcode/trunk 

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

htdocs 
cgi-bin 

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

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

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

Brian

Answer 1

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

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

/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 

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

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

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