Існує багато документації "Git для користувачів Perforce", але навпаки, дуже мало.

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

Хтось зацікавлений у складанні кількох порад щодо використання Perforce для того, хто звик до Git?

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

Вступ до Perforce для користувачів Git

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

Короткий проїзд, перш ніж ми зануримось; якщо ви віддаєте перевагу Git, ви можете досить добре використовувати Git з Perforce. Ми надаємо інструмент під назвою Git Fusion, який генерує сховища Git, які синхронізуються з сервером Perforce. Люди Git та Perforce можуть жити в гармонії, працюючи над тим самим кодом, в основному це не впливає на вибір колегами контролю версій. Git Fusions 13.3 доступний на веб-сайті Perforce . Його потрібно встановити адміністратором Perforce, але якщо встановити його, ви побачите, що його функція нарізки сховища може бути дуже зручною як користувач Git.

Якщо ви не можете переконати свого адміністратора встановити Git Fusion, Git сам постачається з прив'язкою Perforce під назвою Git-P4, яка дозволяє використовувати Git для зміни та подання файлів у робочу область Perforce. Більше інформації про це можна знайти за посиланням: https://git.wiki.kernel.org/index.php/GitP4

Досі тут? Добре, давайте подивимось на Перфорс.

Деякі термінологічні відмінності для сортування

Перш ніж розібратися в деталях, нам потрібно коротко висвітлити декілька термінологічних відмінностей між Git та Perforce.

Перший - замовлення . У Git таким чином ви отримуєте копію коду з певної гілки у вашу робочу зону. У Perforce ми називаємо це синхронізацією з командного рядка або з нашого GUI P4V "Отримати останню версію". Perforce використовує перевірку слів з P4V або p4 editз командного рядка, щоб означати, що ви плануєте змінити файл із системи контролю версій. У решті цього документа я буду використовувати каси в розумінні цього слова.

Другий - це Git commit vs Perforce submit . Де ви покладетеся на Git, ви подасте в Перфорсі. Оскільки всі операції відбуваються проти спільної служби версій Perforce, Perforce не має еквівалента для git push. Так само у нас немає pull; команда синхронізації зверху піклується про отримання файлів для нас. У Perforce немає поняття чистої локальної подачі, якщо ви не вирішите скористатися нашим інструментом P4Sandbox, описаним коротко нижче.

Основні поняття в Перфорсі

Якби я спростив Perforce до двох ключових понять, я б зосередився на депо та робочій області. Депо Perforce - це сховище файлів, що живуть на сервері Perforce. Сервер Perforce може мати будь-яку кількість депо, і кожен склад може містити будь-яку кількість файлів. Часто ви чуєте, як користувачі Perforce взаємозамінно використовують депо і сервер, але вони різні. Сайт Perforce може вибрати кілька серверів, але найчастіше всі файли знаходяться на одному сервері.

Робоча область або клієнт Perforce - це об'єкт в системі, який відображає набір файлів на сервері Perforce в розташування файлової системи користувача. Кожен користувач має робочу область для кожної машини, яку він використовує, і часто користувачі матимуть більше одного робочого простору для тієї ж машини. Найважливіша частина робочого простору - це відображення чи перегляд робочої області.

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

Щоб порівняти Perforce з Git у цьому плані, з Git ви вибираєте і вибираєте набір Git repos, який вас цікавить. Кожне репо, як правило, чітко визначене, щоб містити лише пов'язані файли. Перевагою цього є те, що з вашого боку немає конфігурації; ти робиш клонінг git з речей, які тебе цікавлять, і ти закінчив. Це особливо приємно, якщо ви працюєте лише з одним або двома сховищами. З Perforce вам потрібно витратити трохи часу на вибір і вибір потрібних бітів коду.

У багатьох магазинах Perforce використовуються потоки, які можуть автоматично генерувати перегляд робочої області, або вони генерують представлення даних за допомогою сценаріїв або робочих просторів шаблонів. Так само багато людей залишають своїх користувачів самостійно генерувати свої робочі простори. Однією з переваг можливості відображення декількох модулів в одному робочому просторі є те, що ви можете легко змінювати декілька модулів коду за одну реєстрацію; ви можете гарантувати, що кожен, хто має аналогічний перегляд клієнта, який синхронізує вашу реєстрацію, матиме весь код у правильному стані. Це також може призвести до надмірно залежного коду; примусове розділення Git може призвести до кращої модульності. На щастя, Perforce також може підтримувати сувору модульність. Це все питання про те, як ви вирішили використовувати інструмент.

Чому робочі простори?

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

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

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

Для отримання додаткової інформації про повну потужність робочих просторів Perforce читайте Налаштування P4 .

Явна перевірка проти неявного оформлення замовлення

Однією з найбільших проблем для користувачів, які переходять від Git до Perforce, є концепція явного оформлення замовлення. Якщо ви звикли до роботи Git / SVN / CVS із зміною файлів, а потім сказати системі управління версіями шукати те, що ви зробили, це може бути надзвичайно болісним переходом.

Хороша новина полягає в тому, що якщо ви вирішите, ви можете працювати з робочим процесом у стилі Git у Perforce. У Perforce ви можете встановити параметр "allwrite" на робочій області. Це скаже Perforce, що всі файли потрібно записати на диск із встановленим бітом, що можна записати. Потім ви можете змінити будь-який бажаний файл, не повідомляючи прямо Perforce. Щоб Perforce узгодив ті зміни, які ви внесли, ви можете запустити "p4 status". Він відкриє файли для додавання, редагування та видалення за необхідності. Працюючи таким чином, вам потрібно використовувати "оновлення p4", а не "p4 sync", щоб отримати нові редакції з сервера; "p4 update" перевіряє зміни, перш ніж синхронізуватись, тому не зупинить ваші локальні зміни, якщо ви ще не запустили "статус p4".

