Почему крупные компании используют Perforce? [закрыто]

Я слышал о некоторых крупных компаниях, например, Google, Facebook используют Perforce

Есть ли причина, по которой SVN / Git не может заменить Perforce?

Обоснование, возможно, менее актуально, чем когда-то, но Perforce имеет тенденцию работать лучше в больших репозиториях, чем Subversion. Это одна из причин, по которой Microsoft приобрела исходную лицензию для Perforce для создания Source Depot; Репозиторий NT - чудовище, и не многие продукты, коммерческие или иные, могут справиться с этим.

Кроме того, по крайней мере, в одно время визуальные инструменты для Perforce были намного лучше, чем доступные из коробки (так сказать) из Subversion или Git. Если вы используете Meld, возможно, эти вещи значат меньше, чем когда-то, но есть еще несколько вещей, которые Perforce сделала очень хорошо, включая визуализации ветвления и слияния, которые, хотя у меня нет подробной памяти о том, как это было Прошло около 3 лет с тех пор, как я в последний раз прикасался к Perforce, и это казалось более изощренным, чем, например, подход Github к этому.

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

Большинство проектов, над которыми я работал за пределами Microsoft, могут быть достаточно хорошо реализованы Git, Mercurial или Subversion, и я бы сказал, что большинство компаний, для которых я работал, использовали один из этих вариантов. Но есть и приятное место, обычно это сочетание размера хранилища, модели ветвления и слияния, а также опыта / истории команды, которая заставляет людей использовать коммерческие инструменты. Например, я редко видел большие репозитории Git. Это не может быть связано с какими-либо внутренними ограничениями Git; Я допускаю полное неведение этого. Но в некоторых проектах (например, Windows NT) могут быть некоторые практические ограничения для бесплатных решений.

Я достаточно опытен в svn, git и Perforce, как в качестве пользователя, так и в настройке и обслуживании серверов.

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

• Насколько это соответствует вашей модели разработки?
• Насколько легко разработчикам изучать и использовать?
• Быстро ли выполняются рутинные операции для разработчиков?
• Является ли процесс использования этого отвлечением от их реальной работы, которая заключается в написании кода?
• Насколько легко настроить и поддерживать?
• Сколько стоит покупка и обслуживание?
• Если вам нужна помощь, насколько легко ее получить?

Я собираюсь пропустить подробности о плюсах и минусах отдельных систем. Достаточно сказать, что когда я в прошлом году вернулся к очному консультированию, я пересмотрел все три, чтобы решить, что позволит мне максимально быстро заработать, поставляя качественное программное обеспечение своим клиентам и не требуя много неоплачиваемой работы. дурачиться. Когда я взял политическое соображение «FOSS - это хорошо, а не FOSS - это зло» из уравнения, я в итоге отказался от лицензии Perforce.

И именно поэтому крупные компании выбирают Perforce тоже.

Вот подробности tl: dr из комментариев, плюс немного больше.

Обращаться к SVN легко: по сравнению с Perforce, это очень медленно. Я работал в компании, которая занималась внедрением Linux для мобильных телефонов, и наши полные источники занимали 9 ГБ; они использовали Perforce. Как только вы получили код, обновление последних источников обычно занимало секунды в локальной сети или пару минут через VPN-соединение из моего дома. С svn это были бы минуты и часы соответственно.

Git vs. Perforce более сложный. Многие компании считают, что у них есть веские бизнес-причины для использования централизованного репозитория с контролем доступа и упрощения его фиксации, а других - трудно, и Perforce идеально подходит для этой модели. Однако git положительно поощряет людей работать в местном отделении, и нет способа заставить его работать по-другому. Разработчик может работать полностью в местном филиале и никогда не брать на себя обязательства по центральному репо - поэтому, если компания не хочет, чтобы ее сотрудники работали таким образом, лучше использовать Perforce.

