Чому великі компанії використовують Perforce? [зачинено]

Я чув про деякі великі компанії, наприклад, Google, Facebook використовують Perforce

Чи є причина, чому SVN / Git не може замінити Perforce?

Виправдання є, мабуть, менш актуальним, ніж це було раніше, але Perforce прагне краще працювати на великих сховищах, ніж Subversion. Це одна з причин Microsoft придбала Perforce джерело ліцензії на створення Source Depot; Сховище NT - це чудовисько, і не багато продуктів, комерційних чи інших способів, могли б впоратися з ним.

Також, принаймні свого часу, візуальні інструменти для Perforce були набагато кращими, ніж те, що доступно у вікні (так би мовити) із Subversion або Git. Якщо ви використовуєте Meld, можливо, ці речі мають значення менше, ніж колись, але все ж є кілька речей, які Perforce зробив дуже добре, включаючи візуалізації розгалуження та злиття, які, хоча я не маю детальної пам’яті з тих пір, як це було приблизно 3 роки з моменту, коли я востаннє торкнувся Перфорса, здавалося складнішим, ніж, наприклад, підхід Гітуба до цього.

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

Більшість проектів, над якими я працював поза межами Майкрософт, можуть добре обслуговуватися Git, Mercurial або Subversion, і я б сказав, що більшість компаній, над якими я працював, використовують один із цих варіантів. Але є приємне місце, як правило, поєднання розміру сховища, моделі розгалуження та об'єднання, а також досвід / історія роботи команди, яка спонукає людей до використання комерційних інструментів. Наприклад, я рідко бачив великі сховища Git. Це може бути не пов’язано з будь-якими внутрішніми обмеженнями Git; Я визнаю повне незнання цього. Але в деяких проектах (як Windows NT) можливі обмеження щодо безкоштовних рішень.

Я досить добре володію svn, git та Perforce, як як користувач, так і в налаштуванні та підтримці серверів.

Для компанії або навіть самотнього програміста, як я, контроль над джерелами - це витрати, понесені на підтримку реальної грошової діяльності, яка розробляє і продає код. Отже, слід врахувати кілька факторів:

• Наскільки це добре відповідає вашій моделі розвитку?
• Наскільки легко розробникам вивчати та використовувати?
• Чи рутинні операції для розробників швидкі?
• Чи відволікається процес його використання від їх реальної роботи, а саме - написати код?
• Наскільки легко налаштувати та підтримувати?
• Скільки коштує придбання та обслуговування?
• Якщо вам потрібна допомога, як легко її отримати?

Я збираюся пропустити tl: dr детально про плюси і мінуси окремих систем. Досить сказати, що коли я повернувся до штатного консалтингу минулого року, я переглянув усіх трьох, щоб вирішити, що дозволить мені максимально швидко заробити гроші, доставляючи якісне програмне забезпечення для моїх клієнтів і не вимагаючи багато неоплаченого дуріти. Коли я взяв політичний розгляд "FOSS - це добре, а не FOSS - це зло" з рівняння, я завершив розсилку за ліцензією Perforce.

І тому великі компанії також вибирають Perforce.

Ось тл: др деталі з коментарів, а також трохи більше.

Адресація svn проста: порівняно з Perforce, це дуже повільно. Я працював у компанії, яка вбудовувала Linux для мобільних телефонів, і наші повні джерела працювали в 9 ГБ; вони використовували Перфорс. Після того, як у вас з'явився код, оновлення останніх джерел зазвичай займало секунди в локальній мережі або пару хвилин через VPN-з'єднання від мого будинку. З svn було б відповідно хвилини та години.

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

Є інші проблеми з git для деяких бізнес-потреб. Я працював у компанії, яка використовувала git, і не знаю, скільки разів я чула цю дискусію: "Я б хотіла, щоб ми використовували [якусь іншу VCS], тому що мені потрібно [це] робити, і я не можу з git . " "Звичайно, ви можете це зробити з git." "Як?" "Ну, спершу вам потрібно написати сценарій баш ..." "Неважливо".

І тоді є час, який потрібен для початкового заповнення вихідного дерева, яке має багато історії. Завдяки Perforce, оскільки історія зберігається на сервері, ви отримуєте найновіші версії всіх файлів, так що це дуже швидко - навіть налаштування цього всього 9 ГБ я згадала лише за пару годин на VPN. При git це може тривати десь між тривалим часом і вічністю. Мені іноді доводиться клонувати GTK + або репост X-сервера X, і це довга перерва на обід, або, можливо, час для сну.

