Факторы настройки взвешивания для подрывной деятельности

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 over HTTPS работает очень хорошо, особенно если ваше сетевое соединение выполняется быстро. HTTPS также является довольно универсальной системой доступа. Если вы не постоянно проверяете сотни или тысячи файлов (или если вы не пытаетесь обвинить файл в тысячах ревизий), разница в скорости может не стоить того, чтобы вы это делали. В нашей компании мы используем svnserve и аутентифицируем билеты на kerberos, но это намного сложнее настроить.

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Используйте 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.

И ...

Использование ПРОФ, а также. Он прекрасно сочетается с подрывной деятельностью и дает разработчикам интерфейс от подрывной деятельности, чтобы посмотреть на их файлы/изменения и т. Д.