Есть и другие проблемы с git для некоторых бизнес-задач. Я работал в компании, которая использовала git, и я не знаю, сколько раз я слышал эту дискуссию: «Я хотел бы, чтобы мы использовали [некоторые другие VCS], потому что мне нужно сделать [это], а я не могу с git «. «Конечно, вы можете сделать это с помощью мерзавца». "Как?" «Ну, во-первых, тебе нужно написать скрипт bash ...» «Не бери в голову».

И затем есть время, необходимое для первоначального заполнения исходного дерева с большой историей. С Perforce, поскольку история хранится на сервере, вы просто получаете последние версии всех файлов, и это действительно быстро - даже для настройки всего 9 ГБ дерева, о котором я упоминал, через VPN потребовалось всего несколько часов. С мерзавцем это может занять где-то между долгим временем и вечностью. Иногда мне приходится клонировать GTK + или репозитории X server git, и это долгий обеденный перерыв или, может быть, время для сна.

На самом деле, это вопрос правильного инструмента для работы. SVN отлично работает для большинства усилий Apple по открытому исходному коду, и будет ужасно для взлома ядра. git прекрасно работает для GTK +, но невероятно медленен для работы внутри WebKit - дерево исходных текстов и история слишком велики (как я выяснил, сложный способ работы с кодом с портала SVK-to-git WebKit). Perforce хорошо работает, если у вас гигантское дерево исходников и вам нужен централизованный контроль. Каждый из них отлично работает в правильном контексте.

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

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

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

• Люди давно используют Perforce, и им это довольно удобно, поэтому они не решаются переключиться на другое решение. Лица, принимающие решения, могут также не решиться отдать свой проект стоимостью 30 миллионов долларов в руки программного обеспечения, которое они никогда не использовали ранее.
• Многие компании / команды добавили поддержку Perforce к своим внутренним инструментам, которые могут потребовать значительного объема работы для обновления для поддержки другой VCS.
• Хотя программистам может быть легко переключиться на другой Git / Hg / SVN, в команде разработчиков игр гораздо меньше технических специалистов, таких как художники, дизайнеры и продюсеры. Чтобы освоить их с новой системой, может потребоваться много времени, и я готов поспорить, что они будут весьма устойчивы к изменениям.

Может быть, им нравится Perforce, потому что Perforce лучше?

• Perforce это быстро. Гораздо быстрее, чем Subversion или Git.
• Выполнение слияния лучше, чем Subversion или Git. Git не выполняет слияний, а отслеживание версий Subversion не так хорошо, по крайней мере, в 1.5.
• Perforce имеет отличную поддержку клиентов.
• Perforce объединяет редакцию хранилища Subversion с отдельными редакциями файлов. Perforce позволяет просматривать ревизии репозитория через списки изменений или отдельные ревизии файлов.
• Perforce намного лучше справляется с несколькими списками изменений, чем Subversion. Списки изменений в Subversion являются чем-то вроде запоздалой мысли, и я знаю мало кто его использует. Perforce встроен. Если вы переместите измененный файл из списка изменений по умолчанию, он не будет случайно зафиксирован.
• Perforce позволяет указать ваш рабочий макет каталога. Например, если у вас есть стандартное дерево каталогов исходного кода, но у некоторых клиентов есть пользовательский источник, вы можете наложить пользовательский источник поверх стандартного дерева. Вы можете легко сделать редкие заказы, указав только те элементы, которые вы хотите оформить.

Хорошо, прежде чем вы думаете, что я фанат Perforce, последний раз, когда я рекомендовал Perforce компании, было более семи лет назад. Perforce стоит 800 долларов за лицензию - что дешево по сравнению с ClearCase, но дороже по сравнению с Subversion. Мне трудно оправдать перформанс над Subversion.

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

Также есть меньше интеграций с Perforce over Subversion. Частично это связано с использованием клиента . Это просто не очень хорошо с VisualStudio или даже с Hudson. Частично это связано с тем, что Perforce должен создавать клиентские интеграции.

