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

113

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

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

user34401
источник
34
Я слышал, что Google использует папки с метками времени на общем диске! ;)
FrustratedWithFormsDesigner
10
Только общий диск использует MapReduce, так что они крутые
Пол Стовелл
4
Большой проблемой будет поддержка. Когда вы покупаете Perforce, вы покупаете поддержку у разработчика системы, чего вы можете не получить от Git.
ChrisF
12
@ Анто: кого волнует, что говорит Линус? Тот факт, что вы блестящий разработчик ядра, не означает, что вы лучше всех знаете обо всем.
Билли ONEAL
5
Я только что пришел с пользовательской конференции Perforce 2 недели назад и могу сказать, что Google использует Perforce. Они получают более 10000 сообщений в день на свой 1 сервер.
горизонтально

Ответы:

83

Обоснование, возможно, менее актуально, чем когда-то, но 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) могут быть некоторые практические ограничения для бесплатных решений.

JasonTrue
источник
3
Спасибо за разумный ответ, кроме циничной теории "вина и обеда". Это может быть правдой для многих компаний, но есть некоторые законные причины, по которым компании выбирают Perforce (или переписывают его: P). Я не могу представить, что пытаюсь обработать источник NT в SVN. Это правда, что SVN и Git наверстывают упущенное, и, возможно, для нового крупного проекта один из них - правильное решение. Но подумайте о расходах, связанных с переносом живого проекта размером с Windows (все версии) из одной системы контроля версий в другую. Это не стоит затрат, особенно когда работает текущая система контроля версий.
Грег Джексон
1
На самом деле, они перешли от SLM (внутренний инструмент) к Source Depot (форк Perforce), так что, возможно, в этом случае это стоило того. Но да, это не стоит затрат, если нет довольно существенной выгоды.
JasonTrue
1
Discussion.GogCreek.com / Joelonsoftware / ... имеет некоторые из этой истории в основном из сторонних источников. (Я был аутсайдером с 2004 года, FWIW).
JasonTrue
3
Я не уверен в ситуации большого репо. Я управляю одним, это репо 12 Гб (т. Е. Каталог сжатых серверов 12 Гб) и содержит 320 000 ревизий. Достаточно быстро. Скорее всего, Microsoft использовала Perforce, потому что SVN не существовало еще в 1999 году. Maillist.perforce.com/pipermail/perforce-user/2001-August/… и subversion.apache.org/docs/release-notes/release-history.html
gbjbaanb
8
@gbjbaanb, это не большое хранилище ... в наши дни оно считается средним. ;) См., Например, research.google.com/pubs/archive/34459.pdf
Алекс Фейнман,
65

Я достаточно опытен в 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 хорошо работает, если у вас гигантское дерево исходников и вам нужен централизованный контроль. Каждый из них отлично работает в правильном контексте.

Боб Мерфи
источник
2
Проблема в том, что крупные компании помещают свой код в один репозиторий? Как насчет помещения каждого «модуля» или «приложения» в отдельный репозиторий Git, чтобы размеры этих репозиториев были управляемыми? Каждый из этих репозиториев будет затем импортировать необходимые функции, используя функцию субмодуля Git. Таким образом, сопровождающие репозиториев иногда pullбудут получать свои подмодули для получения обновлений или новых функций, и только тогда пользователям этого репозитория потребуются обновления, размер которых превышает код самого репозитория.
Карл Дж
@Carl G: Если вы прочитаете все ответы здесь, вы найдете множество причин, по которым люди выбрали Perforce вместо git, которые не имеют ничего общего с возможностями git в отношении репозиториев или подмодулей.
Боб Мерфи
Я пытался рассмотреть «время, которое требуется для первоначального заполнения исходного дерева», но на самом деле я вижу, что упомянутая проблема подмодулей не имеет значения, поскольку подмодули также содержат всю историю этих репозиториев. Я предполагаю, что единственный способ сократить историю - использовать двоичные файлы зависимостей.
Карл Дж
Что ж, с помощью git вы можете сделать мелкий клон и получить только небольшое количество истории или, возможно, только самые последние файлы (git clone --depth 1). Это работает и для подмодулей git.
Сахил Сингх
38

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

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

Wyatt Barnett
источник
4
+1. Мы перешли на Git относительно недавно, и нам пришлось довольно долго выступать на концертах - просто потому, что все остальное было хуже.
9000
11
Хотя IMO Perforce тратит впустую много моего времени. Мы все еще используем его на работе, потому что мы потратили время на разработку пользовательских инструментов, которые взаимодействуют с ним. Чтобы переключиться, мы должны были бы перестроить эти инструменты.
m4tt1mus
2
Разработчики Perforce и невежественные пользователи ненавидят проверку кода. Я предпочел бы написать код с карандашом и скомпилировать это .
Джим Шуберт
Я думаю, что вы должны взглянуть на выступление, прежде чем комментировать.
Тоби Аллен
30

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

  • Люди давно используют Perforce, и им это довольно удобно, поэтому они не решаются переключиться на другое решение. Лица, принимающие решения, могут также не решиться отдать свой проект стоимостью 30 миллионов долларов в руки программного обеспечения, которое они никогда не использовали ранее.
  • Многие компании / команды добавили поддержку Perforce к своим внутренним инструментам, которые могут потребовать значительного объема работы для обновления для поддержки другой VCS.
  • Хотя программистам может быть легко переключиться на другой Git / Hg / SVN, в команде разработчиков игр гораздо меньше технических специалистов, таких как художники, дизайнеры и продюсеры. Чтобы освоить их с новой системой, может потребоваться много времени, и я готов поспорить, что они будут весьма устойчивы к изменениям.
