Я слышал о некоторых крупных компаниях, например, Google, Facebook используют Perforce
Есть ли причина, по которой SVN / Git не может заменить Perforce?
version-control
user34401
источник
источник
Ответы:
Обоснование, возможно, менее актуально, чем когда-то, но 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 хорошо работает, если у вас гигантское дерево исходников и вам нужен централизованный контроль. Каждый из них отлично работает в правильном контексте.
источник
pull
будут получать свои подмодули для получения обновлений или новых функций, и только тогда пользователям этого репозитория потребуются обновления, размер которых превышает код самого репозитория.Особенно GIT, а SVN в некоторой степени не так уж и стар - если вам нужен был надежный контроль версий в середине 90-х, вам почти пришлось перейти на коммерческую деятельность, поскольку SVN была в зачаточном состоянии, а CVS была, ну, в общем, CVS. После того, как вы много вложили в систему, ее перемещение может быть медвежьим.
Да, и парни, которые действительно принимают эти решения, вероятно, никогда не взаимодействуют с системой контроля версий, но получают удовольствие и обедают от вышеупомянутого торгового персонала.
источник
Я работаю программистом в игровой индустрии почти 9 лет, и каждый проект, над которым я когда-либо работал, использовал Perforce. Я подозреваю, что есть несколько вещей, поддерживающих использование Perforce в этой конкретной отрасли.
источник
Может быть, им нравится 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 - это не последний инструмент для всех. Он отлично работает в тех случаях, когда вам не нужен централизованный контроль доступа к хранилищу. Но это может быть боль во многих обстоятельствах. Я так выразился так:
Если вы делаете централизованные сборки, вам все равно нужно использовать один репозиторий. В чем преимущество распределенной системы в этих обстоятельствах? На самом деле, это может побудить людей работать в автономном режиме . Разработчики могут просто пойти своим собственным веселым путем и не совершать ничего до последней минуты. Затем вы проводите два безумных дня, пытаясь заставить все работать снова.
Я не против 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 используется и интегрируется в системы сборки и системы отслеживания ошибок, у компании очень мало краткосрочной выгоды, чтобы перейти к чему-либо еще.
Итак, подведем итог, перформанс получил «ногу в дверь», когда не было много других вариантов, и они еще не запутались, чтобы заставить людей отойти от этого .
источник