Там стоит проприетарная лицензия назвать административные расходы. Представьте себе, если бы вы могли лицензировать часть программного обеспечения по цене 1 доллар за пользователя. Черт возьми, давайте сделаем это двумя битами. Тысячи лицензий обойдутся вам всего в 250 долларов.

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

Вот почему многие коммерческие фирмы перешли на открытый исходный код. Это не стоимость лицензии. Вы платите разработчику 150 000 долларов в год, а какие еще 800 долларов за лицензию Perforce? Он управляет этой лицензией. Perforce выглядит великолепно по сравнению с ClearCase: быстрее, проще, дешевле, лучше. Но против Subversion? Perforce может быть быстрее, а может и лучше, но лучше ли это на 800 долларов? Это управление лицензией лучше? Не лучше ли использовать нужный инструмент?

Вот почему у Perforce могут быть проблемы.

Git - это не последний инструмент для всех. Он отлично работает в тех случаях, когда вам не нужен централизованный контроль доступа к хранилищу. Но это может быть боль во многих обстоятельствах. Я так выразился так:

1. Вы запускаете проект с открытым исходным кодом. Вы были бы счастливы или расстроены, если бы миллион людей имели копию всего вашего хранилища?
2. Вы управляете отделом финансовой торговли, который использует проприетарное программное обеспечение, чтобы получить преимущество над конкурентами. Вы были бы счастливы или расстроены, если бы миллион людей имели копию всего вашего хранилища?

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

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

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

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

Если бы колледж использовал Subversion, кто-то должен был бы знать всех студентов и дать им доступ к центральному хранилищу. Им придется управлять тем, кто может проверить, что и где. Если бы профессор назначил групповой проект, его нужно было бы настроить и управлять. Вам понадобится человек, работающий полный рабочий день, чтобы справиться с этим.

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

Git великолепен, но я продолжаю возвращаться к Subversion для моего личного хранилища исходных текстов. В конце концов, я этим не делюсь, а Subversion проще в использовании. Я использую Git для личной работы, если у меня небольшая команда, потому что мне не нужно постоянно держать свой репозиторий в Интернете. Для большинства коммерческих сайтов я по-прежнему считаю, что Subversion работает лучше всего. Но есть обстоятельства, когда Git светит.

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

Угадайте, что продукты FOSS не представлены в этих местах!

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

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

И наконец, хотя многие продукты FOSS имеют поддержку (например, Collabnet или Wandisco для SVN), они все еще пользуются репутацией «созданных гиками в их задней спальне». Мы все знаем, что это, как правило, b * * ** t, и лучший FOSS невероятно хорошо конкурирует с коммерческими предложениями, но моего менеджера еще нужно убедить. возможно, он просто не осознает разницу между незрелыми и зрелыми продуктами FOSS; может, ему все равно.

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

Потому что такие инструменты, как Perforce, привлекают продавцов вина и обедают людей, отвечающих за покупки, а Git - нет. Конечно, это просто циничная сторона моего разговора, но это цинизм, вызванный вниманием к процессу.

Просто чтобы прояснить ситуацию: я не имею в виду, что каждый раз, когда вы видите, что ваш ИТ-директор пьяно спотыкается по коридору, вы ожидаете использовать новую систему управления версиями в следующем квартале. Просто во многих организациях существует разрыв между использованием и приобретением. Конечно, есть и другие причины, по которым компании используют Perforce: например, они, возможно, уже вложили значительные средства в его реализацию в своем рабочем процессе. Но в целом - и этот вопрос очень общий - функционального преимущества в том, чтобы не использовать инструменты FOSS, нет.

Вероятно, по той же причине, по которой моя компания отказывается использовать много программного обеспечения с открытым исходным кодом (не то, чтобы я был согласен):

Когда что-то идет не так, они хотят, чтобы кто-то позвонил и на них кричал.

Хотя во всех ответах говорится о крупных компаниях, использующих P4 (и они отвечают, почему Google использовал P4), одна из основных причин, по которой Google продолжает использовать Perforce, заключается в том, что Perforce позволяет вам получить поддерево репо, тогда как вы не можете сделать это с помощью Git. С большими репозиториями, такими как Google, это имело огромное значение.

