Какова оптимальная конфигурация для обслуживания нескольких проектов с Subversion? - PullRequest
1 голос
/ 02 июня 2009

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

Я пишу небольшое приложение Django для базового управления проектами, что-то вроде упрощенного кода Google, и мне нужна тесная интеграция с SVN, что означает, что я хочу иметь возможность управлять правами доступа пользователей. Я также хочу, чтобы мое приложение создавало хранилище при создании проекта, как это делает Google Code.

Теперь проблема:

Я мог бы обслуживать один репозиторий и складывать все свои проекты в корневую папку (как в настоящее время я делаю) ИЛИ запускать демон svnserve для каждого репозитория.

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

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

http://articles.slicehost.com/2007/9/6/multiple-repositories-and-subversion

Однако мой коллега считает это излишним, и я не должен этого делать.

Для себя я думаю, что, учитывая, что я вряд ли когда-нибудь перейду более 100 проектов, это не проблема. И даже если бы у меня было нереально 500 активных проектов, сервер, вероятно, справился бы с 500 бездействующими процессами.

Кто прав?

Или я должен пойти на что-то еще, например, Mercurial?

Ответы [ 2 ]

2 голосов
/ 02 июня 2009

Перейти с несколькими хранилищами. Это то, что я делаю, это не перебор. Я использую что-то вроде VisualSVN Server Manager для управления ими. Он может даже настроить https и сокращенный сервер Apache для вас. (только окна)

1 голос
/ 02 июня 2009

IIRC Apache выбрал один большой репозиторий v.s. много небольших репозиториев. Я считаю, что различия, влияющие на выбор подхода, наиболее заметны, если вам нужно совместно использовать код в репозиториях. Есть некоторые инструменты и операции, которые просто не работают с отдельными репозиториями. Насколько я помню, в примечаниях к выпуску для последних выпусков TortoiseSVN и / или Subversion были некоторые подробные комментарии, в которых упоминались некоторые из этих ограничений. Я лично столкнулся с некоторыми из этих наземных мин, особенно при работе со сторонними хранилищами.

FWIW - я использую отдельные репозитории, так как я работаю для многих разных клиентов. VisualSVN Server, также упомянутый Malfist, очень хорош тем, что вы работаете в Windows, и делает его простым в настройке нескольких репозиториев. Выполнение того же самого вручную с нуля требует гораздо большего опыта, особенно если вы используете Apache HTTPD в качестве внешнего интерфейса. Apache является предпочтительным подходом, особенно если вы подключаете SNV к Интернету или вам нужен больший контроль над доступом.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...