Дійсно, це питання правильного інструменту для роботи. svn працює чудово для більшості завдань з відкритим кодом Apple, і буде жахливо для злому ядра. git чудово працює для GTK +, але неймовірно повільний для роботи всередині WebKit - дерево джерела та історія є надто величезними (як я дізнався, важкий спосіб роботи з кодом з порталу svn-to-git WebKit). Perforce працює добре, якщо у вас є гігантське дерево-джерело і вам потрібен централізований контроль. Кожен з них чудово працює в потрібному контексті.

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

О, і хлопці, які приймають ці рішення, ймовірно, ніколи не взаємодіють із системою контролю версій, але виграють і обідають вищевказаний торговий персонал.

Я програміст в ігровій індустрії вже майже 9 років, і кожен проект, над яким я працював, використовував Perforce. Я підозрюю, що є кілька речей, що дозволяють Perforce використовувати у цій конкретній галузі.

• Люди користуються Perforce вже давно, і їм це дуже зручно, завдяки чому вони вагаються перейти на інше рішення. Ті, хто приймає рішення, можуть також вагатися, щоб передати свій проект на 30 мільйонів доларів у руки програмного забезпечення, яке вони ніколи раніше не використовували.
• Багато компаній / команд додали підтримку Perforce до своїх внутрішніх інструментів, що може потребувати значного обсягу роботи для оновлення для підтримки іншого VCS.
• Хоча програмісти можуть легко перейти на інший Git / Hg / SVN, в команді з розробки ігор є набагато менше технічних членів, таких як художники, дизайнери та продюсери. Приємне їх використання з новою системою може зайняти багато часу, і я б хотів зробити ставку, що вони будуть досить стійкими до змін.

Можливо, може, їм подобається Перфорс, тому що Перфорс кращий?

• Виконання сили швидко. Набагато швидше, ніж Subversion або Git.
• Персональне злиття краще, ніж Subversion або Git. Git насправді не зливається, а відстеження версій Subversion не так добре, принаймні в 1.5.
• Perforce має чудову підтримку клієнтів.
• Perforce поєднує перегляд сховища Subversion з переглядом окремих файлів. Perforce дозволяє переглядати версії сховищ за допомогою списків змін або окремих редакцій файлів.
• Perforce робить набагато кращу роботу з кількома списками змін, ніж Subversion. Списки змін субверсії дещо задумані, і я мало знаю тих, хто цим користується. Perforce вбудований. Якщо ви перемістите змінений файл зі списку змін за замовчуванням, він не відбувається випадково.
• Perforce дозволяє вказати макет робочого каталогу. Наприклад, якщо у вас є стандартне дерево каталогів вихідного коду, але деякі клієнти мають власне джерело, ви можете накладати спеціальне джерело на стандартне дерево. Ви можете легко робити невеликі каси, вказавши лише ті предмети, які ви хочете отримати.

Гаразд, перш ніж ти подумаєш, що я "Фанбой Перфорса", останній раз, коли я рекомендував "Перфорс" компанії, було більше семи років тому. Perforce коштує 800 доларів за ліцензію - це дешево порівняно з ClearCase, але зате дорого порівняно з Subversion. Мені важко обгрунтовувати Перфорсу над Підривом.

Крім того, більшість розробників використовують Subversion. Вони не хочуть вчитися Perforce, який має інший спосіб роботи, ніж Subversion. У Perforce вам потрібно створити клієнта, і ви повинні позначити файли для редагування, перш ніж ви зможете їх змінити. Вам не потрібно робити цього з Subversion.

З Perforce над Subversion також є менше інтеграцій. Частина цього пов'язана з використанням клієнта . Він просто не грає добре з VisualStudio або навіть з Хадсоном. Частина його пов'язана з тим, що Perforce повинен створити клієнтські інтеграції.

Існує вартість на власну ліцензію, яка викликає адміністративні витрати. Уявіть, чи зможете ви ліцензувати частину програмного забезпечення на суму 1,00 долара на користувача. Чорт забирай, зробимо це двома бітами. Тисяча ліцензій коштувала б вам всього 250 доларів.

Тепер вам потрібна штатна особа, яка керує ліцензією. Середній технічний працівник перебуває у компанії близько 2 років. Це означає, що 500 людей щороку їдуть, а ще 500 приїдуть. Десять людей щотижня повинні змінювати ліцензію. Тоді, бувають випадки, коли проект підбирається, і вам потрібно ще 250 ліцензій. Їх потрібно замовляти, вводити та підтримувати. Це може зайняти тижні.

Тому багато комерційних фірм перейшли до відкритого коду. Це не вартість ліцензії. Ви платите розробнику 150 000 доларів на рік, що ще 800 доларів за ліцензію Perforce? Це управління цією ліцензією. Perforce виглядає чудово в порівнянні з ClearCase: Швидше, легше, дешевше і краще. Але, проти підриву? Виконання може бути швидшим, а може і кращим, але хіба на 800 доларів краще? Чи краще управління ліцензією? Чи не краще використовувати бажаний інструмент?