И, насколько я слышал, Facebook использует SVN и Git-SVN.

Потому что SVN - это, ну, в общем, SVN, и Perforce (из-за того, что 4 года назад сравнивали инструменты) делает некоторые вещи лучше, чем SVN . (Разветвление является одним из них, я думаю.)

И GIT это Dvcs, как в распределенных . Для команд компании распределенная часть вполне может быть чем-то, что ни забота, ни желание.

Еще одна причина, по которой крупные компании стремятся покупать большие, клочковатые, «корпоративные» системы контроля версий:

Руководители среднего и высшего звена в ИТ-отделах рассматривают VCS как нечто, что используется в каждом отдельном проекте, или вы можете принудительно применять его. После того, как вы навязали использование VCS, тогда почему бы не добавить туда небольшой «процесс»? Я имею в виду, что у вас есть возможность указать «корпоративную» систему, почему бы не взять ее под центральный контроль, добавить «аварийное восстановление» и некоторые «функции рабочего процесса», чтобы вы могли сказать «Мы CMM Level StraightJacket совместимый!». VCS - слишком легкая цель, чтобы внедрять функции, обеспечивающие соблюдение рабочих процессов.

Что касается выбора какого-то непристойного, неуклюжего программного обеспечения (Serena Dimensions), говорят, что несколько раундов игры в Bikini Golf на Багамах с несколькими сотрудниками по продажам, насчитывающими более 20 с лишним лет, могут убедить директора или вице-президента в чем угодно.

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

Git не работает так же хорошо в этой модели. Если у вас небольшая компания или компания с плохим VPN-доступом, это то, где она действительно сияет.

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

Я чувствую, что в будущем компании могут начать уходить от Perforce и больше к GIT ... большинство разработчиков, которых я знаю, предпочитают это !! Также проверьте http://whygitisbetterthanx.com/#git-is-fast для получения дополнительных доказательств того, почему Perforce может быть не столь доминирующим в ближайшие годы!

Несколько раз назад мы перешли от набора VCS (я точно знаю, что RCS, CVS, ClearCase, Perforce использовались ранее, могут быть и другие) на Perforce в качестве уникальной используемой системы. Это был не маленький проект: миграция заняла больше года. Ответственная команда (я не был ее частью) провела оценку нескольких VCS, и, по крайней мере, git и svn были рассмотрены так же, как и те, которые уже используются. Насколько я помню их отчет, они отфильтровали инструменты без необходимых функций и затем рассмотрели:

• производительность при обычном использовании, особенно для удаленных сайтов

• требования к ресурсам

• Важность изменений, необходимых в рабочей привычке

• поддержка доступности и стоимости

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

Когда-то, не так давно (когда IDE называли VI), единственными бесплатными (с открытым исходным кодом) системами были CVS, RCS и SCCS.

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

Было много коммерческих систем управления исходным кодом, большинство из которых были предоставлены одним поставщиком оборудования (IBM, DEC, HP и т. Д.) И работали только на их оборудовании.

Затем несколько компаний заявили о продаже кроссплатформенного коммерческого управления исходным кодом, включая Perforce и ClearCase.

ClearCase был построен на RPC, который не работал хорошо в глобальных сетях (пока что только в Интернете) из-за большого количества небольших сетевых пакетов, которые были «замкнуты», также IBM и рационально рассматривали ClearCase как «дойную корову» и никогда не показывали это много любовь.

Таким образом, единственной «старой» коммерческой системой контроля исходного кода, которая все еще широко используется, является Perforce. После того, как Perforce используется и интегрируется в системы сборки и системы отслеживания ошибок, у компании очень мало краткосрочной выгоды, чтобы перейти к чему-либо еще.

Итак, подведем итог, перформанс получил «ногу в дверь», когда не было много других вариантов, и они еще не запутались, чтобы заставить людей отойти от этого .