Ответ 1

Это то, над чем я работал в последние пару недель. Он все еще развивается, но может быть полезно. Обратите внимание, что я сотрудник Perforce.

Вступление к Perforce для пользователей Git

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

Один короткий объезд перед погружением; если вы предпочитаете Git, вы можете использовать Git с Perforce достаточно хорошо. Мы предоставляем инструмент под названием Git Fusion, который генерирует репозитории Git, которые хранятся в синхронизации с сервером Perforce. Git и люди Perforce могут жить в гармонии, работая над одним и тем же кодом, в основном не затрагивая их коллегами выбор контроля версий. Git Сплавки 13.3 доступны на веб-сайте Perforce. Он должен быть установлен администратором Perforce, но если вы его установите, вы обнаружите, что его функция репозитория может быть весьма удобна как пользователь Git.

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

Еще здесь? Хорошо, давайте посмотрим на Perforce.

Некоторые терминологические различия для сортировки

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

Первая проверка. В Git так получается, что вы получаете копию кода из данной ветки в свою рабочую зону. В Perforce мы называем это синхронизацией из командной строки или из нашего графического интерфейса P4V "Получить последний вариант". Perforce использует слово checkout из P4V или p4 edit из командной строки, что означает, что вы планируете изменить файл из системы управления версиями. В остальной части этого документа я буду использовать checkout в смысле Perforce этого слова.

Вторая Git фиксация по сравнению с Perforce submit. Где вы будете совершать в Git, вы отправите в Perforce. Поскольку все операции происходят с общим сервисом управления версиями Perforce, Perforce не имеет эквивалента для git push. Аналогично, мы не имеем a pull; команда sync сверху заботится о получении файлов для нас. В Perforce нет концепции чистой локальной отправки, если вы не решите использовать наш инструмент P4Sandbox, описанный ниже.

Ключевые понятия в Perforce

Если бы я упростил 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" . Он будет открывать файлы для добавления, редактирования и удаления по мере необходимости. При работе таким образом вы захотите использовать "p4 update" вместо "p4 sync" для получения новых версий с сервера; "Обновление p4" проверяет изменения перед синхронизацией, поэтому не будет сжимать ваши локальные изменения, если вы еще не выполнили "статус p4" .

Почему явная проверка?

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

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

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

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

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

Замена Perforce для Git Особенности

• git stash == > p4 shelve
• git локальное ветвление == > либо полки Perforce, либо ветки задач
• git blame == > p4 annotate или Perforce Timelapse View из графического интерфейса

Работа отключена

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

1) Используйте P4Sandbox для полного локального управления версиями и локального разветвления

2) Редактируйте файлы, как вам угодно, и используйте "статус p4" , чтобы сообщить Perforce, что вы сделали.

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

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.

Ответ 2

Вероятно, не так много такой документации, потому что Perforce - довольно традиционная система контроля версий (ближе к CVS, Subversion и т.д.) и обычно считается менее сложной, чем современные распределенные системы контроля версий.

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

• Запустите p4 edit для каждого файла, который вы хотите отредактировать. Вам нужно сообщить Perforce, какие файлы вы редактируете. Если вы добавляете новые файлы, используйте p4 add. Если вы удаляете файлы, используйте p4 delete.
• Внесите изменения в свой код.
• Запустите p4 change, чтобы создать набор изменений. Здесь вы можете создать описание своих изменений и, возможно, добавить или удалить файлы из своего набора изменений. Вы можете запустить p4 change CHANGE_NUMBER, чтобы изменить описание позже, если это необходимо.
• Вы можете внести дополнительные изменения кода, если вам нужно. Если вам нужно добавить/отредактировать/удалить другие файлы, вы можете использовать p4 {add,edit,delete} -c CHANGE_NUMBER FILE.
• Запустите p4 sync, чтобы извлечь последние изменения с сервера.
• Запустите p4 resolve, чтобы разрешить любые конфликты при синхронизации.
• Когда вы готовы отправить свое изменение, запустите p4 submit -c CHANGE_NUMBER.

Вы можете использовать p4 revert для возврата изменений в файлы.

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

Если вам нужно отредактировать файлы, которые вы уже открыли в другом наборе изменений, вы можете либо создать отдельный клиент Perforce, либо позже вы можете закрепить свой существующий набор изменений через p4 shelve. (В отличие от git stash, стеллажи не возвращают файлы в вашем локальном дереве, поэтому вы должны отменить их отдельно.)

Ответ 3

Самое большое различие между git и p4, к которому не относится ни один из существующих ответов, заключается в том, что они используют разные единицы абстракции.

• В git абстракция - это патч (aka diff, aka changeet). Конец в git - это, по существу, вывод запуска diff между предыдущим и текущим состоянием файлов, которые были совершены.
• В perforce абстракция - это файл. Конец в p4 - это полное содержимое файлов в фиксации в этот момент времени. Это организовано в список изменений, но сами ревизии хранятся на основе каждого файла, и список изменений просто собирает разные версии файлов вместе.

Все остальное вытекает из этой разницы. Ветвление и слияние в git является безболезненным, поскольку с точки зрения абстракции git каждый файл может быть полностью восстановлен путем применения набора патчей по порядку и, следовательно, для объединения двух ветвей вам просто нужно применить все исправления на ветке источника, которые не присутствуют в целевой ветки на целевую ветвь в правильном порядке (при условии, что на обеих ветвях нет перекрытий).

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