Ось чому у Перфорса можуть виникнути проблеми.

Git - це не кінцевий інструмент "все-все". Це чудово працює в тих випадках, коли ви не хочете централізованого контролю того, хто має доступ до сховища. Але, це може бути болем за багатьох обставин. Я так висловився так:

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

Якщо ви займаєтесь централізованими побудовами, вам все одно потрібно використовувати одне сховище. Яка перевага розподіленої системи в цій обставині? Насправді це може спонукати людей працювати поза межами . Розробники можуть просто піти самостійно веселим шляхом і нічого не робити до останньої хвилини. Потім ви проводите два шалені дні, намагаючись змусити все знову працювати.

Я не проти Гіта. Я рекомендував Git у багатьох випадках. Сюди входять розподілені команди з поганим з'єднанням один з одним або місця, де ви не хочете відслідковувати всіх, хто має доступ до вихідного сховища.

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

Використовуючи Git, адміністратору сховища потрібно лише брати коміти у своїх колег-професорів. Вони не повинні турбуватися про окремих студентів. Професори можуть дозволити студентам взяти на себе зобов’язання щодо своєї версії сховища. Студенти можуть працювати в групах, і кожна група може поділитися своєю версією сховища.

Якщо коледж використовував Subversion, хтось повинен був би знати всіх студентів і надати їм доступ до центрального сховища. Їм доведеться керувати, хто може перевірити, що і де. Якщо професор призначив груповий проект, його потрібно було б налаштувати та керувати ним. Вам знадобиться штатна людина просто для управління цим.

Це не футбольна гра, де одна команда краща за іншу. Інструменти працюють по-різному, і кожен має свої переваги та недоліки. Перфорс - чудовий інструмент. На жаль, склалися обставини, які важко рекомендувати.

Git чудовий, але я продовжую повертатися до Subversion для мого особистого сховища. Зрештою, я не поділяю це, а Subversion просто простіший у використанні. Я використовую Git для особистої роботи, якщо у мене є невелика команда, оскільки мені не доведеться постійно зберігати своє сховище в Інтернеті. Для більшості комерційних сайтів я все ще вважаю, що Subversion працює найкраще. Але, є обставини, коли Гіт світить.

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

Здогадаєтеся, що в таких місцях продукти FOSS відсутні!

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

Інша причина - зрілість. Деякі продукти, які ми використовуємо сьогодні, лише нещодавно досить стабільні для серйозного використання бізнесу, деякі не мають можливості підтримки, деякі не мають перевірених результатів як бізнес-рішень. Це важливі речі, які слід враховувати (хоча, як технік, я з радістю оцінюватиму FOSS-рішення, якщо ризик їх використання та відмови від них мінімальний для того, щоб продовжувати працювати), а деякі менеджери побоюються не мати їх. Вони підзвітні своїм начальникам і почуватимуться набагато комфортніше, якщо за продуктом стоїть організація підтримки - все-таки у вас є одна для вашого бізнесу.

Нарешті, хоча багато продуктів FOSS мають за собою підтримку (подумайте Collabnet або Wandisco для SVN), вона все ще отримує репутацію "зробленої вундеркіндами в їх задній спальні". Ми всі знаємо, що це загалом b * * ** t, і найкращий FOSS неймовірно добре конкурує з комерційними пропозиціями, але мій менеджер все-таки повинен переконатися. можливо, він просто не усвідомлює різниці між незрілими та зрілими продуктами FOSS; можливо, йому все одно.

У будь-якому випадку, Perforce - це чудова SCM, немає причин не вибирати її. Я міг би сказати те саме і для інших СКМ, але знову ж таки, я можу сказати лише про погані речі про деякі інші, і все ж маю кошмари, коли мова йде про певну пару продуктів.

Тому що такі інструменти, як Perforce, мають продавців вина та обідають людей, які відповідають за закупівлю, а Git - ні. Звичайно, це якраз цинічна сторона моєї розмови, але це цинізм, спричинений баченням процесу близько.

Просто для того, щоб це було абсолютно зрозуміло: я не маю на увазі, що кожного разу, коли ви побачите, що ваш CIO спотикається п’яним коридором, очікуйте, що в наступному кварталі будете використовувати нову систему версій. Просто в багатьох організаціях існує розрив між використанням та придбанням. Звичайно, є й інші причини, що компанії використовують Perforce: наприклад, вони, можливо, вже вклали значні кошти в її впровадження у свій робочий процес. Але взагалі --- і це питання дуже загальне --- немає функціональної переваги в тому, щоб не використовувати інструменти FOSS.

