Существует много документации "Git for Perforce users", но, похоже, совсем немного противоположного.

Я использовал 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.

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

Некоторые терминологические различия, чтобы разобраться

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

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

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

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

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

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

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

Чтобы сравнить Perforce с Git в этом отношении, с помощью Git вы выбираете и выбираете набор репозиториев 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» для получения новых ревизий с сервера; «p4 update» проверяет наличие изменений перед синхронизацией, поэтому не изменит ваши локальные изменения, если вы еще не запустили «p4 status».

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

Вопрос, который я часто получаю: «Почему вы хотите использовать явную проверку?» На первый взгляд это может показаться сумасшедшим дизайнерским решением, но явная проверка имеет некоторые существенные преимущества.

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

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

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

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

Perforce Replacements для Git-функций

• git stash ==> p4 shelve
• git local branching ==> Выполнить полки или ветви задач
• git blame==> p4 annotateили Выполнить вид замедленной съемки из графического интерфейса

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

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

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

2) Отредактируйте файлы по своему усмотрению и используйте «p4 status», чтобы сообщить Perforce, что вы сделали

Используя оба вышеупомянутых параметра, вы можете использовать параметр «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 абстракция - это патч (он же diff, он же changeset). Коммит в git по сути является результатом работыdiff между предыдущим и текущим состоянием фиксируемых файлов.
• В действии абстракция - это файл . Коммит в p4 - это полное содержимое файлов в коммите на данный момент времени. Это организовано в список изменений, но сами версии хранятся отдельно для каждого файла, а список изменений просто собирает разные версии файлов вместе.

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

Перфекты разные. Выполняемая операция ветвления скопирует файлы из одной подпапки в другую, а затем пометит связь между файлами с метаданными на сервере. Чтобы объединить файл из одной ветви в другую ( integrationв терминах перформса), Perforce будет просматривать полное содержимое файла в «заголовке» исходной ветви и полное содержимое файла в заголовке целевой ветви и при необходимости объединить с помощью общего предка. Он не может применять патчи один за другим, как 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стеллажей, файлы в локальном дереве не восстанавливаются, поэтому вы должны возвращать их отдельно).