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

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

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

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

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

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

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


eclipse svn flexbuilder flash-builder
person Manius    schedule 14.10.2010    source источник
comment
Назовите меня сумасшедшим, но я не вижу проблемы с IBM Rational. Может ли кто-нибудь показать мне ссылку на любой из этих противоречий?   -  person rahmu    schedule 10.11.2011
comment
Сколько IBM платит тебе, раму?   -  person Manius    schedule 11.11.2011

Ответы (2)


arrow_upward
3
arrow_downward

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

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

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

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

3 / Конечно, что у нас есть.

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

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

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

person VonC    schedule 14.10.2010
comment
Какие специальные символы использовались или что вы подразумеваете под «неправильным соглашением об именах»? - person Manius; 15.10.2010
comment
@Crusader: '~ # é è () ... любые символы в именах файлов, которые действительно усложняют дамп svnadmin. - person VonC; 15.10.2010
comment
Не должно быть проблемой, если - или _ не попадают в эту категорию. Бывший. some-application_module1 или что-то в этом роде. - person Manius; 16.10.2010
comment
@Crusader: ты прав, тогда у тебя не должно быть таких проблем. - person VonC; 16.10.2010

arrow_upward
3
arrow_downward

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

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

person Michael Borgwardt    schedule 14.10.2010
comment
Спасибо за эту потрясающую «статистику». Низкозатратный OSS: 1 Раздутое ПО с завышенной ценой-IBM-кухня-раковина-мусор: 0 - person Manius; 22.12.2010
comment
Странный поврежденный комментарий выше, должен сказать, что Low-Cost-OSS «больше, чем» Overpriced-bloatware-IBM-kitchen-раковина-мусор. - person Manius; 11.11.2011