Можливо, з тієї ж причини моя компанія відмовляється використовувати багато програмного забезпечення з відкритим кодом (не те, що я згоден):

Коли щось піде не так, вони хочуть, щоб хтось, на кого можна зателефонувати, кричати.

Хоча всі відповіді говорять про великі компанії, які використовують P4 (і вони відповідають, чому Google використовував P4), одна з головних причин, якими Google продовжує користуватися Perforce, полягає в тому, що Perforce дозволяє оформити піддірева репо, тоді як ви не можете цього робити з Git. З великими репортажами на зразок Google, які зробили величезну зміну.

І наскільки я чув, у Facebook використовують SVN та Git-SVN

Тому що SVN - це, мабуть, SVN та Perforce (колись 4 роки тому порівнюючи інструменти) робить деякі речі краще, ніж SVN . (Я думаю, що гілка серед них одна.)

І GIT - це Dvcs, як і в розповсюдженому . Для команд компаній розподілена частина може бути чимось, про що ні піклуються, ні бажають.

Ще одна причина, що великі компанії, як правило, купують великі, клубні, "корпоративні" системи управління версіями:

Середній та вищий рівень управління в ІТ-відділах розглядають VCS як щось, що використовується у кожному проекті, або ви можете застосувати його до використання. Після того, як ви застосували використання VCS, то чому б і там не поставити трохи "процесу"? Я маю на увазі, у вас є можливість вказати систему "для всіх підприємств", чому б не взяти її під центральний контроль, і додати "відновлення після аварій" та деякі "функції робочого процесу", щоб ви могли сказати "Ми рівень CMM StraightJacket поступливий! ". Про те, до чого сходить, система VCS є надто простою ціллю, щоб поставити функції забезпечення робочого процесу.

Що стосується вибору якихось хитрого, крутого програмного забезпечення (Serena Dimensions), то сказано, що кілька раундів бікіні-гольфу на Багамах з кількома 20-ти жіночими продавцями можуть переконати директора чи віце-президента у будь-чому.

Великим компаніям потрібна якась централізована модель. Як тільки розробники закінчують розробку, вона передається в службу підтримки. Ви дійсно хочете бути в туфлях з підтримкою, коли їм доводиться розчісувати 50-200 розподілених репортажів для розробників? І побудови робляться на основі центрального репо, будівлі повинні завжди, завжди, завжди бути відстежуваними та відтворюватися. Ви дізнаєтесь про це вперше, коли вас звернуть до суду через якесь дурне порушення патенту.

Git не працює так добре в цій моделі. Якщо у вас є менша компанія або компанія з поганим доступом до VPN, саме там вона справді світить.

Однією з причин, якою більшість компаній користуються Perforce, може бути те, що в ІТ-відділі є більше професіоналів, які мають багато знань про це та мають багаторічний досвід проблем, пов’язаних із цим.

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

Деякий час тому ми перейшли з набору VCS (я точно знаю, що RCS, CVS, ClearCase, Perforce використовувались раніше, також могли бути й інші) на Perforce як унікальну систему, що використовується. Це був не маленький проект: міграція зайняла один рік. Відповідальна команда (я не був її членом) оцінювала кілька VCS, і принаймні git та svn були розглянуті, а також ті, що вже використовуються. Як я пам’ятаю їхній звіт, вони відфільтрували інструменти без необхідних функцій, а потім розглянули:

• продуктивність за типового використання, особливо для віддалених сайтів

• вимоги до ресурсів

• важливість змін, необхідних у звичці праці

• доступність та вартість підтримки

і Перфорс був цілком явним переможцем в цілому. git був трохи кращим для першого пункту, але невигідний для інших.

Колись, не так давно (коли IDE називали VI), єдиними безкоштовними (відкритими) системами були CVS, RCS та SCCS.

• Жоден із них навіть не міг добре впоратися з перейменованим файлом.
• Вони не фіксували злиття, тож якщо активно працювали два відділення, їх було дуже важко об'єднати, поки робота не закінчилася на одній гілці.
• Вони не масштабували дуже великі бази коду
• Вони не забезпечили рівень контролю доступу та інформаційного процесу, якого хочуть великі проекти.

Там було багато систем управління комерційним вихідним кодом, більшість із них забезпечувалась одним постачальником машин (IBM, DEC, HP тощо) і працює лише на їх апаратному забезпеченні.

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

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

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

Отже, підсумовуючи, перфорс отримав "ногу у двері", коли не було багато інших варіантів, і вони ще не зіпсувались, щоб люди могли відійти від неї .