Использование Subversion в качестве стандартного репозитория контроля версий для крупной фирмы по разработке

Question

Я ищу предыдущий опыт и лучшие практики по созданию крупной фирмы по разработке для использования Subversion в качестве репозитория контроля версий.

Здесь я имею в виду сотни разработчиков / пользователей!

Answer 1

• Выберите правильную структуру каталогов с самого начала - это сука, чтобы изменить позже.
  • Я склонен думать, что «лучшее» организовано проектом, со стволом / тегами / ветвью под каждым проектом
• Каждый человек не нуждается в проверке каждого проекта. Только проверьте, что вам нужно
• Найдите способ поделиться инструментами среди разработчиков. Такие мелочи, как программа SQL diff, которая захватывает с серверов и проверяет их, неоценима.
• Старайтесь не допустить, чтобы какой-либо проект был слишком большим. Попытка обновления или фиксации в папке с 1 ГБ - это очень долго вычислять
• Определите стратегию обновления для сервера Subversion
• Резервное копирование вашего хранилища, конечно - с полной историей изменений
• Trac полезен для непосредственного связывания людей с изменениями и различиями
• Сделать это весело. По выходным запустите поиск по ключевым словам в репо и проследите, как часто люди произносят ругательства в коде. Запустите код роя

Answer 2

Я работал в команде, которая внедрила собственный хостинг Subversion в 3 географических точках, сотнях разработчиков и более 100 проектов. Некоторые ключевые уроки

1. Используйте Apache mod_svn вместо svnserve. Затем вы можете связать «аутентификацию Subversion» с LDAP (или аутентификацией ActiveDirectory), чтобы командам не приходилось запоминать еще одно имя пользователя и пароль.

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

3. Мы разработали простые Python-CGI-сценарии для управления пользователями, разрешениями и сценариями svn-hook для уведомлений по электронной почте и RSS-каналов. Сценарии помогли быстрее принять svn командами проекта.

4. Вы можете установить обратный прокси-сервер и выборочно представить несколько проектов через доступ по протоколу https извне корпоративной сети. Таким образом, внешние группы поставщиков / подрядчиков могут получить контролируемый доступ к проектам.

В целом, мы перевели все проектные команды примерно за один год на новые системы (включая перенос данных из существующих систем, таких как CVS и Visual SourceSafe).

Answer 3

Я полностью согласен с Nitin Bhide. Мои дополнения:

если вы использовали CVS, то некоторые рабочие процессы в SVN очень отличаются, например ветви поставщиков , которых нет в CVS, поскольку вы просто удалили все файлы в поставщике папку и скопируйте новую версию внутри. Это больше не будет работать в SVN.

Также, если вы привыкли к затмению, многое в subversive, как и в subclipse, отличается. Вы должны научить пользователей привыкать к глобальным номерам ревизий, как наиболее трудным для понимания пользователям CVS

Также важна стратегия миграции, позволяющая избежать задержек для команд разработчиков, если миграция их репозитория не удалась

Answer 4

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

Answer 5

Одна фирма, в которой я работал, использовала Subversion для сотен пользователей, которые не имели своих собственных серверов. Вместо этого это была управляемая служба из Collabnet .