Perforce для пользователей Git?

Question

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

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

Кому-то интересно собрать несколько советов по использованию Perforce для тех, кто привык к Git?

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы сравнить Perforce с Git в этом отношении, с Git вы выбираете набор Git-репозиций, который вас интересует. Каждое репо обычно ограничено областью, содержащей только связанные файлы. Преимущество этого заключается в том, что с вашей стороны не требуется настройка; вы делаете git clone того, что вам нужно, и все готово. Это особенно приятно, если вы работаете только с одним или двумя репозиториями. С Perforce вам нужно потратить немного времени на выбор и выбирая нужные фрагменты кода.

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

Почему рабочие пространства?

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

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

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

Дополнительную информацию о полной мощности рабочих мест Perforce читайте Configuring 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 будут автоматически проверять файлы, когда вы начнете их редактировать, освобождая вас от необходимости самостоятельно делать чек.

неволей Замены для Git Особенности

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

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

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

1) Использование P4Sandbox иметь полный локальный контроль версий и местных разветвлений

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

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

неволей 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.

Answer 2

Существует, вероятно, не так много документации, поскольку 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, стеллажи не возвращают файлы в вашем локальном дереве, поэтому вы должны их отменить отдельно.)

Answer 3

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

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

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

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