Майк О'Коннор
источник
19
Я думаю, что «старые» разработчики (+10 лет), вероятно, так же устойчивы к изменениям, как и «нетехнические» люди.
Уэйн Вернер
3
+1 на это, специально для этой отрасли. Программисты видеоигр, как правило, имеют так много на своем планшете, что изменение инфраструктуры, с которой они работают, является пугающим предложением. «Если ничего не сломано ...» - это своего рода мантра, которая часто мешает индустрии перейти от более старых решений, даже если они могут быть более подходящими.
Крис Субаджио
2
@Wayne - полностью эйджистский комментарий. Мне за шестьдесят, и я являюсь ведущим сторонником перемен и инноваций на моем среднем сайте. Джеймсу Гослингу было 46 лет, когда он начал писать первую JVM. Кену Томсону было 49 лет, когда он придумал схему кодирования UTF-8, и 63 года, когда он начал работать над языком GO.
Джеймс Андерсон
1
@JamesAnderson Я думаю, что вы, вероятно, там. А если в вашей организации нет культуры улучшения, то вы увидите эффект Мертвого моря . Интересно, возможно ли изменить систему в целом или мы можем только поиграть с нашей маленькой частью?
Уэйн Вернер
2
@ MikeO'Connor Вы также забыли, что в играх используется много бинарных ресурсов. Возможность исключительно блокировать бинарные активы - ОГРОМНЫЙ плюс.
CodingMadeEasy
22

Может быть, им нравится 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 светит.

Дэвид В.
источник
40
Чего ждать? Вы потеряли меня здесь "Выполнять слияние лучше, чем Subversion или Git. Git действительно не выполняет слияния [...]". Вы можете объяснить это?
Сверр Rabbelier
1
На самом деле я нахожу, что Git довольно хорош для слияний, более приятен, чем scm-инструменты старой школы, но когда я в svn, мне не хватает возможности вносить изменения в список изменений «не регистрировать», как я это часто делал с Perforce. (Я пытался сделать это в SVN, но все равно в итоге случайно проверял, потому что списки изменений svn и p4 ведут себя по-разному).
JasonTrue
12
@SverreRabbelier 3 года спустя, и все еще есть люди, которые ждут ответа на ваш вопрос.
Навин
1
«потому что Perforce лучше» ... «Это не футбольный матч, где одна команда лучше другой». ...
RJFalconer
4
исполнять быстро. намного быстрее чем svn или git. --- тесты, или этого не произошло ...; p
sjas
14

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

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

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

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

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

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

gbjbaanb
источник
Это был более убедительный аргумент десять лет назад, но многие продукты FOSS сегодня очень популярны; в том числе SVN, который используется в некоторых крупных компаниях.
Джереми
Меня не волнует, что у FOSS есть подходящие вещи, чтобы конкурировать - меня волнует, что мой менеджер думает, что это не так. Кроме того, некоторые крупные компании продвигаются медленно, поэтому они все еще находятся там, и некоторым из них понадобится еще пара лет, чтобы рассмотреть возможность оценки продуктов FOSS.
gbjbaanb
gbjbaanb Вы меня неправильно поняли. Я не думаю, что факторы, которые вы описываете, почти так же актуальны на любом уровне управления, как и десять лет назад. Хотя это может быть вашей ситуацией, было бы ошибочно обобщать это. FOSS является основным, то есть она будет принята большинством крупных компаний и используется в основных системах.
Джереми
6
Я думаю, что это ключевой момент: инструменты FOSS не рекламируют себя, на самом деле, потому что у них нет причин для этого. Отчасти это брошюры и другие вещи, о которых вы упоминаете, но даже если я использую Google «системы сравнения SCM» или «системы контроля версий сравнения», единственные вещи, которые я нахожу, - это те, что выполнены Perforce. Конечно, я должен рассмотреть источник, но я не знаю, как инструменты FOSS пытаются рекламировать себя и рассказывают о том, почему они лучшие. Я знаю, что мы смотрим на коммерцию свысока, но иногда маркетинг и реклама действительно помогают мне сделать осознанный выбор.
Шанс
1
Я думаю, что есть две веские причины не выбирать Perforce: 1. Ветвление очень дорогое, и 2. Процесс извлечения-затем-редактирования сильно затрудняет согласование автономной работы.
Кевин Клайн
14

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

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