Чому явна перевірка?

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

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

Ще однією перевагою є те, що явна перевірка надає форму асинхронного спілкування, яка дозволяє розробникам знати загалом над тим, над чим працюють їхні однолітки або принаймні де. Це може дати вам знати, що ви можете уникнути роботи в певній області, щоб уникнути непотрібного конфлікту, або може попередити вас про те, що новий розробник у команді розібрався в код, який, можливо, їм не потрібен редагувати. Мій особистий досвід полягає в тому, що я, як правило, працюю або в Git, або використовую Perforce з allwrite над проектами, де я є єдиним учасником, або нечастою особою, і явно оформлюю замовлення, коли тісно співпрацюю з командою. Вдячно, вибір за вами.

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

Якщо ви використовуєте IDE для розробки, таких як Visual Studio або Eclipse, я настійно рекомендую встановити плагін Perforce для свого IDE. Більшість плагінів IDE автоматично завантажить файли, коли ви почнете їх редагувати, позбавляючи вас від необхідності робити замовлення самостійно.

Персональні заміни для функцій Git

• git stash ==> p4 shelve
• git local branching ==> або полки Perforce або гілки завдань
• git blame==> p4 annotateабо Перегляд Perforce Timelapse з графічного інтерфейсу

Робота відключена

Існує два варіанти роботи, відключеної від служби версій Perforce (це наш фантазійний термін для сервера Perforce).

1) Використовуйте P4Sandbox, щоб мати повну локальну версію та локальне розгалуження

2) Відредагуйте файли за вашим бажанням та скористайтеся "статусом p4", щоб сказати, що Ви зробили

З обома наведеними вище параметрами ви можете вибрати налаштування "allwrite" у своїй робочій області, щоб не потрібно розблокувати файли. Під час роботи в цьому режимі вам потрібно використовувати команду "p4 update" для синхронізації нових файлів замість "p4 sync". "p4 update" перевірить файли на зміни, перш ніж синхронізувати їх.

Perforce Quickstart

Усі наступні приклади будуть з командного рядка.

1) Налаштуйте своє з'єднання з Perforce

export P4USER=matt
export P4CLIENT=demo-workspace
export P4PORT=perforce:1666

Ви можете вставити ці налаштування у файл конфігурації оболонки, p4 setзберегти їх у Windows та OS X або скористатися конфігураційним файлом Perforce.

1) Створіть робочу область

p4 workspace

# set your root to where your files should live:
Root: /Users/matt/work

# in the resulting editor change your view to map the depot files you care about
//depot/main/... //demo-workspace/main/...
//depot/dev/...  //demo-workspace/dev/...

2) Отримайте файли з сервера

cd /Users/matt/work
p4 sync

3) Оформіть файл, над яким ви хочете працювати, і змініть його

p4 edit main/foo; 
echo cake >> main/foo

4) Надішліть його на сервер

p4 submit -d "A trivial edit"

5) Запустіть, p4 help simpleщоб побачити основні команди, які вам знадобляться для роботи з Perforce.

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

• У git абстракція - це патч (він також відрізняється від акаунта змін). Фіксація в git - це, по суті, результат запуску diffміж попереднім та поточним станом файлів, які виконуються .
• У виконанні абстракція - це файл . Фіксація в p4 - це повний вміст файлів у коміті на той момент часу. Це організовано у список змін, але самі редакції зберігаються на основі файлів, і список змін просто збирає різні версії файлів разом.

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

Гілки перфорсу різні. Операція гілки в perforce копіює файли з однієї підпапки в іншу, а потім позначає зв'язок між файлами з метаданими на сервері. Щоб об'єднати файл з однієї гілки в іншу ( integrationв умовах perforce), perforce буде дивитись на повний вміст файлу в 'head' у вихідній гілці та на повний вміст файла на чолі цільової гілки та при необхідності злиття, використовуючи спільного предка. Він не може застосовувати патчі один за одним, як git can, а це означає, що ручні злиття трапляються частіше (і, як правило, є більш болючими).

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

Спроба відображення команд від однієї до іншої не є правильним підходом; Концепції від централізованих проти розподілених систем контролю ревізії не однакові. Натомість я опишу типовий робочий процес у Perforce:

1. Запустіть p4 editкожен файл, який потрібно відредагувати. Вам потрібно повідомити Perforce, які файли ви редагуєте. Якщо ви додаєте нові файли, використовуйте p4 add. Якщо ви видаляєте файли, використовуйте p4 delete.
2. Внесіть зміни до коду.
3. Запустіть, p4 changeщоб створити набір змін. Тут ви можете створити опис змін і, можливо, також додати або видалити файли зі свого набору змін. Ви можете запустити p4 change CHANGE_NUMBERдля редагування опису пізніше, якщо необхідно.
4. Ви можете внести додаткові зміни коду, якщо вам потрібно. Якщо вам потрібно додати / редагувати / видалити інші файли, ви можете використовувати p4 {add,edit,delete} -c CHANGE_NUMBER FILE.
5. Запустіть, p4 syncщоб отримати останні зміни із сервера.
6. Запустити, p4 resolveщоб вирішити будь-які конфлікти від синхронізації.
7. Коли ви будете готові надіслати свої зміни, запустіть p4 submit -c CHANGE_NUMBER.

Ви можете p4 revertповернути свої зміни до файлів.

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

Якщо вам потрібно редагувати файли, які ви вже відкрили, в іншому наборі змін, ви можете створити окремий клієнт Perforce або зберегти наявний набір змін для подальшого використання через p4 shelve. (На відміну від цього git stash, стелаж не поверне файли у вашому локальному дереві, тому їх потрібно відновити окремо.)