Какую систему контроля версий вы бы использовали для более 1000 организаций-разработчиков? Зачем?

Ответ 1

• Для такой огромной установки существуют, по крайней мере, следующие основные требования: Безопасность данных, зрелость, надежность, Масштабируемость, цена ( лицензия на каждое место по сравнению с открытым исходным кодом всегда имеет огромное значение независимо от цены за место), простота администрирования.
• Я бы подумал, что subversion будет просто отлично.
• Доступна поддержка (из collabnet, clearvision, wandisco и другие). Вы можете спросить их, сможет ли subversion справиться с вашей задачей.
• subversion имеет очень зрелую базу данных базы данных - FSFS. Он абсолютно прочный, и с 1,5 года он может обрабатывать действительно много изменений без ухудшения производительности. Изменения написаны в файловой системе. Таким образом, надежность вашего репозитория subversion зависит от качества вашей файловой системы, ОС и системы хранения.
• Вот почему я рекомендовал бы Solaris 10 с ZFS в качестве файловой системы. ZFS имеет отличные возможности файловой системы для производственных систем. Но прежде всего он обеспечивает проверку целостности данных. Таким образом, с таким количеством исходного кода в репозитории subversion вам не придется беспокоиться о повреждении репозитория из-за молчаливой ошибки жесткого диска или ошибки контроллера или бита кабеля. К настоящему времени ZFS достаточно зрелая, что ее можно безопасно использовать в качестве UFS или любой другой замены.
• Я не знаю об аппаратных требованиях. Возможно, Collabnet может дать вам совет.
• Но действительно хороший старт (который может быть использован как хранилище NFS или резервное хранилище, если он окажется слишком медленным - вы, безусловно, сможете его использовать в любом случае) будет вторым поколением thumper, то есть Сервер Sun Fire X4540: вы можете иметь (все в пределах хорошего 4U Rack Server за 80 000 $(цена по списку - это вероятно, будет предметом переговоров): 48 ТБ Дисковое пространство!, 8 ядер AMD Opteron, 64 ГБ оперативной памяти, предустановленная Solaris 10, 3-летняя программная и аппаратная поддержка Platinum от солнца. Таким образом, простая стоимость оборудования и поддержки для этого сервера составит 25 долларов США за место вашего 3000 разработчиков.
• Для обеспечения действительно большой безопасности данных вы можете разбить 48 жестких дисков следующим образом: 3 диска для операционной системы (3-стороннее зеркало Raid-1), 3 горячих резерва (не используется, в режиме ожидания в корпусе сбой других дисков), пул zfs из 14 3-way Raid 1 зеркал (14 * 3 = 42 приводов) для репозитория subversion. Если вы хотите заполнить 14-битное пространство ZFS Raid только на 80%, тогда это будет приблизительно 10 Tebibyte реального полезного дискового пространства для репозитория, то есть в среднем 3 ГБ на разработчика.
• С этой конфигурацией: Subversion 1.6 на Sun x4540 thumper с 10 TiB 3-way Raid-1 ZFS избыточным и контролируемым дисковым пространством это должно быть действительно серьезное начало.
• Если для более 3000 разработчиков недостаточно вычислительной мощности, вы можете купить более сильный сервер, который мог бы использовать дисковое пространство thumper. Если производительность диска слишком низкая, вы можете подключить огромный массив быстрых дисков scsi к вычислительному серверу и использовать thumper в качестве резервного решения.
• Конечно, имеет смысл получить консультационные услуги от collabnet относительно планирования и развертывания этого сервера subversion и получить платиновую поддержку для аппаратного обеспечения и операционной системы Solaris от солнца.
• Изменить (ответ на комментарий # 1): для распределенных команд существует возможность конфигурации ведущего-подчиненного: WebDAV-Proxy, Каждая локальная команда имеет подчиненный сервер, который реплицирует репозиторий. Разработчики получают все проверки от этого подчиненного. Проверки передаются прозрачно от подчиненного устройства к мастеру. Таким образом, мастер всегда является текущим. Подавляющее большинство трафика - это проверки: каждый разработчик получает каждую проверку, которую совершает любой разработчик. Таким образом, трафик проверки должен составлять 99,97% трафика с 3000 разработчиков. Если у вас есть местная команда с 50 разработчиками, трафик проверки будет уменьшен на 98%. Проверка не должна быть проблемой: как быстро кто-нибудь может ввести новый код? Очевидно, что для небольшой команды вы не будете покупать thumper. Вам просто нужен ящик с достаточным объемом жесткого диска (т.е. Если вы намерены хранить репозиторий дыр 10TB). Это может быть конфигурация raid5, поскольку потеря данных - это не конец компании. Вам также не понадобится Solaris. Вы могли бы поставить на него Linux, если локальные жители будут более комфортно с ним. Опять же: спросите консультанта, как collabnet, если это действительно звуковая концепция. С этим много мест не должно быть проблемой платить за разовую консультацию. Они могут создать все это. Sun доставляет коробку с предустановленной солнечной батареей. У вас есть поддержка солнца. Таким образом, вам не нужен гуру солярки на месте, так как конфигурация не должна меняться в течение следующих лет. Эта конфигурация означает, что
  • медленная линия от команды до штаб-квартиры не будет забита избыточными данными проверки и
  • члены местной команды могут быстро получить свои выписки.
  • это резко снизит нагрузку на thumper - это означает, что с этой конфигурацией вам не нужно вообще беспокоиться, способен ли thumper обрабатывать нагрузку
  • это снижает затраты на пропускную способность.
• Изменить (после выпуска M3000): гораздо более экстремальная аппаратная конфигурация, нацеленная еще больше на безумную целостность данных, будет комбинацией M3000 и J4500 массив:
  • J4500 Storage Array представляет собой практически бесшумный, но без интерфейсов центрального процессора и внешнего хранилища, который позволяет подключаться к серверу.
  • Сервер M3000 - это сервер Sparc64 по средней цене с высокоскоростными функциями RAS. Большинство каналов данных и даже регистры процессора имеют контрольную сумму и т.д. ОЗУ не только защищена ECC, но и имеет эквивалент функции IBM Chipkill: она осуществляет рейд по памяти: не только обнаружены и исправлены ошибки только одного бита, но и все чипы памяти могут не работать полностью, в то время как данные не теряются - подобно сбоям жестких дисков в RAID-массивах.
  • Так как файловая система ZFS выполняет проверку ошибок на основе ЦП на данных до того, как она поступит, или после того, как она поступит в ЦП, качество контроллера хранения и кабели J4500 не имеет значения. Важно то, что функции предотвращения и обнаружения ошибок бит процессора M3000, памяти, контроллера памяти и т.д.
  • Неудивительно, что высокое качество палочек для карт памяти, используемое для повышения качества, еще более дорогое, что комбинация четырех основных (восемь потоков) 4 ГБ Ram M3000 + 48 ТБ J4500 будет примерно эквивалентна thumper, но если вы хотите увеличить память сервера с 4 до 8, 16 или 32 ГБ для целей кэширования в памяти, цена резко возрастает. Но, возможно, конфигурации 4 ГБ будет даже достаточно, если используется конфигурация master-slave для распределенных команд.
  • Эта аппаратная комбинация заслуживает внимания, если исходный код и целостность данных этого 3000-хранилища-разработчика будут оценены чрезвычайно высокому руководству. Тогда было бы также целесообразно добавить два или более Thumpers в качестве вращающегося решения для резервного копирования (не обязательно для защиты от отказа оборудования, но для защиты от ошибок администратора или для резервных копий за пределами площадки в случае физических desasters).
  • Поскольку это будет решение Sparc, а не x86, для этой платформы доступны свободно Collabnet Subversion двоичные файлы.
• Одним из преимуществ подрывной деятельности является также отличная документация: есть отличная книга из O'Reilly (Управление версиями с Subversion) также можно бесплатно скачать как PDF или HTML версия.
• Подводя итог: с использованием комбинации Subversion 1.6 + Solaris 10 + 3-way-raid-1 и контрольной суммы ZFS + thumper + репликации сервера-хозяина для локальных команд + поддержка sun + collabnet/clearvision/orcaware/Karl Vogel consulting + отличное и бесплатное руководство по подрывной деятельности для всех разработчиков, у вас должно быть решение, которое обеспечивает
  • Чрезвычайно высокая безопасность данных (очень важно для большого количества исходного кода - вы не хотите испортить свой репозиторий, ошибки в битах происходят, жесткие диски не работают!) У вас есть один репозиторий основных данных, который действительно поддерживает все ваши версии/ревизии: Главная особенность систем управления версиями.
  • Зрелость. Subversion использовалась многими, многими компаниями и проектами с открытым исходным кодом.
  • Масштабируемость. При репликации master-slave у вас не должно быть проблем с нагрузкой на главном сервере: загрузка проверок незначительна. Осмотр осуществляется ведомыми устройствами.
  • Отсутствие высокой задержки для локальных команд за медленными соединениями (из-за репликации)
  • Низкая цена: подрывная деятельность бесплатна (без платы за место), отличная бесплатная документация, за трехлетний период всего 8 долларов США за место в год за аппаратное и вспомогательное обслуживание для главного сервера, дешево linux для ведомых, одноразовая консультация от collabnet et. al., низкая стоимость полосы пропускания из-за репликации master-slave.
  • Простота администрирования: По существу, администрирование главного сервера отсутствует. Консультант subversion может развернуть все. Сотрудники Sun будут заменять неисправные жесткие диски и т.д. Подчиненными могут быть ящики Linux или любые административные навыки, доступные на локальных сайтах. Отличная документация по подрывной деятельности.

Ответ 2

Проработав в нескольких компаниях с более 1000 работников, я обнаружил, что по большому счету все они используют Perforce.

Я спросил: "Почему бы вам не использовать что-то еще? SVN? Git? Mercurial? Darcs?" - и они сказали, что (это то же самое для всех компаний) - когда они сделали решение пойти с Perforce, это было либо то, либо SourceSafe, либо CVS - и, честно говоря, учитывая эти три варианта, я тоже поеду с Perforce.

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

Perforce имеет множество API-интерфейсов для разработчиков, и для централизованной системы у него много chutzpah.

Я не говорю, что это лучшее решение, но я, по крайней мере, видел некоторые очень крупные компании, в которых работает Perforce, и достаточно хорошо, что это почти повсеместно.

Ответ 3

Git был написан для ядра Linux, что может быть самым близким примером для такой ситуации, на которую вы можете найти общедоступную информацию.

Ответ 4

Я хочу сказать git, но не думаю, что компания такого размера будет всем Linux (поддержка Windows для git все еще отстой). Поэтому перейдите к SCM, который использовался Linux до git i.e. BitKeeper

Ответ 5

К 2015 году наиболее важным фактором является использование системы управления распределенной версией (DVCS). Основное преимущество использования DVCS: возможность совместной работы с исходным кодом на многих уровнях за счет уменьшения трения манипуляции с исходным кодом. Это особенно важно для 1000+ разработчиков.

Уменьшение трения

Индивидуальные проверки разработчиков отделены от действий совместной работы. Легкие проверки стимулируют чистые единицы самостоятельной работы в короткие сроки (много проверок в час или в день). Сотрудничество, естественно, обрабатывается в другом, обычно более длинном, временном масштабе (синхронизация с другими ежедневно, еженедельно, ежемесячно), поскольку система создается в распределенной организации.

Используйте Git

Из параметров DVCS вам скорее всего следует использовать Git и воспользоваться преимуществами больших сообществ в GitHub или Bitbucket. Для крупных частных организаций важным может быть внутренний хостинг и внутренний хостинг исходного кода (есть поставщики, продающие частные системы хостинга, такие как Atlassian Stash и, возможно, другие).

Основной причиной использования Git является то, что это самый популярный DVCS. Из-за этого:

• Git хорошо интегрирован в широкий диапазон программных цепочек разработки

• Git известен и используется большинством разработчиков

• Git хорошо документировано

Или Mercurial

В качестве альтернативы Git, Mercurial тоже очень хорошо. Mercurial имеет несколько более чистый, более ортогональный набор команд, чем Git. В конце 2000-х годов он был лучше поддержан, чем Git для систем Windows, главным образом из-за наличия основных разработчиков, которые больше заботились о Windows.

GUI

Для тех, кто хочет использовать графический интерфейс вместо git и hg в командной строке, SourceTree отличное приложение Windows и OS X, которое представляет собой чистый интерфейс как для Git, так и для Mercurial.

Устаревшие рекомендации

По состоянию на 2010 год я рекомендовал Mercurial с TortoiseHG. Это лучшая комбинация функций поддержки Windows и распределенной версии.

В 2006-2009 годах я рекомендовал Subversion (SVN), потому что он бесплатный и имеет большую интеграцию с большинством IDE. Для тех, кто путешествует или предпочитает более распределенную модель, они могут использовать Git для всех своих локальных работ, но по-прежнему фиксировать репозиторий SVN, когда они хотят использовать код. Это отличный баланс между централизованной и распределенной системой. Для начала ознакомьтесь с Git -SVN Crash Course. Последней и, возможно, самой важной причиной использования SVN является TortoiseSVN, клиент Windows для SVN, который делает доступ к репозиториям щелчком правой кнопки мыши для кто угодно. В моей компании это доказало отличный способ предоставить доступ к репозиторию для не-разработчиков.

Ответ 6

Во-первых, большой НЕТ по CVS. Использование CVS в 2008 году походит на вождение 92 Isuzu Trooper. Единственная причина, по которой они находятся на дороге, и что люди тратят деньги на их содержание, - это чисто сентиментальные причины. CVS - старая шляпа, технологически, и вы пожалеете об этом.

Я бы вообще удалился от инструментов с открытым исходным кодом в таком размере компании. Subversion - отличный инструмент и довольно прочный, но, несмотря на то, что вы спускаетесь вниз или сталкиваетесь с ошибкой, о которой вы не знали, бремя ответственности за то, что вы исправили ее, в то время как 3000 человек сидят без дела. Perforce дешево, если поставить в этой перспективе, и я очень рекомендую его.

Меня удивляет, сколько людей, которые претендуют на роль профессионалов SCM, идут со "свободными". На первый взгляд он отлично подходит для управления, но когда вы находитесь под пистолетом, это помогает создать высококачественную группу поддержки на вашей стороне. Когда вы проснетесь в 3 часа ночи в воскресенье, потому что ваша команда в Сингапуре не может выполнять какую-либо работу, вы не будете думать, что "свободен" был хорошей идеей.

Инструменты управления источником являются критически важными, вы говорите об активах компании и интеллектуальной собственности. Не экономьте на инструментах управления версиями, никогда!

Ответ 7

Любые DVCS (BitKeeper, git, Bazaar, Mercurial и т.д.), потому что распределение будет сокращать нагрузку на центральный "канонический" SCM-сервер. Опасность заключается в том, что они довольно новые технологии, и не многие люди будут знакомы с их использованием.

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

Ответ 8

Не используйте CVS! Если вам нужна модель CVS, Subversion является гораздо лучшей альтернативой.

Ответ 9

Хорошо, прямое выражение об отказе от ответственности: я являюсь разработчиком для компании под названием MKS, которая делает систему контроля версий для "enterprise" компаний как часть платформы управления конфигурацией программного обеспечения, называемой Integrity. Бла-бла-бла, очевидный штепсель.

Поэтому я не могу честно ответить на вопрос.

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

Компания с 1000+ разработчиков хочет знать, что все делают то, что они должны делать, и что никто не делает то, что они не должны делать, все отслеживается, а менеджеры получают прекрасные отчеты и графики, которые они могут вставить в слайды PowerPoint для своих менеджеров.

Если крупная компания не особенно заботится об этих вещах, они с большей вероятностью оставят ее перед отдельными командами разработчиков, чтобы выяснить их собственную вещь, и в этом случае 1000+ разработчиков используют hodge-podge различных инструментов, основанных на том, что казалось наиболее удобным в то время.

Ответ 10

Резюме: из систем, с которыми я имел личный опыт работы с git, справится с этим лучше.

Подробнее:

Я работал в нескольких крупных компаниях с большим количеством разработчиков. На предыдущем задании (я бы догадался около 500 разработчиков) мы использовали (из-за эпохи) RCS и CVS. Другая группа также использовала ClearCase. У группы ClearCase были серьезные проблемы, но я никогда не знал, было ли это из-за ClearCase или неправильного использования какой бы то ни было методологии ClearCase, или плохого администратора администрации ClearCase.

В компании, с которой я сейчас работаю (более 10000 разработчиков, но я сомневаюсь, что более 1000 человек относятся к тому, что большинство людей будет рассматривать как единый проект, хотя они ИМЕЮТ, что многие из одного продукта), мы использовали CVS (по историческим причинам), SVN (потому что это был простой путь миграции), SVK (хорошо в то время, но я бы не рекомендовал его), Mercurial (извините, никакого прямого опыта), Perforce (ditto), и Git.

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

SVN стабилен и зрелый, а ветвление - путь быстрее, чем CVS (секунды не минуты для большого проекта). Однако слияние этих ветвей по-прежнему немного примитивно (в простых случаях небольшая оболочка script может сделать ее довольно простой, но если ветвь обновилась, а материал потянул, что также было совершено в другом месте, ее очень сложно управлять). Источникам-источникам SVN также, кажется, нужно больше заботиться и кормить, чем любые другие репозитории с открытым исходным кодом (но, тем не менее, коммерческие они, похоже, берут). SVN имеет приятную простую концептуальную модель.

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

SVK работал намного лучше для наших "медленных сайтов" (и позволил значительно больше "отделить работу" ). Он также работал намного лучше для сложных слияний, чем SVN. SVK больше не поддерживается, иначе я бы рекомендовал его.

Git относительно молод для огромного предприятия, которое серьезно рассматривает, но в стороне...

Это хорошая работа, но имеет довольно крутую кривую обучения. Тем более для групп, которые уже используют централизованную систему управления источниками. Одна вещь, которая помогает здесь, - формализовать такие вещи, как "X - это авторитарное репо для проекта Y", и взять все ваши старые процессы обзора и т.д. И применить их к этому репо (если вам понадобится обзор кода из R и выключение что тесты T передаются перед проверкой в ​​вашей старой соединительной линии системы управления версиями, требуют тех же вещей, прежде чем совершать фиксацию в авторитетной ветке главного сервера репо.)

В некотором роде git на самом деле работает лучше для больших групп, тогда как SVN. Вы можете обеспечить соблюдение процесса, имея лишь небольшое число людей, способных совершить любое репо, которое вы обозначили как авторитетное. Эти люди могут нести ответственность за то, чтобы все "процессы" были соблюдены, прежде чем они вносят изменения в репо. git будет даже следить за тем, кто внес изменения в сравнении с тем, кто их интегрировал (что-то похожее на то, что SVN часто ошибается).

Git делает его еще более дешевым, чем SVN, для создания ветвей (вы можете отключить его, и это меньше секунды или, возможно, 3 секунды на SVN), но в то время как большинство людей утверждают, что это огромная сделка "т. Большое дело в том, что слияния очень легки. Даже в тех случаях, когда вы делали такие вещи, как начатый филиал, выполнявший половину работы, приходилось работать над чем-то еще месяц, обновлять источник в своем филиале, потому что другие люди изменили базовый проект в течение месяца, а затем сделали второй половина работы, отвлеклась, должна была вернуться позже, выяснила, что была 3-я половина работы, больше внешних обновлений и т.д....... даже после того, как слияние выяснило, что на самом деле было ново в вашей отрасли vs. пришли из ваших обновлений и сохранили количество вещей, которые действительно нуждаются в слиянии с минимумом.

Есть много вещей, которые мне не нравятся в git, но они почти все сводятся к" некоторым инструментам острым, и вы должны быть осторожны ". Такие вещи, как много операций, которые не существуют в таких вещах, как SVN, должны выполняться только в коммитах, которые существуют только в вашем репозитории (не редактируйте историю, которую видели другие!). Другие системы управления версиями имеют схожие проблемы, но git уделяет больше внимания редактированию истории, чтобы сохранить ее" чистой", поэтому есть больше инструментов и опций для инструментов, которые вам нужно либо игнорировать, либо знать, когда это безопасно, катастрофа. В балансе я считаю, что он превосходит другие системы управления версиями, которые я использовал.

Моя информация из вторых рук о Perforce - "это лучше, чем SVN, а не какая-то". Моя вторая информация о Mercurial о том, что "она более или менее похожа на git, за исключением деталей, некоторым это нравится другим, например, git more".

В корпорации с более 1000 разработчиков я бы рекомендовал вам получить контракт на поддержку любой системы управления версиями, которую вы используете. Для git я бы посмотрел на github: fi.

Ответ 11

Я бы использовал любой SCM, у которого нет пессимистической блокировки (http://old.davidtanzer.net/?q=node/118). Тем более, что вы хотите, чтобы люди могли "редактировать" один и тот же файл одновременно в любом значимом проекте.

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

Другие варианты могут включать в себя "git", которые используют ядро ​​Linux, но на самом деле у меня нет никакого опыта.

Ответ 12

Если у вас такая большая организация, тогда не задайте ни одного конкретного SCM.

Я уверен, что они не все работают над одним и тем же кодом, и было бы неплохо позволить самим командам выбирать, с чем они наиболее удобны.

(Возможно, вам потребуется провести некоторую подготовку, чтобы понять, как выбирать между Git, SVN, некоторой внутренней системой устаревания.)

Ответ 13

неволей

То, что мне нравится в perforce, говорит по сравнению с CVS, заключается в том, что управление филиалом должно быть более сложным (но все же достаточно простым), и вам не нужно бить центральную бюрократию для создания веток/ярлыков и т.п. Другими словами, он позволяет отдельной команде (или разработчику) управлять своими исходными компонентами, как им нравится, перед тем, как отправить на основную линию, находящуюся в центре управления кем-то другим.

О, я бы также сказал, что у него есть один из лучших графических интерфейсов, хотя он все еще имеет интерфейс командной строки для граждан первого класса. Я обычно ненавижу GUI, но их работа работает.

Ответ 14

Я бы использовал биткипер. Я использовал bitkeeper, clearcase, accurev, perforce, subversion, cvs, sccs и rcs, и из всех этих биткиперов был далеко и выше лучших. Я играл с git и был впечатлен его скоростью, но я думал, что его пользовательский интерфейс был немного громоздким (хотя это мнение было сформировано только после его использования на пару полдня).

bitkeeper имеет довольно неуклюжий вид GUI, но они исключительно функциональны. Инструменты командной строки bitkeeper, возможно, являются лучшими в своем роде, и его возможности слияния были абсолютно фантастическими.

То, что мне больше всего понравилось в bitkeeper (и это, вероятно, относится ко всем распределенным системам), заключается в том, что ветки были грязными. Создание ветвей было способом жизни, а не чем-то бояться.

Ответ 15

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

Microsoft Team Foundation Server используется в Microsoft в некоторых очень больших командах, и команда TFS работает над тем, чтобы сделать ее масштабируемой. Кроме того, интеграция контроля источника и отслеживания ошибок привлекательна. Это не дешево, и администрации достаточно хлопот, что он не масштабируется хорошо для небольших команд, но для вашей ситуации вы можете позволить себе эти расходы. Вероятно, вы также захотите позвонить в крупную организацию поддержки, например, Microsoft, когда у вас возникают проблемы (но если вы идете со свободным программным обеспечением, то у вас есть возможность сделать эту поддержку самостоятельно).

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

Ответ 16

Я бы использовал AccuRev. Я использовал svn, cvs, clearcase (base, ucm), ccc/harvest, но ни один из них не может бить силы AccuRev. "3000+ организация-разработчик с несколькими сайтами"? вы можете использовать распределенное решение Accurev (AccuReplica) для этого - что означает, что у вас есть один главный сервер и столько, сколько хотите реплик на удаленных сайтах (так что те, у кого есть "медленная ссылка", не будут сильно страдать)

Прежде всего AccuRev предлагает уникальный подход - поистине новую концепцию/проектирование/реализацию инструмента SCM, основанного на потоках. Не в (плохой) способ ClearCase-UCM сделал это (потому что потоки ClearCase "в конечном счете были ветвями" ), но по-современному.

Лучше всего попробовать, я знаю, что они предлагают пробную версию за 30 дней с достаточным количеством лицензий для игры с инструментом - попробуйте, и вы не захотите рассмотреть другие инструменты. Мое обещание.

Ответ 17

Я сомневаюсь, что у вас есть 3000 разработчиков в вашей организации, работающих на одной и той же базе кода. Я работаю в компании среднего размера, и у нас, вероятно, не так много во всей компании, но есть также много независимых проектов.

Внутренне некоторые группы доставляют выпуски другим группам для использования в своих продуктах; это не управляется через систему SCM.

Наша собственная группа имеет собственный SCM, но есть только около 25 активных разработчиков. Мы используем CVS, и, честно говоря, это не совсем так (мы бы переносили, но у меня было много скриптов/фиксаций и других битов и фрагментов, которые нуждаются в большой работе для изменения). Проблема с использованием CVS на базе кода разумного размера заключается в том, что многие операции выполняются очень медленно и включают блокировку других разработчиков.

Ответ 18

Я в ужасе, что большинство людей, выступающих здесь за DCVS, воспринимаются как некие фанаты. DCVS-es отображаются как еще одно модное слово, как говорят облачные вычисления, социальные сети и т.д.

Некоторые люди здесь выступают за использование SVN вместе с определенной аппаратной настройкой, конкретным дисковым хранилищем, которое предполагается (или даже способно) обеспечить надежность таблицы. Теперь не это просто побеждает одну из двух основных целей SCM - а именно обеспечение целостности данных?

У вас недостаточно информации об уровне хранения данных, чтобы обеспечить целостность всей исходной базы во всех предыдущих версиях. Что делать, если вы хотите перенести данные на другую машину? Что делать, если вы хотите постепенно его перенести, не останавливая все разработки до тех пор, пока это не закончится? Что делать, если есть проблема с безопасностью, и кто-то испортил вашу основную копию? Как вы находите последний действительный? Целостность хранилища доводит вас до такой степени и не даст вам никаких средств для решения каких-либо из этих проблем. Это происходит именно потому, что он работает на неудовлетворительном уровне абстракции. Разве это не ваше хранилище. Это ваша база кода.

Другая проблема. Некоторые люди не могут поверить, что на самом деле возможно, чтобы более 3000 человек работали в одном проекте. Они говорят: "Иди и испеки свой собственный scm", который, я думаю, является еще одним способом формулировки "да... правильно... 3000+ разработчиков... удачи в этом". В то же время есть проекты, в которых задействовано гораздо больше людей. Возьмите практически все, от инженерного до закона. Но почему-то, когда дело доходит до разработки программного обеспечения, это невозможно, этого не может быть. Мысль (я думаю) выглядит примерно так: Что? 3000+ людей касаются одного и того же файла? Теперь этого не может быть. И, да, это правильно. Этого не может быть. Вопрос в том, почему вы позволили бы 3000+ людям касаться одного и того же файла? Где в природе вы когда-нибудь находите такую ​​ситуацию? Разве 3000 + адвокаты посылают друг другу один документ, пока они со временем не согласятся на все? Люди не работают так. В действительности так нельзя работать. Однако централизованное CVS теоретически позволяет. Хуже того, это заставляет людей фактически координировать свою работу с людьми, которых они даже не знают. В такой ситуации даже не проблема умных людей на борту, хотя из тысяч людей я представляю себе довольно трудно гарантировать, что каждый из них не идиот. Это просто о том, чтобы делать общие глупые ошибки. Все совершают ошибки (буквально). Почему вы вдруг хотели бы сообщить об этом всей компании?

Теперь некоторые могут сказать - но вам не нужно давать доступ для всех. Ну, это мошенничество. Это абсолютно безнадежная попытка построить распределенный рабочий поток в централизованной среде. Внезапно у вас есть дерево с двумя уровнями - люди с доступом к фиксации отправляют работу всем тем, кто этого не делает. Хорошо, если вы зашли так далеко, почему бы просто не согласиться с неизбежным - что нет и никогда не будет просто единой общей версией всей исходной базы. То, что люди должны работать в своих средах, которые могут быть легко объединены.

В наши дни много DCVS. Только Git использует этот подход для отслеживания контента, а не отдельных файлов, что в данном случае может оказаться не оптимальным выбором (однако это очень зависит от организации проекта). Существует также Mercurial, есть базар. Таким образом, оба свойства не зависят друг от друга.

Я действительно не хочу рекомендовать какие-либо конкретные DCVS там, я не чувствую себя компетентным. Однако в ситуации, когда большинство рекомендуемых решений не распределены, не гарантируйте целостность данных, на самом деле хуже, чем отсутствие CVS вообще, я чувствовал, что мне нужно что-то написать. Вопрос действительно в том, какой DCVS лучше всего подходит для выполнения задания.

Ответ 19

Adobe использует Perforce

Ответ 20

Perforce - достойная система и хорошо масштабируется.

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

Кроме того, он имеет хорошую поддержку для окон, mac и unix, включая хорошей командной строки и имеет хорошую поддержку script.

Я использовал CVS раньше, и он недостаточно масштабируется для групп, больших, чем около 25-50 инженеров (в основном из-за атомных операций и производительности)

Ответ 21

Если вы имеете в виду более 3000 разработчиков, работающих на одной и той же базе кода, я не знаю. Если вы имеете в виду работу над несколькими сотнями проектов в разных местах, и у вас должен быть стандарт, я бы пошел на то, что популярно с массовой поддержкой онлайн-пользователей, а не с чем-то неясным, что дает вам 10 хитов в Google.

Лично я бы согласился на SVN, я на IT-депе с несколькими сотнями разработчиков, а предпочтительным приложением для управления версиями является SVN.

:)

//W

Ответ 22

Я бы действительно просмотрел Team Foundation Server. Это очень хорошая система, которая может масштабироваться, и, вероятно, легко пройти через внутренние отделы. Я знаю, что это ОС Windows, но вы также можете использовать надстройки для Linux/Mac, и вы можете использовать прокси для некоторых сайтов с медленными соединениями.

И я подумал бы о наличии двух систем в крупной организации, это может помочь получить лучшее в некоторых отдельных случаях.

Ответ 23

Perforce и TFS - единственные варианты, о которых я знаю. Я знаю, что оба они были использованы в крупных проектах в Microsoft. Vault может масштабироваться так сильно, но я не знаю, выходит ли он за пределы 500-1000 пользователей.

Ответ 24

Perforce доказал свою масштабируемость до 5000+ пользователей на одном сервере в Google, см. Life on the Edge: мониторинг и запуск очень большой установки Perforce

Казалось бы, многие крупнейшие компании-разработчики программного обеспечения используют Perforce исключительно или как основной SCM. Например: Adobe, Cisco, SAP, Symantec, EA, UbiSoft и Autodesk - все пользователи Perforce. Он не идеален, но он по-прежнему превосходит SVN или TFS (ни один из них не является плохим в своем собственном праве).

Ответ 25

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

[слух] Я слышал, что Microsoft использовала его для Vista. [/rumor] По-видимому, для них это была настроенная версия, но она не намного больше.

Ответ 26

Посмотрите варианты.

1 - Perforce. Используется многими компаниями (как говорят люди) Adobe, Amazon, MS, Google Компании, которые росли, продвигались и зависели от продажи программного обеспечения каждый день, чтобы положить еду на стол, что их выбор. Я предполагаю, что я бы пошел, если бы мне понадобилось поддерживаемое "глобальное решение" для множества сайтов и т.д. Хорошо для Win/Linux (не уверен в Mac OS)

2 - SVN. Используемый большими командами также, KDE использует его (огромный, огромный проект), который в настоящее время находится в редакции 880 000 (да!) Очень практично как для Windows, так и для Linux (хотя я бы назвал TortoiseSVN ниже среднего по некоторым аспектам) Коммерческая поддержка может быть сокращена также. Хорошо для Windows/Linux/Mac.

3 - Accurev Если бы я пытался быть "острым". Я бы не разворачивал его на всей компании без какого-либо тестирования и привык к этому.

4 - MS Team Foundation Это может быть хорошим решением, но я никогда не пробовал и, вероятно, только Windows.

5 - Git/Bzr/Hg - Bzr и Hg имеют свои "черепахи", поэтому хорошо для Windows (хотя я не уверен в зрелости) Git будет linux только пока, даже хотя это ОЧЕНЬ ХОРОШЕ (и намного лучше и проще в использовании, чем пару лет назад).

Я НИКОГДА, КОГДА-ЛИБО, АБСОЛЮТНО НЕ ПУТЬ JOSE используют Clearcase. ПЕРИОД Это пустая трата всех денег, времени и здравомыслия.

Удаляйтесь от: CVS/Clearcase/ничего более старого

Ответ 27

Если все работают над одним и тем же продуктом, возможно, Perforce.

Если существует много небольших проектов (от 2 до 50), я бы запустил несколько блоков Subversion (SVN).

Ответ 28

Subversion легко масштабируется и разбивается. Perforce стоит тысячи долларов только для небольшого количества сотрудников, дороги к дорогим, и кроме того, он не предлагает ничего, что подрывная деятельность не предлагает.

Subversion действительно легко, лучше, чем cvs.

Я бы рекомендовал git, если бы только поддержка их окон была лучше

Ответ 29

в нашей компании мы используем alienbrain, но мы переходим к Perforce. У Perforce есть все, что вы хотите: он имеет код и данные, он интегрирует инструменты для непрерывной интеграции, он обрабатывает локальный реестр (для каждого разработчика), чтобы вы могли регистрироваться в своем локальном репозитории, прежде чем совершать на сервере.

Я проголосовал за Perforce

Ответ 30

SVN с TortiseSVN (в Windows) превосходна. Я очень рекомендую его.