Взвешивание факторов настройки для Subversion

Question

У меня есть несколько разных проектов, около 5, и несколько разных разработчиков, около 15, и некоторые проекты находятся в подрывной деятельности, а некоторые нет. Все разработчики работают на компьютерах под управлением Windows с TortoiseSVN, а код проектов представляет собой смесь классического asp и asp.net. Каков наилучший, с точки зрения наиболее отзывчивого, полезного и простого в администрировании, способ, при котором все проекты находятся в подрывной деятельности и имеют аутентифицированный доступ для всех разработчиков, как для чтения, так и для записи?

Некоторые из вещей, которые следует учитывать, - это обслуживать их через svnserve или apache, что означает проблемы со скоростью, простоту администрирования доступа / пользователей и паролей и необходимость открывать дополнительный порт брандмауэра (если svnserve)

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

Answer 1

• Я бы порекомендовал использовать один репозиторий для всех ваших проектов. Это значительно упрощает настройку доступа для ваших разработчиков. Кроме того, вам нужно сделать резервную копию только одного хранилища. Не только это, но также позволяет легко копировать файлы (и поддерживать историю этих файлов) между проектами. Это, вероятно, случается не так часто, но приятно, когда это происходит. Создание новых проектов так же просто, как 'svn mkdir'.

И вы на самом деле не много теряете, используя один репозиторий. Вы по-прежнему можете настроить права доступа к каждому проекту, как вам нравится.

Ваша структура каталогов svn может выглядеть следующим образом:

projects/
    proj1/
        trunk/
        branches/
        tags/
    proj2/
        trunk/
        branches/
        tags/
    ...

• Насколько велики ваши проекты? Использование SVN через HTTPS работает очень хорошо, особенно если ваше сетевое соединение быстрое. HTTPS также является довольно универсальной системой доступа. Если вы постоянно не проверяете сотни или тысячи файлов (или если вы не пытаетесь обвинить файл с тысячами ревизий), разница в скорости может не стоить вам. В нашей компании мы используем svnserve и аутентифицируемся с билетами Kerberos, но это намного сложнее настроить.

Answer 2

Я бы порекомендовал

1. Apache , не svnserve - он достаточно быстрый, дружественный к брандмауэрам и прокси-серверам, и администратор пользователя в любом случае работает одинаково. Я также считаю весьма полезным иметь возможность просматривать мои репозитории с помощью браузера.

2. Только один репозиторий , с папкой для каждого проекта, содержащей ствол / ветви / теги. Это намного гибче, чем я думал на первый взгляд, и во многих случаях вам не нужны подкаталоги для транка / веток / тегов. Намного проще управлять одним репозиторием, и у вас есть контроль версий, поэтому вам не нужно беспокоиться о том, что пользователи могут испортить чужие проекты или что-то подобное.

Answer 3

Если вы все на относительно быстрых линиях, запуск SVN через Apache 2 с SSL - отличный вариант. Нет проблем с брандмауэром, и аутентификацию пользователя можно выполнить несколькими способами.

У меня есть размещенная учетная запись SVN на другом континенте, потому что SSL не такой быстрый, но приемлемый, поскольку речь идет об исходном коде, не слишком много передачи данных. Если у вас есть ближе сервер, я уверен, что производительность будет вполне нормально.

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

Answer 4

Несколько проектов против одного проекта:

Если код общий и файлы будут перемещаться, используйте один репозиторий. Если код изолирован, используйте много. Помните, что:

1. Единый репозиторий позволяет легко перемещать файлы и переименовывать каталоги
2. Изменение в репозитории увеличивает номер ревизии повсюду в этом репозитории
3. Структура физического каталога разработчика может отличаться от структуры svn

Аутентификация

Используйте apache, и SSL не требуется, если вы настраиваете apache для аутентификации всегда.

<Location /svn/test>
    DAV svn
    SVNPath /svn/test
    <LimitExcept GET PROPFIND OPTIONS REPORT>
       AuthType Basic
       AuthName "Authorization Realm"
       AuthUserFile /svn/passwd
       Require valid-user
    </LimitExcept>
</Location>

Вы можете играть с этими правилами, чтобы запрашивать пароль при оформлении заказа или нет. И ваши пароли живут в этом одном файле /svn/passwd.

И ...

Также используйте trac. Он прекрасно интегрируется с Subversion и предоставляет разработчикам интерфейс от Subversion для просмотра их файлов / наборов изменений и т. Д.

Answer 5

Есть только два безопасных способа, которыми я могу придумать: использовать svn через SSH-туннель или использовать svn для получения / передачи по протоколу HTTP с поддержкой SSL через веб-сервер.

Я бы оставил каждый проект в своем собственном репозитории, используя стандартный формат транка / веток / тегов для каждого проекта в качестве макета репозитория. Это более чистый макет, поскольку каждая вещь имеет свой собственный контейнер, и если одна из баз данных Subversion будет повреждена или заклинена, это не повлияет на всю работу во всех проектах.