Большие команды разработчиков и SVN - PullRequest
Новая
       15

Большие команды разработчиков и SVN

3 голосов
/ 14 октября 2010

Несколько вопросов по этой теме:

1) Какую самую большую группу разработчиков (выполняющую реальные коммиты, не считая только для чтения) вы имели в одном SVN-репозитории?Были ли у вас какие-либо проблемы?

2) Какую команду наибольшего размера вам было бы удобно в одном SVN-репозитории?Является ли другой инструмент контроля версий лучше для очень больших команд?(Не называйте IBM Rational, потому что он будет проигнорирован и воспламенен, но другие могут быть возможны, если будет сделано обоснованное обоснование. Совместимость с Solid Eclipse и Flex / Flash Builder IDE является обязательной.)

2aОчевидно, что это зависит от проекта, но есть ли серьезные недостатки, связанные с разделением «больших» команд разработчиков на маленькие модульные команды , которые используют свои собственные репозитории SVN ?

3) Имеет ли смысл для организации иметь два стандартных инструмента управления версиями, один для больших систем (при необходимости) и один для небольших (~ 5 разработчиков или менее) систем?

Для дополнительных баллов:
4) Что бы вы назвали «большой» командой (считая только разработчиков , поскольку это относится к использованию SVN, не QA, управлению, тестировщикам и т. Д.)?

Ответы [ 2 ]

3 голосов
/ 14 октября 2010

Я работал над SVN-репозиторием, в котором было более ста активных коммиттеров, номер ревизии более 80.000, и был перенесен из CVS 3 года назад.

ОбычноЯ бы сказал, что SVN является , а не вероятным узким местом, когда речь идет о крупных проектах и ​​больших командах разработчиков.Конечно, в нем могут отсутствовать некоторые функции, которые могли бы упростить некоторые аспекты, но это совершенно несущественно по сравнению с организационными проблемами.

3 голосов
/ 14 октября 2010

1 / Многие из наших репо используют от 50 до 100 разработчиков в течение многих лет.
Проблемы тогда:

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

2 / Центральная VCS обычно не имеет специальных ограничений в отношении стороны хранилища.
Большие команды оценивают Производят , очень быстро оформляют свои рабочие места.

2a / Как вы говорите, это зависит от проекта. Для настоящего монолитного проекта с множеством взаимозависимых частей основным недостатком является синхронизация контента, которую необходимо выполнить между репо (вы не можете обновить модуль, не влияя на другие).

3 / Конечно, это то, что мы имеем.

  • Обычно зарезервированный для больших проектов не является бесплатным (особенно потому, что менеджерам необходимо знать, что существует реальная группа поддержки продуктов VCS, на которую они могут положиться в случае серьезных проблем с этим инструментом).
  • для небольшого проекта достаточно VCS с открытым исходным кодом (бесплатная).

Но SVN по-прежнему может управлять обоими размерами проекта, будучи «свободным» (вам все равно придется платить за администратора и за инфраструктуру - сервер, диск, резервные копии, ... - для запуска любого инструмента, бесплатного или нет) .

4 / Любая команда, которая превышает (в среднем) 15 человек, может разрабатывать разные части приложения с разной скоростью. Это становится модульной разработкой и требует тщательного структурирования репозитория SVN.

...