Perforce е много популярна version-control система в корпоративните среди. Съществува от 1995 г. и това я прави най-старата от всички, които разглеждаме в тази глава. Като такава, тя е проектирана съобразно нуждите от онези времена и подразбира, че сте свързани към единичен централен сървър и само една версия се пази на локалния диск. За да сме справедливи, нейните функционалности и ограничения обслужват много добре някои специфични задачи, но на практика съществуват много проекти, които използват Perforce а биха работили много по-добре на Git.
Ако искате да съчетаете използването на Perforce и Git, налични са две опции. Първата, която ще опишем е “Git Fusion” бриджа създаден от авторите на Perforce, който ви позволява да третирате subtrees от Perforce депо като read-write Git хранилища. Втората, git-p4, е клиентски бридж, който позволява да използвате Git като Perforce клиент без да се налага каквато и да било промяна в настройките на Perforce сървъра.
Perforce предоставя продукта Git Fusion (наличен на http://www.perforce.com/git-fusion), който синхронизира Perforce сървър с Git хранилища от страна на сървъра.
За нашите примери ще използваме най-лесния метод за инсталиране на Git Fusion, виртуална машина, в която работят Perforce демона и Git Fusion. Можете да свалите имидж за виртуалната машина от http://www.perforce.com/downloads/Perforce/20-User, и след това да го стартирате в предпочитания от вас виртуализационен софтуер (в случая ползваме VirtualBox).
След стартирането си, виртуалната машина изисква задаване на пароли за три Linux потребителя (root, perforce и git) и предоставя име на инстанцията, което може да се използва за различаване на конкретната инсталация от другите в същата мрежа.
Когато всичко това приключи ще видите следното:
Запомнете показания тук IP адрес, ще го ползваме по-късно.
След това, ще създадем потребител за Perforce.
Изберете опцията “Login” в долния край на екрана и натиснете enter (или влезте в машината през SSH), след това влезте като root.
След това изпълнете тези команди, за да създадете новия потребител:
$ p4 -p localhost:1666 -u super user -f john
$ p4 -p localhost:1666 -u john passwd
$ exitПървата ще отвори редактора Vi за настройка на потребителя, можете да приемете настройките по подразбиране изпълнявайки :wq и enter.
Следващата команда ще ви пита два пъти за паролата.
Това е всичко, което правим в конзолата, така че можете да излезете от сесията.
Следващото нещо, което следва да направим, е да кажем на Git да не проверява SSL сертификатите. Виртуалната машина на Git Fusion идва със сертификат за домейн, който няма да съвпада с IP адреса на виртуалната машина и Git ще отхвърля HTTPS връзката. Ако това ще бъде перманентна инсталация, можете да погледнете документацията на Git Fusion и да видите как да инсталирате различен сертификат. За целите на демонстрацията това няма да е нужно:
$ export GIT_SSL_NO_VERIFY=trueСега можем да тестваме дали всичко работи.
$ git clone https://10.0.1.254/Talkhouse
Cloning into 'Talkhouse'...
Username for 'https://10.0.1.254': john
Password for 'https://john@10.0.1.254':
remote: Counting objects: 630, done.
remote: Compressing objects: 100% (581/581), done.
remote: Total 630 (delta 172), reused 0 (delta 0)
Receiving objects: 100% (630/630), 1.22 MiB | 0 bytes/s, done.
Resolving deltas: 100% (172/172), done.
Checking connectivity... done.Имиджът идва с инсталиран примерен проект, който може да се клонира.
Тук клонираме през HTTPS като потребител john, който създадохме преди малко. Git ще пита за име и парола за конекцията първия път, но после credential кешът ще ви спести това неудобство.
След като имате инсталиран Git Fusion, ще променим леко конфигурацията.
Това е сравнително лесно с предпочитания от вас Perforce клиент, просто асоциирайте //.git-fusion директорията на Perforce сървъра в работното си пространство.
Файловата структура изглежда така:
$ tree
.
├── objects
│ ├── repos
│ │ └── [...]
│ └── trees
│ └── [...]
│
├── p4gf_config
├── repos
│ └── Talkhouse
│ └── p4gf_config
└── users
└── p4gf_usermap
498 directories, 287 filesДиректорията objects се използва служебно от Git Fusion за асоцииране на Perforce обекти с Git и обратно, няма да се налага да пипате нищо в нея.
В нея има глобален p4gf_config файл, както и по един такъв за всяко хранилище — това са конфигурационните файлове, които определят поведението на Git Fusion.
Нека видим файла в главната директория:
[repo-creation]
charset = utf8
[git-to-perforce]
change-owner = author
enable-git-branch-creation = yes
enable-swarm-reviews = yes
enable-git-merge-commits = yes
enable-git-submodules = yes
preflight-commit = none
ignore-author-permissions = no
read-permission-check = none
git-merge-avoidance-after-change-num = 12107
[perforce-to-git]
http-url = none
ssh-url = none
[@features]
imports = False
chunked-push = False
matrix2 = False
parallel-push = False
[authentication]
email-case-sensitivity = noНяма да задълбаваме в подробности за всички флагове тук, просто отбележете, че това е INI-форматиран текстов файл, подобен на тези, които и Git използва за конфигурации.
Този файл задава глобалните опции, които могат да бъдат презаписани от съответния файл в конкретно хранилище като например repos/Talkhouse/p4gf_config.
Ако отворите подобен такъв, ще видите секцията [@repo] с няколко настройки, които се различават от глобалните.
Ще видите и секции като:
[Talkhouse-master]
git-branch-name = master
view = //depot/Talkhouse/main-dev/... ...Това е мапинг между Perforce клон и Git клон.
Тази секция може да се казва както желаете, стига да е уникална.
git-branch-name позволява да конвертирате пътя на депо, който може да е объркващ под Git към нещо по-разбираемо.
Настройката view определя как Perforce файловете се съотнасят в Git хранилището, използва се стандартния view mapping синтаксис.
Както е видно, може да се задава повече от един мапинг:
[multi-project-mapping]
git-branch-name = master
view = //depot/project1/main/... project1/...
//depot/project2/mainline/... project2/...По този начин, ако нормалният ви workspace мапинг включва промени в структурата на директориите, може да ги отразите в Git хранилището.
Последният файл, на който обръщаме внимание е users/p4gf_usermap, който съотнася Perforce потребители на Git потребители, и от който може въобще да не се нуждаете.
Когато конвертира от Perforce changeset към Git къмит, Get Fusion по подразбиране ще потърси Perforce потребителя и ще използва имейл адреса и пълното му име за съответните author/committer полета в Git.
В обратната посока, подразбиращото се поведение е да се потърси Perforce потребител с имейл адрес съответстващ на author полето на Git къмита и changeset-а да се запише като направен от този потребител (като се вземат предвид и правата за достъп).
В повечето случаи тази схема работи коректно, но погледнете този мапинг файл:
john john@example.com "John Doe"
john johnny@appleseed.net "John Doe"
bob employeeX@example.com "Anon X. Mouse"
joe employeeY@example.com "Anon Y. Mouse"Всеки ред следва формата <user> <email> "<full name>" и дефинира единично съответствие за потребител.
Първите две полета асоциират два отделни имейл адреса с един и същи Perforce потребителски акаунт.
Това е полезно, ако сте създали Git къмити с различни имейл адреси (или пък сте сменили адреса), но искате да ги присъедините към същия Perforce потребител.
Когато създавате Git къмит от Perforce changeset, първият ред съответстващ на Perforce потребителя се използва за попълване на информацията за автора в Git.
Последните два реда маскират действителните имена и имейл адреси на Bob и Joe, от създадените Git къмити. Това е хубаво, в случай че решите да отворите кода на вътрешен проект, но не искате да разкриете списъка с разработчици в компанията ви на останалия свят. Запомнете, че имейл адресите и пълните имена трябва да са уникални, освен ако не искате всички Git къмити да са с фиктивен единичен автор.
Git Fusion е двупосочен бридж между Perforce и Git. Да видим как изглежда работата от гледната точка на Git. Ще допуснем, че сме асоциирали проекта “Jam” с конфигурационен файл като показания по-горе. Клонираме го така:
$ git clone https://10.0.1.254/Jam
Cloning into 'Jam'...
Username for 'https://10.0.1.254': john
Password for 'https://john@10.0.1.254':
remote: Counting objects: 2070, done.
remote: Compressing objects: 100% (1704/1704), done.
Receiving objects: 100% (2070/2070), 1.21 MiB | 0 bytes/s, done.
remote: Total 2070 (delta 1242), reused 0 (delta 0)
Resolving deltas: 100% (1242/1242), done.
Checking connectivity... done.
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/rel2.1
$ git log --oneline --decorate --graph --all
* 0a38c33 (origin/rel2.1) Create Jam 2.1 release branch.
| * d254865 (HEAD, origin/master, origin/HEAD, master) Upgrade to latest metrowerks on Beos -- the Intel one.
| * bd2f54a Put in fix for jam's NT handle leak.
| * c0f29e7 Fix URL in a jam doc
| * cc644ac Radstone's lynx port.
[...]Първият път, когато направите това, може да отнеме повече време. Това, което се случва е, че Git Fusion конвертира всички приложими changesets в Perforce историята в Git къмити. Това се случва локално на сървъра, така че е сравнително бързо, но все пак зависи от мащаба на историята. Последващите изтегляния правят инкрементално конвертиране, така че наподобяват скоростта на Git, с която сме свикнали.
Както може да видите, хранилището ни изглежда точно като всяко друго с Git.
Имаме три клона и Git услужливо е създал локален master клон, който проследява origin/master.
Нека направим малко промени и създадем няколко къмита:
# ...
$ git log --oneline --decorate --graph --all
* cfd46ab (HEAD, master) Add documentation for new feature
* a730d77 Whitespace
* d254865 (origin/master, origin/HEAD) Upgrade to latest metrowerks on Beos -- the Intel one.
* bd2f54a Put in fix for jam's NT handle leak.
[...]Сега имаме два нови къмита. Следва да проверим дали някой друг колега не е публикувал нови промени:
$ git fetch
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://10.0.1.254/Jam
d254865..6afeb15 master -> origin/master
$ git log --oneline --decorate --graph --all
* 6afeb15 (origin/master, origin/HEAD) Update copyright
| * cfd46ab (HEAD, master) Add documentation for new feature
| * a730d77 Whitespace
|/
* d254865 Upgrade to latest metrowerks on Beos -- the Intel one.
* bd2f54a Put in fix for jam's NT handle leak.
[...]Изглежда има такива.
От този изглед няма как да разберете това, но къмитът 6afeb15 е създаден в действителност от Perforce клиент.
От гледна точка на Git, този къмит изглежда като нормален Git къмит и точно това е идеята.
Нека да видим как Perforce сървърът управлява merge къмит:
$ git merge origin/master
Auto-merging README
Merge made by the 'recursive' strategy.
README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
$ git push
Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 917 bytes | 0 bytes/s, done.
Total 9 (delta 6), reused 0 (delta 0)
remote: Perforce: 100% (3/3) Loading commit tree into memory...
remote: Perforce: 100% (5/5) Finding child commits...
remote: Perforce: Running git fast-export...
remote: Perforce: 100% (3/3) Checking commits...
remote: Processing will continue even if connection is closed.
remote: Perforce: 100% (3/3) Copying changelists...
remote: Perforce: Submitting new Git commit objects to Perforce: 4
To https://10.0.1.254/Jam
6afeb15..89cba2b master -> masterСпоред Git нещата работят.
Нека видим историята на README файла от гледната точка на Perforce с revision graph опцията на p4v:
Ако никога преди не сте виждали такъв изглед, той може да изглежда смущаващо, но показва същите концепции както графичния инструмент на Git за разглеждане на историята.
Ние гледаме историята на файла README така че дървото горе вляво показва само него както се вижда в различните клонове.
Горе вдясно виждаме как се свързват различните версии на файла, а общата картина на тази графика е долу вдясно.
Останалата част от картинката е за детайлите на избраната версия (2 в този случай).
Едно от нещата, които се виждат е, че графиката изглежда точно както тази в Git историята.
Perforce няма именуван клон за съхранение на къмитите 1 и 2, така че е създал “anonymous” клон в директорията .git-fusion за тях.
Същото ще се случи за именувани Git клонове, които не съвпадат с именувани Perforce клонове (и после можете да ги мапнете към Perforce клон с конфигурационния файл).
Повечето от това се случва задкулисно, но крайният резултат е, че един човек в екипа може да използва Git, друг Perforce и нито един от тях няма да знае за избора на другия.
Ако имате достъп (или може да получите такъв) към вашия Perforce сървър, Git Fusion е чудесен начин да накарате Git и Perforce да си сътрудничат. Има известна работа по конфигурацията, но като цяло не е толкова сложно. Това е една от малкото секции в тази глава, в които няма да видите предупреждения за използването на пълната сила на Git. Това не означава, че Perforce ще е щастлив с всичко, което му изпратите — ако се опитате да промените история, която вече е била публикувана, Git Fusion ще откаже това, но иначе се опитва да бъде максимално близък до Git. Можете дори да използвате Git модули (въпреки, че те ще изглеждат странно за Perforce потребителите) и да сливате клонове (това ще се запише като integration от страната на Perforce).
Ако не успеете да убедите администратора на сървъра ви да инсталира Git Fusion, все пак съществува възможност да използвате двете системи заедно.
Git-p4 е двупосочен бридж между Git и Perforce. Той работи изцяло във вашето Git хранилище, така че не ви трябва никакъв достъп до Perforce сървър (като изключим потребителските име и парола, разбира се). Git-p4 не е толкова гъвкаво и пълно решение като Git Fusion, но ви позволява да правите повечето неща, които бихте желали, без да се налага да пипате по сървъра.
|
Note
|
Трябва да поставите |
За целите на примерите, ще използваме Perforce сървъра от Git Fusion OVA както е показано по-горе, но ще заобикаляме Git Fusion сървъра и ще комуникираме директно с Perforce version control системата.
За да използваме p4 конзолния клиент (от който зависи работата на git-p4), трябва да настроим няколко променливи на обкръжението:
$ export P4PORT=10.0.1.254:1666
$ export P4USER=johnКакто всичко в Git, първата команда е за клониране:
$ git p4 clone //depot/www/live www-shallow
Importing from //depot/www/live into www-shallow
Initialized empty Git repository in /private/tmp/www-shallow/.git/
Doing initial import of //depot/www/live/ from revision #head into refs/remotes/p4/masterТова създава, според терминологията на Git, “shallow” копие; само последната Perforce версия се импортира в Git; спомнете си, че Perforce не е проектиран да предоставя всяка версия на всеки потребител. Това е достатъчно да използваме Git като Perforce клиент, но за други цели не е.
След края на командата, имаме пълнофункционално Git хранилище:
$ cd myproject
$ git log --oneline --all --graph --decorate
* 70eaf78 (HEAD, p4/master, p4/HEAD, master) Initial import of //depot/www/live/ from the state at revision #headВиждаме, че съществува отдалечена “p4” референция към Perforce сървъра, но всичко друго изглежда като стандартно клонирано копие. В действителност това е малко заблуждаващо, защото такава отдалечена референция не съществува тук.
$ git remote -vНе се показват никакви отдалечени референции.
Git-p4 е създал няколко референции за да пресъздаде статуса на сървъра и за git log те изглеждат като отдалечени такива. Обаче не се управляват от Git и не можете да публикувате в тях.
Нека да направим малко промени. Допускаме, че сте постигнали напредък по много важна функционалност и сте готови са я споделите с екипа.
$ git log --oneline --all --graph --decorate
* 018467c (HEAD, master) Change page title
* c0fb617 Update link
* 70eaf78 (p4/master, p4/HEAD) Initial import of //depot/www/live/ from the state at revision #headИмаме два нови къмита и искаме да ги изпратим на Perforce сървъра. Проверяваме за междувременно въведени промени от някой друг:
$ git p4 sync
git p4 sync
Performing incremental import into refs/remotes/p4/master git branch
Depot paths: //depot/www/live/
Import destination: refs/remotes/p4/master
Importing revision 12142 (100%)
$ git log --oneline --all --graph --decorate
* 75cd059 (p4/master, p4/HEAD) Update copyright
| * 018467c (HEAD, master) Change page title
| * c0fb617 Update link
|/
* 70eaf78 Initial import of //depot/www/live/ from the state at revision #headИзглежда, че такива има и клоновете master и p4/master са разделени.
Системата за клонове на Perforce няма нищо общо с тази на Git, така че изпращането на merge къмити няма никакъв смислъл.
Git-p4 препоръчва да пребазирате къмитите си и дори предлага кратък път за това:
$ git p4 rebase
Performing incremental import into refs/remotes/p4/master git branch
Depot paths: //depot/www/live/
No changes to import!
Rebasing the current branch onto remotes/p4/master
First, rewinding head to replay your work on top of it...
Applying: Update link
Applying: Change page title
index.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)Вероятно и сами сте забелязали от резултата, но все пак да кажем, че git p4 rebase е съкратен вариант на git p4 sync последвана от git rebase p4/master.
Командата дори е една идея по-умна, особено при работа с много клонове, но засега това ни е достатъчно.
Сега историята ни отново е линейна и сме готови да изпратим промените си към Perforce.
Командата git p4 submit ще се опита да създаде нова Perforce ревизия за всеки Git къмит между p4/master и master.
Изпълнението ѝ ще ни отвори текстовия редактор със следното съдържание:
# A Perforce Change Specification.
#
# Change: The change number. 'new' on a new changelist.
# Date: The date this specification was last modified.
# Client: The client on which the changelist was created. Read-only.
# User: The user who created the changelist.
# Status: Either 'pending' or 'submitted'. Read-only.
# Type: Either 'public' or 'restricted'. Default is 'public'.
# Description: Comments about the changelist. Required.
# Jobs: What opened jobs are to be closed by this changelist.
# You may delete jobs from this list. (New changelists only.)
# Files: What opened files from the default changelist are to be added
# to this changelist. You may delete files from this list.
# (New changelists only.)
Change: new
Client: john_bens-mbp_8487
User: john
Status: new
Description:
Update link
Files:
//depot/www/live/index.html # edit
######## git author ben@straub.cc does not match your p4 account.
######## Use option --preserve-user to modify authorship.
######## Variable git-p4.skipUserNameCheck hides this message.
######## everything below this line is just the diff #######
--- //depot/www/live/index.html 2014-08-31 18:26:05.000000000 0000
+++ /Users/ben/john_bens-mbp_8487/john_bens-mbp_8487/depot/www/live/index.html 2014-08-31 18:26:05.000000000 0000
@@ -60,7 +60,7 @@
</td>
<td valign=top>
Source and documentation for
-<a href="http://www.perforce.com/jam/jam.html">
+<a href="jam.html">
Jam/MR</a>,
a software build tool.
</td>Това в голямата си част е същото съдържание, което ще видите при изпълнение на p4 submit, с изключение на нещата в края, които git-p4 услужливо е вмъкнала.
Git-p4 се опитва да съблюдава вашите Git и Perforce настройки индивидуално, когато трябва да даде име за къмит или changeset, но в някои случаи ще искате да го редактирате.
Например, ако Git къмитът, който импортирате, е бил създаден от потребител, който няма Perforce потребителски акаунт, може все още да искате полученият changeset да изглежда така сякаш е създаден от този потребител (не от вас).
Git-p4 удобно е вмъкнал съобщението от Git къмита като съдържание за този Perforce changeset, така че просто трябва да запишем и да излезем, два пъти (по веднъж за всеки къмит). Резултатът на екрана ще изглежда подобно:
$ git p4 submit
Perforce checkout for depot path //depot/www/live/ located at /Users/ben/john_bens-mbp_8487/john_bens-mbp_8487/depot/www/live/
Synchronizing p4 checkout...
... - file(s) up-to-date.
Applying dbac45b Update link
//depot/www/live/index.html#4 - opened for edit
Change 12143 created with 1 open file(s).
Submitting change 12143.
Locking 1 files ...
edit //depot/www/live/index.html#5
Change 12143 submitted.
Applying 905ec6a Change page title
//depot/www/live/index.html#5 - opened for edit
Change 12144 created with 1 open file(s).
Submitting change 12144.
Locking 1 files ...
edit //depot/www/live/index.html#6
Change 12144 submitted.
All commits applied!
Performing incremental import into refs/remotes/p4/master git branch
Depot paths: //depot/www/live/
Import destination: refs/remotes/p4/master
Importing revision 12144 (100%)
Rebasing the current branch onto remotes/p4/master
First, rewinding head to replay your work on top of it...
$ git log --oneline --all --graph --decorate
* 775a46f (HEAD, p4/master, p4/HEAD, master) Change page title
* 05f1ade Update link
* 75cd059 Update copyright
* 70eaf78 Initial import of //depot/www/live/ from the state at revision #headИзглежда сякаш сме изпълнили git push, най-близкия аналог на това, което реално стана.
По време на този процес всеки Git къмит се превръща в Perforce changeset; ако искате да ги съчетаете в единичен changeset, може да го направите с интерактивно пребазиране преди да изпълните git p4 submit.
Също така отбележете, че SHA-1 хешовете на всички изпратени като changesets къмити са променени, това е защото git-p4 добавя по ред в края на всеки конвертиран къмит:
$ git log -1
commit 775a46f630d8b46535fc9983cf3ebe6b9aa53145
Author: John Doe <john@example.com>
Date: Sun Aug 31 10:31:44 2014 -0800
Change page title
[git-p4: depot-paths = "//depot/www/live/": change = 12144]Какво се случва, ако опитате да изпратите merge къмит? Нека опитаме. Ето ситуацията, в която попадаме:
$ git log --oneline --all --graph --decorate
* 3be6fd8 (HEAD, master) Correct email address
* 1dcbf21 Merge remote-tracking branch 'p4/master'
|\
| * c4689fc (p4/master, p4/HEAD) Grammar fix
* | cbacd0a Table borders: yes please
* | b4959b6 Trademark
|/
* 775a46f Change page title
* 05f1ade Update link
* 75cd059 Update copyright
* 70eaf78 Initial import of //depot/www/live/ from the state at revision #headИсторията на Git и Perforce се разделя след 775a46f. Git страната има два къмита, след това merge къмит с Perforce head, и след това още един къмит. Ще се опитаме да изпратим всичко това върху единичен changeset от Perforce страната. Какво се случва, ако опитаме да публикуваме:
$ git p4 submit -n
Perforce checkout for depot path //depot/www/live/ located at /Users/ben/john_bens-mbp_8487/john_bens-mbp_8487/depot/www/live/
Would synchronize p4 checkout in /Users/ben/john_bens-mbp_8487/john_bens-mbp_8487/depot/www/live/
Would apply
b4959b6 Trademark
cbacd0a Table borders: yes please
3be6fd8 Correct email addressФлагът -n е съкратено за --dry-run и се опитва да докладва какво би се случило, ако submit командата беше реална.
В този случай, изглежда че ще се опитаме да създадем три Perforce changeset-а, съответстващи на трите non-merge къмита, които все още не съществуват на Perforce сървъра.
Звучи като това, което искаме — нека изпълним реалната команда:
$ git p4 submit
[…]
$ git log --oneline --all --graph --decorate
* dadbd89 (HEAD, p4/master, p4/HEAD, master) Correct email address
* 1b79a80 Table borders: yes please
* 0097235 Trademark
* c4689fc Grammar fix
* 775a46f Change page title
* 05f1ade Update link
* 75cd059 Update copyright
* 70eaf78 Initial import of //depot/www/live/ from the state at revision #headИсторията ни стана линейна, точно както ако бяхме пребазирали преди публикуването (което в действителност е реалният резултат). Това значи, че може да се чувствате свободни да създавате, работите, изтривате и сливате клонове локално в Git без да се тревожите, че историята ви ще стане несъвместима с Perforce. Всичко, което можете да пребазирате, може да се изпрати към Perforce сървъра.
Ако вашият Perforce проект има много клонове, не е страшно, git-p4 може да се справи с тази ситуация по начин, по който сте свикнали с Git. Нека кажем, че вашето Perforce депо изглежда така:
//depot
└── project
├── main
└── devИ нека приемем, че имате dev клон с view spec подобен на това:
//depot/project/main/... //depot/project/dev/...Git-p4 може автоматично да установи ситуацията и да направи правилното:
$ git p4 clone --detect-branches //depot/project@all
Importing from //depot/project@all into project
Initialized empty Git repository in /private/tmp/project/.git/
Importing revision 20 (50%)
Importing new branch project/dev
Resuming with change 20
Importing revision 22 (100%)
Updated branches: main dev
$ cd project; git log --oneline --all --graph --decorate
* eae77ae (HEAD, p4/master, p4/HEAD, master) main
| * 10d55fb (p4/project/dev) dev
| * a43cfae Populate //depot/project/main/... //depot/project/dev/....
|/
* 2b83451 Project initОтбележете “@all” указателя в пътя на депото, той казва на git-p4 да клонира не само най-новия changeset за това под-дърво, но също и всички changesets, които някога са докосвали тези пътища. Това е близко до концепцията на Git за клон, но може да отнеме време при проекти с голяма история.
Флагът --detect-branches казва на git-p4 да използва branch-спецификациите на Perforce за да мапва клоновете с Git референции.
Ако тези мапинги не са налични на Perforce сървъра (което е съвсем валиден начин за използване на Perforce), можете вие да кажете на git-p4 какви са мапингите и ще получите същия резултат:
$ git init project
Initialized empty Git repository in /tmp/project/.git/
$ cd project
$ git config git-p4.branchList main:dev
$ git clone --detect-branches //depot/project@all .Ако за конфигурационната променлива git-p4.branchList зададем стойност main:dev, това казва на git-p4, че “main” и “dev” са клонове и че вторият произлиза от първия.
Ако сега изпълним git checkout -b dev p4/project/dev и направим няколко къмита, git-p4 е достатъчно умен да определи кой е правилния клон при изпълнение на git p4 submit.
За съжаление, git-p4 не може да смесва shallow копия и множество клонове, ако имате голям проект и искате да работите по повече от един клон, ще трябва да изпълните git p4 clone по веднъж за всеки клон, в който искате да публикувате.
За създаването и интеграцията на клонове ще трябва да използвате Perforce клиент. Git-p4 може да синхронизира и публикува към съществуващи клонове и само с един линеен changeset в даден момент. Ако слеете два клона в Git и се опитате да публикувате новия changeset, всичко което ще бъде записано ще множество файлови промени, метаданните с информация за това кои клонове са участвали в интеграцията, ще бъдат загубени.
Инструментът Git-p4 прави възможно използването на Git работен процес при работа с Perforce сървър и е добър в това. Обаче, важно е да се помни, че Perforce обработва сорс кода и Git се използва само за локална работа. Просто бъдете наистина внимателни при споделяне на Git къмити, ако имате отдалечена референция ползвана и от други хора, не публикувайте никакви къмити, които преди това не са изпратени към Perforce сървъра.
Ако искате свободно да смесвате използването на Perforce и Git като клиенти за сорс контрол и ако успеете да убедите системния ви администратор да го инсталира, то Git Fusion превръща Git в първокласен version-control клиент за Perforce сървър.