Дмитрий
источник
13
Это может показаться циничным, но по сути вы попали в ноготь на голове. В моей собственной компании я изо всех сил стараюсь продвигать любое решение FOSS, поскольку у исполнительного директора есть ощущение, что если оно бесплатное, оно не может быть полезным.
wolfgangsz
1
Слава этому, хотя я мог бы немного их преобразовать, когда они заменили наше решение SVN на «корпоративное» решение, которое стоило фальшивое состояние, требовало консультантов, двух подрядчиков для его администрирования, а также после долгих воплей, скрежета зубов, глючной операции и смерть нашей производительности ... была выброшена и заменена нашим старым решением SVN.
gbjbaanb
7
Google на самом деле не известен такой культурой.
Джереми
11
@Chance: С какими вещами вы связываетесь с техподдержкой? Я использовал CVS, Subversion и Mercurial, и я ни разу не обнаружил, что хочу кого-то, кому я мог бы позвонить. Если у меня есть проблема, я гуглю или отправляю вопрос, и он решается, как правило, за несколько минут. Я бы предположил, что инструмент управления исходным кодом, который требует поддержки от разработчика системы, имеет серьезную проблему.
Том Андерсон
2
@TobyAllen: не около шести лет (обратите внимание на дату вопроса) , но в эти дни она выглядит как даже неволей хочет использовать что - то другое , чем Perforce: perforce.com/git
Дмитрий
12

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

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

Майкл
источник
2
Я согласен: это большая причина для многих ИТ-отделов, но это кажется незрелым. «Это не наша вина, это их ошибка». Выбор продукта более низкого качества только из-за потенциальной возможности указывать пальцем на шею - это инфантильное решение. Не то, чтобы это не часто делали, просто это кажется детским.
Брюс Эдигер
Ваш ответ не относится к технической поддержке Perforce. Жаль, потому что, если бы вы знали, насколько это хорошо, ваш ответ мог бы не прийти. Техническая поддержка Perforce является звездной и преданной, и они быстро исправляют ситуацию.
Br.Bill
9

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

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

manojlds
источник
1
Безусловно, подпункты поощряют и облегчают повторное использование кода. Вот почему я выбираю Perforce, когда у меня есть право голоса. Большое дело! Легко смешивайте и сопоставляйте код из разных репозиториев (вложенные репозитории hg), отслеживая, кто использует тот или иной репо, возможность легко отслеживать реконы, ответвления и слияния во всех репо. В то же время это делает его очень простым для конечного разработчика с помощью однострочной клиентской спецификации и сохраняет детали в отраслевой спецификации для суперпользователей. Прямо сейчас я вынужден использовать Mercurial в большом проекте, и работа с sup-repos при помощи hg стоит МНОГО денег из-за потери производительности.
stephenmm
8

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

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

Мартин Ба
источник
5
Вы можете прекрасно использовать Git с различными рабочими процессами, так что распределение не является проблемой ... если только команда компании не имеет ни малейшего понятия. whygitisbetterthanx.com/#any-workflow
М. Дадли
2
Я бы не сказал, что Perforce хорошо разветвляется ... создание ветвей Perforce приводит к занятой копии всего разветвленного. SVN разветвляется ленивой копией, поэтому разветвляется намного быстрее.
Кевин Клайн
1
@Jason - ветвление в subversion происходит быстрее, чем я могу напечатать: "svn cp ...; svn switch ..." При выполнении создание веток безумно сложно; создать спецификацию ветки, создать рабочее пространство, интегрировать, зафиксировать. Черт, с перформансом все так. Без быстрого и легкого ветвления я считаю RCS непригодным для использования. Судя по чистому трафику и скорости расширения, похоже, что Perforce является продуктом с истекшим сроком эксплуатации.
Кевин Клайн
1
@ Кевин, я не уверен, как вы делаете ветвление, но я просто делаю интеграцию, коммит часть. Я никогда не задавал спецификацию ветвления, и мне никогда не приходилось создавать рабочую область для ветвления (хотя мне, возможно, пришлось изменить свое отображение представления, если я решил исключить каталоги в моем представлении). При этом я ничего не сделал с SVN, поэтому я не могу комментировать этот аспект.
шанс
1
@kevin: Вы знаете, что «что-то работает лучше» не обязательно зависит от количества команд CLI, необходимых для этого. Просто комментарий кого-то, кто не очень опытен ни в SVN, ни в Perforce.
Мартин Ба
6

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

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

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

Брюс Эдигер
источник
без комментариев, но я хочу знать, кто из наших подрядчиков или менеджеров должен играть в бикини гольф!
gbjbaanb
5
Я признаю это, Bikini Golf, вероятно, будет работать на меня тоже.
Джоккинг
5

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

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

Квартира
источник
2
Все дело в определении рабочего процесса, централизованного или децентрализованного значения не имеет. Работа поддержки не легче при попытке прочесать 200 веток в центральном репо. В целом компании выбирают централизованные решения, потому что это то, что им удобно. Нет заметных преимуществ перед DVCS, используемой с централизованным общим репозиторием.
Wadesworld
4

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

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

rrazd
источник
4

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

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

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

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

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

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

AProgrammer
источник
3

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

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

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

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

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

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

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

Ян
источник