git-p4 - وارد
کردن از و
ارسال به
مخازن Perforce
git p4 clone [<گزینههای-همگامسازی>] [<گزینههای-شبیهسازی>] <مسیر-انبار-p4>...
git p4 sync [<گزینههای-همگامسازی>] [<مسیر-انبار-p4>...]
git p4 rebase
git p4 submit [<گزینههای-ارسال>] [<نام-شاخه-اصلی>]
این دستور
راهکاری
برای تعامل
با مخازن p4
با استفاده
از گیت
فراهم
میکند.
با
استفاده از
git p4 clone و دادن
یک یا چند
مسیر انبار
(depot) p4 به آن، یک
مخزن گیت
جدید از یک
مخزن موجود p4
بسازید.
کامیتهای
جدید ناشی
از تغییرات p4
را با
استفاده از
git p4 sync ادغام و
وارد کنید.
دستور sync
همچنین
برای
افزودن
شاخههای
جدید از
سایر
مسیرهای
انبار p4
استفاده
میشود.
تغییرات
گیت را با
استفاده از
git p4 submit به p4
برگردانید
و ارسال
کنید. دستور
git p4 rebase یک
عملیات sync به
علاوه
بازنشانی
پایه (rebase) شاخه
کنونی روی
شاخه
دوردست
بهروزشدهٔ
p4 انجام
میدهد.
•شبیهسازی
یک مخزن:
$ git p4 clone //depot/path/project
•انجام
مقداری کار
در مخزن گیت
تازه ایجاد
شده:
$ cd project
$ vi foo.h
$ git commit -a -m "edited foo.h"
•بهروزرسانی
مخزن گیت با
تغییرات
اخیر از p4، و
بازنشانی
پایهٔ (rebase) کار
شما روی آن:
•ارسال
کامیتهای
شما به p4:
به طور
کلی، git p4 clone
برای ایجاد
یک
دایرکتوری
گیت جدید از
یک مخزن
موجود p4
استفاده
میشود:
$ git p4 clone //depot/path/project
این کار:
1.یک مخزن
خالی گیت در
یک
زیردایرکتوری
به نام project
ایجاد
میکند.
2.محتوای
کامل نسخهٔ
سر (head revision) را از
مسیر انبار p4
دادهشده
به صورت یک
تککامیت
در شاخه گیت
refs/remotes/p4/master وارد
میکند.
3.یک شاخه
محلی به نام
master از این
شاخهٔ
دوردست
ایجاد کرده
و آن را
تحویل (checkout)
میگیرد.
برای
بازتولید
تمام
تاریخچه p4 در
گیت، از
تغییردهندهٔ
@all در مسیر
انبار
استفاده
کنید:
$ git p4 clone //depot/path/project@all
همانطور
که توسعه در
مخزن p4 ادامه
مییابد،
آن تغییرات
را میتوان
با استفاده
از دستور
زیر در مخزن
گیت
گنجاند:
این دستور
تغییرات
جدید را در p4
پیدا کرده و
آنها را به
عنوان
کامیتهای
گیت وارد
میکند.
مخازن p4 را
میتوان با
استفاده از
git p4 sync به یک
مخزن موجود
گیت نیز
افزود:
$ mkdir repo-git
$ cd repo-git
$ git init
$ git p4 sync //path/in/your/perforce/depot
این کار
انبار
مشخصشده
را در refs/remotes/p4/master
در یک مخزن
موجود گیت
وارد
میکند.
گزینهٔ --branch
میتواند
برای تعیین
یک شاخهٔ
متفاوت جهت
استفاده
برای
محتوای p4 به
کار رود.
اگر یک
مخزن گیت
شامل
شاخههای
refs/remotes/origin/p4 باشد،
این
شاخهها در
طول یک
عملیات git p4 sync
ابتدا
واکشی شده و
مورد ارجاع
قرار
میگیرند.
از آنجا که
وارد کردن
مستقیم از p4
به مراتب
کندتر از
واکشی
تغییرات از
یک مخزن
دوردست گیت
است، این
قابلیت
میتواند
در یک محیط
با چند
توسعهدهنده
مفید باشد.
اگر چندین
شاخه وجود
داشته
باشد،
اجرای git p4 sync به
طور خودکار
از
الگوریتم
«تشخیص
شاخه» (BRANCH DETECTION)
برای تلاش
جهت تفکیک
تغییرات
جدید به
شاخه درست
استفاده
میکند. این
رفتار را
میتوان با
گزینهٔ --branch
لغو کرد تا
تنها یک
شاخه برای
بهروزرسانی
مشخص شود.
یک الگوی
کاری رایج،
واکشی
آخرین
تغییرات از
انبار p4 و
ادغام
آنها با
تغییرات
محلی
ثبتنشده
(uncommitted) است. اغلب
اوقات،
مخزن p4 مکان
نهایی تمام
کدها است،
از این رو یک
گردش کار
بازنشانی
پایه (rebase)
منطقی به
نظر میرسد.
این دستور
یک git p4 sync و به
دنبال آن یک
git rebase را اجرا
میکند تا
کامیتهای
محلی را به
بالای
تغییرات
بهروزشدهٔ
p4 منتقل کند.
ارسال
تغییرات از
یک مخزن گیت
به مخزن p4
نیازمند یک
فضای کاری
کلاینت (client workspace)
مجزای p4 است.
این مورد
باید با
استفاده از
متغیر
محیطی P4CLIENT یا
متغیر
پیکربندی
گیت git-p4.client
مشخص شود.
کلاینت p4
باید وجود
داشته
باشد، اما
اگر ریشه
کلاینت (client root)
هنوز وجود
نداشته
باشد،
ایجاد شده و
فایلها در
آن پر
میشوند.
برای
ارسال تمام
تغییراتی
که در شاخه
فعلی گیت
هستند اما
در شاخهٔ p4/master
نیستند، از
دستور زیر
استفاده
کنید:
برای مشخص
کردن
شاخهای
غیر از شاخه
فعلی، از
دستور زیر
استفاده
کنید:
$ git p4 submit topicbranch
برای مشخص
کردن یک
کامیت
منفرد یا یک
محدوده از
کامیتها،
از دستور
زیر
استفاده
کنید:
$ git p4 submit --commit <sha1>
$ git p4 submit --commit <sha1..sha1>
مرجع
بالادستی (upstream
reference) به طور
کلی refs/remotes/p4/master
است، اما
میتواند
با استفاده
از گزینهٔ
خط فرمان --origin=
بازنویسی
شود.
تغییرات p4
با هویت
کاربری که git p4
submit را اجرا
میکند
ایجاد
خواهند شد.
گزینهٔ --preserve-user
باعث
میشود
مالکیت با
توجه به
پدیدآورندهٔ
(author) کامیت گیت
تغییر یابد.
این گزینه
نیازمند
دسترسیهای
مدیر در p4
است که
میتواند
با استفاده
از p4 protect اعطا
شود.
برای
قفسهبندی
(shelve / تعلیق
موقت)
تغییرات به
جای ارسال،
از --shelve و --update-shelve
استفاده
کنید:
$ git p4 submit --shelve
$ git p4 submit --update-shelve 1234 --update-shelve 2345
عملیات Unshelving
یک لیست
تغییرات (changelist)
تعلیقشده
در P4 را
دریافت
کرده و
کامیت
معادل گیت
را در شاخهٔ
refs/remotes/p4-unshelved/<changelist>
تولید
میکند.
کامیت گیت
نسبت به
نسخه مبدا
فعلی (به طور
پیشفرض HEAD)
ایجاد
میشود. یک
کامیت والد
بر اساس
مبدا ایجاد
شده و سپس
کامیت unshelve بر
اساس آن
ساخته
میشود.
نسخه مبدا
را میتوان
با گزینهٔ
"--origin" تغییر
داد.
اگر شاخه
هدف در refs/remotes/p4-unshelved
از قبل وجود
داشته
باشد، شاخه
قدیمی
تغییر نام
خواهد
یافت.
$ git p4 sync
$ git p4 unshelve 12345
$ git show p4-unshelved/12345
<submit more changes via p4 to the same files>
$ git p4 unshelve 12345
<refuses to unshelve until git is in sync with p4 again>
همه
دستورها به
جز clone این
گزینهها
را
میپذیرند.
--git-dir <dir>
تنظیم
متغیر
محیطی
GIT_DIR.
راهنمای
git(1)
را ببینید.
-v, --verbose
ارائه
اطلاعات
بیشتر
درباره
روند
پیشرفت.
این
گزینهها
را میتوان
در clone اولیه
و همچنین در
عملیاتهای
بعدی sync
استفاده
کرد.
--branch <ref>
وارد
کردن
تغییرات به
<ref> به جای refs/remotes/p4/master.
اگر <ref> با refs/
آغاز شود،
همانطور
که هست
استفاده
میشود. در
غیر این
صورت، اگر
با p4/ آغاز
نشود، این
پیشوند به
آن افزوده
میشود.
به طور
پیشفرض،
یک <ref> که با refs/
آغاز نشود
به عنوان
نام یک شاخه
ردیابی
دوردست (تحت
refs/remotes/) در نظر
گرفته
میشود. این
رفتار را
میتوان با
استفاده از
گزینهٔ --import-local
تغییر داد.
مقدار
پیشفرض <ref>
برابر "master"
است.
این مثال
یک شاخه
دوردست
جدید "p4/proj2" را
به یک مخزن
موجود گیت
وارد
میکند:
$ git init
$ git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2
--detect-branches
استفاده
از
الگوریتم
تشخیص شاخه
برای یافتن
مسیرهای
جدید در p4. در
بخش "تشخیص
شاخه (BRANCH DETECTION)" در
زیر مستند
شده است.
--changesfile <file>
وارد
کردن
دقیقاً
همان شماره
تغییرات p4 که
در file فهرست
شدهاند،
در هر خط یکی.
به طور
معمول، git p4
وضعیت
کنونی مخزن p4
را بررسی
کرده و
تغییراتی
را که باید
وارد شوند
تشخیص
میدهد.
--silent
عدم چاپ
هرگونه
اطلاعات
پیشرفت.
--detect-labels
پرسوجو
از p4 برای
برچسبهای
(labels) مرتبط با
مسیرهای
انبار، و
افزودن
آنها به
عنوان تگ (tag)
در گیت. به
دلیل آنکه
تنها
برچسبهای
مرتبط با
changelistهای جدید
را وارد
میکند
کاربرد
محدودی
دارد. منسوخ
شده است.
--import-labels
وارد
کردن
برچسبها
از p4 به گیت.
--import-local
به طور
پیشفرض،
شاخههای p4
در
refs/remotes/p4/
ذخیره
میشوند،
جایی که
توسط
git-branch(1) و
سایر
دستورات به
عنوان
شاخههای
ردیابی
دوردست (remote-tracking)
در نظر
گرفته
خواهند شد.
این گزینه
در عوض
شاخههای p4
را در
refs/heads/p4/
قرار
میدهد.
توجه داشته
باشید که
عملیاتهای
همگامسازی
آینده نیز
باید
--import-local را
مشخص کنند
تا بتوانند
شاخههای p4
را در refs/heads
بیابند.
--max-changes <n>
وارد
کردن
حداکثر n
تغییر، به
جای کل بازه
تغییرات
موجود در
شناسه نسخه
دادهشده.
یک کاربرد
معمول
استفاده از
@all به عنوان
مشخصکننده
نسخه، اما
سپس
استفاده از
--max-changes 1000 برای
وارد کردن
تنها ۱۰۰۰
نسخه آخر به
جای کل
تاریخچه
نسخهها
خواهد بود.
--changes-block-size <n>
اندازه
بلوک داخلی
برای
استفاده
هنگام
تبدیل یک
مشخصکننده
نسخه مانند
@all به فهرستی
از
شمارههای
تغییر خاص.
به جای
استفاده از
یک
فراخوانی
منفرد به p4 changes
برای یافتن
فهرست کامل
تغییرات
جهت تبدیل،
دنبالهای
از
فراخوانیها
به p4 changes -m انجام
میشود که
هر کدام یک
بلوک از
تغییرات را
به اندازه
دادهشده
درخواست
میکند.
اندازه
بلوک
پیشفرض
۵۰۰ است که
معمولاً
مناسب است.
--keep-path
نگاشت
نام
فایلها از
مسیر انبار p4
به گیت به
طور
پیشفرض
شامل حذف کل
مسیر انبار
است. با این
گزینه،
مسیر کامل
انبار p4 در
گیت حفظ
میشود.
برای مثال،
مسیر //depot/main/foo/bar.c،
هنگامی که
از //depot/main/ وارد
میشود، به
foo/bar.c تبدیل
میشود. با
--keep-path، مسیر در
گیت به جای
آن برابر
depot/main/foo/bar.c خواهد
بود.
--use-client-spec
استفاده
از یک
مشخصات
کلاینت (client spec)
برای یافتن
فهرست
فایلهای
مورد نظر در p4.
بخش
"مشخصات
کلاینت (CLIENT SPEC)"
را در زیر
ببینید.
-/ <path>
مستثنی
کردن
مسیرهای
انبار
انتخابشده
هنگام
شبیهسازی
یا
همگامسازی.
این
گزینهها
را میتوان
در یک clone
اولیه به
همراه
گزینههای
sync که در
بالا توضیح
داده شدند
استفاده
کرد.
--destination <directory>
محل
ایجاد مخزن
گیت. در صورت
ارائه
نشدن،
آخرین
مولفه در
مسیر انبار p4
برای ایجاد
یک
دایرکتوری
جدید
استفاده
میشود.
--bare
انجام یک
شبیهسازی
خام (bare clone).
راهنمای
git-clone(1)
را ببینید.
این
گزینهها
میتوانند
برای اصلاح
رفتار git p4 submit
استفاده
شوند.
--origin <commit>
مکان
بالادستی
که
کامیتها
از آن برای
ارسال به p4
شناسایی
میشوند. به
طور
پیشفرض،
این
جدیدترین
کامیت p4 قابل
دستیابی از
HEAD است.
-M
تشخیص
تغییر
نامها.
راهنمای
git-diff(1)
را ببینید.
تغییر
نامها در p4
با استفاده
از
عملیاتهای
صریح
move
نمایش داده
خواهند شد.
گزینه
متناظری
برای تشخیص
کپیها
وجود
ندارد، اما
متغیرهایی
برای هر دو
مورد
جابهجایی
و کپی وجود
دارد.
--preserve-user
بازنویسی
پدیدآورنده
تغییرات p4
پیش از
ارسال به p4.
این گزینه
نیازمند
دسترسیهای
مدیر در p4
است.
--export-labels
صادر
کردن تگها
از گیت به
عنوان
برچسبهای p4.
تگهای
یافتشده
در گیت بر
روی
دایرکتوری
کاری perforce
اعمال
میشوند.
-n, --dry-run
تنها
نشان دادن
اینکه چه
کامیتهایی
به p4 ارسال
خواهند شد؛
وضعیت را در
گیت یا p4
تغییر
ندهید.
--prepare-p4-only
اعمال یک
کامیت روی
فضای کاری p4،
با باز
کردن،
افزودن و
حذف
فایلها در p4
همانند یک
عملیات
عادی submit. اما
دستور
نهایی "p4 submit"
صادر
نمیشود،
بلکه در عوض
پیامی
درباره
نحوه ارسال
دستی یا
بازگرداندن
(revert) چاپ
میشود. این
گزینه
همیشه پس از
اولین
(قدیمیترین)
کامیت
متوقف
میشود.
تگهای گیت
به p4 صادر
نمیشوند.
--shelve
به جای
ارسال،
ایجاد
مجموعهای
از
فهرستهای
تغییرات
تعلیقشده
(shelved changelists). پس از
ایجاد هر shelve،
فایلهای
مربوطه
بازگردانی/حذف
(reverted/deleted) میشوند.
اگر چندین
کامیت در
انتظار
داشته
باشید،
چندین shelve
ایجاد
خواهد شد.
--update-shelve CHANGELIST
بهروزرسانی
یک لیست
تغییرات
تعلیقشدهٔ
موجود با
این کامیت.
مستلزم
گزینه --shelve است.
برای چندین
changelist
تعلیقشده
تکرار
کنید.
--conflict=(ask|skip|quit)
هنگام
اعمال یک
کامیت روی p4
ممکن است
تعارض رخ
دهد. وقتی
این اتفاق
میافتد،
رفتار
پیشفرض ("ask")
این است که
سوال شود
آیا این
کامیت
نادیده
گرفته شده و
ادامه
یابد، یا
خارج شود.
این گزینه
میتواند
برای دور
زدن این
اعلان
استفاده
شود و باعث
شود
کامیتهای
دارای
تعارض به
طور خودکار
نادیده
گرفته
شوند، یا
اینکه تلاش
برای اعمال
کامیتها
بدون
درخواست
تایید
متوقف
گردد.
--branch <branch>
پس از
ارسال،
همگامسازی
این شاخه
نامگذاریشده
به جای شاخه
پیشفرض p4/master.
برای
اطلاعات
بیشتر بخش
"گزینههای
همگامسازی
(Sync options)" در بالا
را ببینید.
--commit (<sha1>|<sha1>..<sha1>)
تنها
ارسال
کامیت یا
محدوده
کامیتهای
مشخصشده،
به جای
فهرست کامل
تغییراتی
که در شاخه
فعلی گیت
وجود دارد.
--disable-rebase
غیرفعال
کردن
بازنشانی
پایه
خودکار پس
از اینکه
تمام
کامیتها
با موفقیت
ارسال شدند.
همچنین
میتواند
با git-p4.disableRebase تنظیم
شود.
--disable-p4sync
غیرفعال
کردن
همگامسازی
خودکار p4/master از
Perforce پس از
ارسال
کامیتها.
مستلزم
گزینه --disable-rebase
است. همچنین
میتواند
با git-p4.disableP4Sync تنظیم
شود.
همگامسازی
با origin/master در
صورت امکان
همچنان
انجام
میشود.
قلاب p4-pre-submit
در صورت
وجود و قابل
اجرا بودن
اجرا
میشود. این
قلاب هیچ
پارامتری
دریافت
نمیکند و
هیچ چیزی از
ورودی
استاندارد
نمیگیرد.
خروج با
وضعیت غیر
صفر از این
اسکریپت
مانع از
اجرای git-p4 submit
میشود. این
قلاب را
میتوان با
گزینه خط
فرمان --no-verify
دور زد.
یک
سناریوی
کاربردی
اجرای
آزمونهای
واحد (unit tests) در
این قلاب
است.
قلاب p4-prepare-changelist
درست پس از
آمادهسازی
پیام
پیشفرض changelist و
قبل از شروع
ویرایشگر
اجرا
میشود. این
قلاب یک
پارامتر
دریافت
میکند که
نام فایلی
است که متن
changelist را در بر
دارد. خروج
با وضعیت
غیر صفر از
اسکریپت
فرآیند را
متوقف
خواهد کرد.
هدف از این
قلاب،
ویرایش
درجا (in place) فایل
پیام است و
با گزینه --no-verify
غیرفعال
نمیشود.
این قلاب
حتی در صورت
تنظیم --prepare-p4-only
نیز
فراخوانی
میشود.
قلاب p4-changelist
پس از اینکه
پیام changelist توسط
کاربر
ویرایش شد
اجرا
میشود. این
قلاب
میتواند
با گزینه --no-verify
دور زده شود.
این قلاب یک
پارامتر
واحد
دریافت
میکند که
نام فایلی
است که متن
پیشنهادی changelist
را
نگهداری
میکند.
خروج با
وضعیت غیر
صفر باعث
لغو دستور
میشود.
این قلاب
مجاز به
ویرایش
فایل changelist است
و میتواند
برای
یکدستسازی
متن به
قالبی
استاندارد
در پروژه
استفاده
شود. همچنین
میتواند
پس از
بازبینی
فایل پیام،
برای رد
کردن Submit
استفاده
شود.
قلاب p4-post-changelist
پس از اینکه
ارسال با
موفقیت در P4
انجام شد
فراخوانی
میشود. هیچ
پارامتری
دریافت
نمیکند و
اساساً
برای
اطلاعرسانی
در نظر
گرفته شده
است و
نمیتواند
بر نتیجه
عملیات git p4 submit
تأثیر
بگذارد.
این
گزینهها
میتوانند
برای تغییر
رفتار git p4 rebase
استفاده
شوند.
--import-labels
وارد
کردن
برچسبهای
p4.
--origin
تنظیم refspec
گیت که changelist
تعلیقشده
در P4 در برابر
آن مقایسه
میشود.
پیشفرض p4/master
است.
آرگومان
مسیر انبار p4
به git p4 sync و git p4 clone
میتواند
یک یا چند
مسیر انبار p4
جداشده با
فاصله
باشد،
همراه با یک
شناسه نسخه
اختیاری p4 در
انتها:
"//depot/my/project"
وارد
کردن یک
کامیت با
تمام
فایلها در
تغییر #head تحت
آن درخت.
"//depot/my/project@all"
وارد
کردن یک
کامیت به
ازای هر
تغییر در
تاریخچه آن
مسیر
انبار.
"//depot/my/project@1,6"
تنها
وارد کردن
تغییرات ۱
تا ۶.
"//depot/proj1@all //depot/proj2@all"
وارد
کردن تمام
تغییرات از
هر دو مسیر
انبار
نامبردهشده
در یک مخزن
واحد. تنها
فایلهای
زیر این
دایرکتوریها
گنجانده
میشوند. در
گیت برای هر
کدام از "proj1" و
"proj2" یک
زیردایرکتوری
ایجاد
نمیشود.
هنگام مشخص
کردن بیش از
یک مسیر
انبار،
باید از
گزینهٔ --destination
استفاده
کنید.
مشخصکننده
نسخه باید
روی هر مسیر
انبار به
طور یکسان
تعیین شود.
اگر در
مسیرهای
انبار
فایلهایی
با نام
یکسان وجود
داشته
باشد،
مسیری که
جدیدترین
نسخه
بهروزشدهٔ
فایل را
دارد در گیت
ظاهر
میشود.
برای نحو
کامل
مشخصکنندههای
نسخه در p4،
به p4 help revisions
مراجعه
کنید.
مشخصات
کلاینت p4 با
دستور p4 client
نگهداری
میشود و از
جمله
فیلدهای
دیگر، شامل
یک View است که
مشخص
میکند
چگونه
انبار به
مخزن
کلاینت
نگاشت
میشود.
دستورهای
clone و sync
میتوانند
هنگام
دریافت
گزینهٔ --use-client-spec
یا زمانی که
متغیر useClientSpec
برابر true
است،
مشخصات
کلاینت را
مد نظر قرار
دهند. پس از git
p4 clone، متغیر useClientSpec
به طور
خودکار در
فایل
پیکربندی
مخزن تنظیم
میشود. این
کار اجازه
میدهد
دستورهای
آیندهٔ git p4 submit
به درستی
کار کنند؛
دستور submit
تنها به این
متغیر نگاه
میکند و
گزینه خط
فرمانی
برای آن
ندارد.
نحو کامل
برای یک view در p4
در p4 help views
مستند شده
است. git p4 تنها
زیرمجموعهای
از نحو view را
میشناسد.
این ابزار
نگاشتهای
چندخطی،
همپوشانیها
(overlays) با +،
موارد
استثنا با -
و علامت
نقلقول
دوگانه در
اطراف
فاصلهها
را متوجه
میشود. از
میان
نویسههای
عمومی (wildcards)
ممکن، git p4
تنها ... را
مدیریت
میکند، و
آن هم فقط
زمانی که در
انتهای
مسیر باشد.
اگر git p4 با
نویسه
عمومی
پشتیبانینشدهای
مواجه شود،
خطا گزارش
میدهد.
اشکالاتی
در
پیادهسازی
نگاشتهای
دارای
همپوشانی
وجود دارد.
اگر چندین
مسیر انبار
از طریق overlays به
یک مکان
یکسان در
مخزن نگاشت
شوند، git p4
ممکن است
مسیر
اشتباه را
انتخاب کند.
حل این مشکل
بدون
اختصاص یک
مشخصات
کلاینت
صرفاً برای
git p4 دشوار
است.
نام
کلاینت را
میتوان به
روشهای
مختلفی به git
p4 ارائه کرد.
متغیر git-p4.client
در صورت
وجود
اولویت
دارد. در غیر
این صورت،
سازوکارهای
عادی p4 برای
تعیین
کلاینت
استفاده
میشوند:
متغیر
محیطی P4CLIENT،
یک فایل
ارجاع
دادهشده
توسط P4CONFIG، یا
نام میزبان
محلی (local host name).
نرمافزار
P4 مفهومی
یکسان با
شاخه در گیت
ندارد. در
عوض، p4
محتوای خود
را به صورت
یک درخت
دایرکتوری
سازماندهی
میکند که
بر اساس
توافق،
شاخههای
منطقی
مختلف در
مکانهای
متفاوتی در
درخت قرار
دارند.
دستور p4 branch
برای
نگهداری
نگاشتهای
میان
بخشهای
مختلف در
درخت و نشان
دادن
محتوای
مرتبط
استفاده
میشود. git p4
میتواند
از این
نگاشتها
برای تعیین
روابط
شاخهها
استفاده
کند.
اگر مخزنی
دارید که در
آن تمام
شاخههای
مورد نظر به
عنوان
زیردایرکتوریهای
یک مسیر
انبار واحد
وجود
دارند،
میتوانید
هنگام
شبیهسازی
یا
همگامسازی
از --detect-branches
استفاده
کنید تا git p4
به طور
خودکار
زیردایرکتوریها
را در p4 پیدا
کرده و
آنها را به
عنوان
شاخههایی
در گیت
ایجاد کند.
برای
مثال، اگر
ساختار
مخزن P4 به
صورت زیر
باشد:
//depot/main/...
//depot/branch1/...
و دستور "p4 branch
-o branch1" یک خط View را
نشان دهد که
شبیه زیر
است:
//depot/main/... //depot/branch1/...
سپس این
دستور git p4 clone:
git p4 clone --detect-branches //depot@all
یک شاخهٔ
جداگانه در
refs/remotes/p4/ برای //depot/main
به نام master، و
یک شاخه
برای //depot/branch1 به
نام depot/branch1
تولید
میکند.
با این
حال، برای
اینکه
بتوان از
آنها
مانند
شاخهها
استفاده
کرد، ایجاد
شاخهها در p4
الزامی
نیست. از
آنجا که
استنباط
روابط
شاخهها به
طور خودکار
دشوار است،
میتوان از
تنظیم
پیکربندی
گیت git-p4.branchList
برای
شناسایی
صریح روابط
شاخهها
استفاده
کرد. این
تنظیم
فهرستی از
جفتهای
"source:destination" است،
مانند یک
مشخصات
ساده شاخه
در p4، که در
آن "source" و "destination"
عناصر مسیر
در مخزن p4
هستند. مثال
بالا متکی
به حضور
شاخه p4 بود.
بدون
شاخههای p4،
همین نتیجه
با
دستورهای
زیر حاصل
خواهد شد:
git init depot
cd depot
git config git-p4.branchList main:branch1
git p4 clone --detect-branches //depot@all .
سازوکار
fast-import مورد
استفاده
توسط git p4
برای هر بار
فراخوانی git p4
sync یک pack file ایجاد
میکند.
معمولاً
فشردهسازی
بازیافت
حافظه گیت
(git-gc(1)) به طور
خودکار این
فایلها را
به
بستههای
کمتری
فشرده
میکند،
اما اجرای
صریح دستور
git repack -adf ممکن
است کارایی
را بهبود
بخشد.
تنظیمات
پیکربندی
زیر
میتوانند
برای تغییر
رفتار git p4
استفاده
شوند. همه
آنها در
بخش git-p4 قرار
دارند.
git-p4.user
کاربر
مشخصشده
به عنوان
گزینهای
برای همه
دستورهای p4،
با -u <user>.
متغیر
محیطی P4USER
میتواند
به جای آن
استفاده
شود.
git-p4.password
گذرواژه
مشخصشده
به عنوان
گزینهای
برای همه
دستورهای p4،
با -P <password>.
متغیر
محیطی P4PASS
میتواند
به جای آن
استفاده
شود.
git-p4.port
درگاه
(پورت)
مشخصشده
به عنوان
گزینهای
برای همه
دستورهای p4،
با -p <port>.
متغیر
محیطی P4PORT
میتواند
به جای آن
استفاده
شود.
git-p4.host
میزبان
مشخصشده
به عنوان
گزینهای
برای همه
دستورهای p4،
با -h <host>.
متغیر
محیطی P4HOST
میتواند
به جای آن
استفاده
شود.
git-p4.client
کلاینت
مشخصشده
به عنوان
گزینهای
برای همه
دستورهای p4،
با -c <client>،
شامل
مشخصات
کلاینت.
git-p4.retries
تعداد
دفعات تلاش
مجدد برای
یک دستور p4 (به
ویژه p4 sync) را
در صورت
اتمام مهلت
شبکه مشخص
میکند.
مقدار
پیشفرض ۳
است. برای
غیرفعال
کردن
تلاشهای
مجدد یا در
صورتی که
نسخه p4 شما از
تلاش مجدد
پشتیبانی
نمیکند
(قبل از 2012.2)،
مقدار را
روی 0 تنظیم
کنید.
git-p4.syncFromOrigin
از آنجا
که وارد
کردن
کامیتها
از سایر
مخازن گیت
بسیار
سریعتر از
وارد کردن
آنها از p4
است،
سازوکاری
برای یافتن
تغییرات p4
ابتدا در
شاخههای
دوردست گیت
وجود دارد.
اگر
شاخههایی
تحت refs/remote/origin/p4
وجود داشته
باشند،
هنگام
همگامسازی
از p4 واکشی
شده و
استفاده
خواهند شد.
این متغیر
میتواند
برای
غیرفعال
کردن این
رفتار بر
روی false تنظیم
شود.
git-p4.branchUser
یک مرحله
در تشخیص
شاخه شامل
بررسی
شاخههای p4
برای یافتن
شاخههای
جدید جهت
وارد کردن
است. به طور
پیشفرض،
تمام
شاخهها
بررسی
میشوند.
این گزینه
جستجو را
تنها به
مواردی
محدود
میکند که
متعلق به
کاربری
هستند که
نامش در
متغیر ذکر
شده است.
git-p4.branchList
فهرست
شاخههایی
که هنگام
فعال بودن
تشخیص شاخه
باید وارد
شوند. هر
ورودی باید
یک جفت از
نامهای
شاخه باشد
که با
دونقطه (:) از
هم جدا
شدهاند.
این مثال
اعلام
میکند که
هر دو شاخه branchA
و branchB از main
ایجاد
شدهاند:
git config git-p4.branchList main:branchA
git config --add git-p4.branchList main:branchB
git-p4.ignoredP4Labels
فهرست
برچسبهای p4
برای
نادیده
گرفتن. این
فهرست با
کشف
برچسبهای
غیرقابل
وارد کردن
به طور
خودکار
ساخته
میشود.
git-p4.importLabels
وارد
کردن
برچسبهای p4
به گیت،
مطابق با
--import-labels.
git-p4.labelImportRegexp
تنها
برچسبهای p4
که با این
عبارت
باقاعده
مطابقت
دارند وارد
خواهند شد.
مقدار
پیشفرض
برابر است
با [a-zA-Z0-9_\-.]+$.
git-p4.useClientSpec
مشخص
میکند که
مشخصات
کلاینت p4
باید برای
شناسایی
مسیرهای
انبار مورد
نظر p4
استفاده
شود. این
معادل
تعیین
گزینهٔ --use-client-spec
است. بخش
"مشخصات
کلاینت (CLIENT SPEC)"
را در بالا
ببینید. این
متغیر یک
مقدار بولی
است، نه نام
یک کلاینت p4.
git-p4.pathEncoding
سیستم Perforce
کدگذاری یک
مسیر را
همانطور
که توسط
سیستمعامل
مبدا تعیین
شده
نگهداری
میکند. گیت
انتظار
دارد
مسیرها با
کدگذاری UTF-8
باشند. از
این
پیکربندی
برای اعلام
به git-p4
استفاده
کنید که Perforce از
چه
کدگذاریای
برای
مسیرها
استفاده
کرده است.
این
کدگذاری
برای تبدیل
مسیرها به UTF-8
استفاده
میشود. به
عنوان
مثال، Perforce در
ویندوز
اغلب از "cp1252"
برای
کدگذاری
نام مسیرها
استفاده
میکند. اگر
این گزینه
به درخواست p4
clone ارسال
شود، در
مخزن گیت
جدید حاصل
ذخیره و
ماندگار
میشود.
git-p4.metadataDecodingStrategy
سیستم Perforce
کدگذاری
توضیحات changelist و
نام کامل
کاربران را
همانطور
که توسط
کلاینت در
یک
سیستمعامل
ذخیره شده
حفظ میکند.
کلاینت p4v از
کدگذاری
محلی
سیستمعامل
استفاده
میکند،
بنابراین
کاربران
مختلف ممکن
است در
نهایت
توضیحات changelist
یا نامهای
کامل
متفاوتی را
با
کدگذاریهای
متفاوتی در
همان انبار
ذخیره کنند.
گیت
کدگذاریهای
ناهماهنگ/نادرست
را در
پیامهای
کامیت و نام
نویسندگان
تحمل
میکند،
اما انتظار
دارد آنها
در قالب utf-8
مشخص شوند.
ابزار git-p4
میتواند
از سه
راهبرد
مختلف
رمزگشایی
در مواجهه
با عدم
قطعیت
کدگذاری در
Perforce استفاده
کند: passthrough
صرفاً
بایتهای
اصلی را از Perforce
به گیت
منتقل
میکند و در
صورتی که
دادههای Perforce
با چیزی غیر
از utf-8
کدگذاری
شده باشند،
دادههایی
قابل
استفاده
اما با
کدگذاری
نادرست
ایجاد
میکند. strict
انتظار
دارد
دادههای Perforce
با کدگذاری
utf-8 باشند، و
در غیر این
صورت
عملیات
وارد کردن
با شکست
مواجه
میشود. fallback
تلاش
میکند
دادهها را
به عنوان utf-8
تفسیر کند،
و در غیر این
صورت به
استفاده از
یک کدگذاری
ثانویه
بازمیگردد
- به طور
پیشفرض
کدگذاری
رایج
ویندوز cp-1252 -
که در صورت
عدم موفقیت
در
رمزگشایی
با کدگذاری
پشتیبان،
بایتهای
دامنه
بالایی
اسکیپ
میشوند. در
پایتون ۲
راهبرد
پیشفرض به
دلایل
تاریخی passthrough
است، و در
پایتون ۳
پیشفرض fallback
است. هنگامی
که strict
انتخاب شود
و رمزگشایی
با شکست
مواجه
گردد، پیام
خطا تغییر
این
پارامتر
پیکربندی
را به عنوان
راهکار
پیشنهاد
میدهد. اگر
این گزینه
به درخواست p4
clone ارسال
شود، در
مخزن گیت
جدید حاصل
ذخیره
میشود.
git-p4.metadataFallbackEncoding
کدگذاری
پشتیبان (fallback)
مورد
استفاده
هنگام
رمزگشایی
نام
نویسندگان
و توضیحات changelist
در Perforce با
استفاده از
راهبرد fallback
را مشخص
میکند
(نگاه کنید
به git-p4.metadataDecodingStrategy).
کدگذاری
پشتیبان
تنها زمانی
استفاده
خواهد شد که
رمزگشایی
به عنوان utf-8
با شکست
مواجه شود.
این گزینه
به طور
پیشفرض
روی cp1252، یک
کدگذاری
رایج
ویندوز،
تنظیم است.
اگر این
گزینه به
درخواست p4 clone
ارسال شود،
در مخزن گیت
جدید حاصل
ذخیره
میشود.
git-p4.largeFileSystem
سیستم
مورد
استفاده
برای
فایلهای
بزرگ
(باینری) را
مشخص
میکند.
لطفاً توجه
داشته
باشید که
سیستمهای
فایل بزرگ
از دستور
git p4 submit
پشتیبانی
نمیکنند.
در حال حاضر
تنها Git LFS
پیادهسازی
شده است
(برای
اطلاعات
بیشتر به
https://git-lfs.github.com
مراجعه
کنید). برای
استفاده از
این گزینه،
افزونه خط
فرمان Git LFS را
دانلود و
نصب کرده و
آن را به این
صورت
پیکربندی
نمایید:
git config git-p4.largeFileSystem GitLFS
git-p4.largeFileExtensions
تمام
فایلهایی
که با یک
پسوند فایل
در این
فهرست
مطابقت
دارند توسط
سیستم
فایلهای
بزرگ
پردازش
خواهند شد.
پیشوند . را
به پسوندها
اضافه
نکنید.
git-p4.largeFileThreshold
تمام
فایلهایی
که اندازه
غیرفشرده
آنها از
آستانه
فراتر رود
توسط سیستم
فایلهای
بزرگ
پردازش
خواهند شد.
به طور
پیشفرض
این آستانه
بر حسب بایت
تعریف
میشود.
پسوند k یا m یا
g را برای
تغییر واحد
اضافه
کنید.
git-p4.largeFileCompressedThreshold
تمام
فایلهایی
که اندازه
فشرده
آنها از
آستانه
فراتر رود
توسط سیستم
فایلهای
بزرگ
پردازش
خواهند شد.
این گزینه
ممکن است
روند
شبیهسازی/همگامسازی
شما را کند
کند. به طور
پیشفرض
آستانه بر
حسب بایت
تعریف
میشود.
پسوند k یا m یا
g را برای
تغییر واحد
اضافه
کنید.
git-p4.largeFilePush
متغیر
بولی که
تعیین
میکند آیا
فایلهای
بزرگ به طور
خودکار به
سرور ارسال
(push) شوند یا
خیر.
git-p4.keepEmptyCommits
اگر این
گزینه بولی
روی true تنظیم
شود، یک changelist که
تنها شامل
فایلهای
مستثنیشده
است به
عنوان یک
کامیت خالی
وارد خواهد
شد.
git-p4.mapUser
نگاشت یک
کاربر P4 به یک
نام و نشانی
ایمیل در
گیت. از یک
رشته با
قالب زیر
برای ایجاد
نگاشت
استفاده
کنید:
git config --add git-p4.mapUser "p4user = First Last <mail@address.com>"
یک نگاشت
هرگونه
اطلاعات
کاربر از P4
را لغو
خواهد کرد.
نگاشتها
را میتوان
برای چندین
کاربر P4
تعریف کرد.
git-p4.detectRenames
تشخیص
تغییر
نامها.
راهنمای
git-diff(1)
را ببینید.
این
میتواند true
یا false یا یک
امتیاز
مورد
انتظار
توسط
git diff -M
باشد.
git-p4.detectCopies
تشخیص
کپیها.
راهنمای
git-diff(1)
را ببینید.
این
میتواند true
یا false یا یک
امتیاز
مورد
انتظار
توسط
git diff -C
باشد.
git-p4.detectCopiesHarder
تشخیص
دقیقتر
کپیها.
راهنمای
git-diff(1)
را ببینید.
یک مقدار
بولی است.
git-p4.preserveUser
هنگام
ارسال،
تغییرات را
بازنویسی
کنید تا
نویسنده
گیت را
منعکس کند،
صرفنظر از
اینکه چه
کسی git p4 submit را
اجرا
میکند.
git-p4.allowMissingP4Users
هنگامی
که preserveUser برابر
true باشد، git p4 به
طور معمول
اگر نتواند
نویسندهای
را در نقشه
کاربران p4
پیدا کند
متوقف
میشود. این
تنظیم در هر
صورت
تغییرات را
ارسال
میکند.
git-p4.skipSubmitEdit
فرآیند submit
ویرایشگر
را قبل از
ارسال هر
تغییر p4
فراخوانی
میکند. با
این حال،
اگر این
تنظیم
برابر true
باشد،
مرحله
ویرایش
نادیده
گرفته
میشود.
git-p4.skipSubmitEditCheck
پس از
ویرایش
پیام تغییر
p4، git p4 با
بررسی زمان
تغییر فایل
اطمینان
حاصل
میکند که
توضیحات
واقعاً
تغییر کرده
است. این
گزینه آن
آزمایش را
غیرفعال
میکند.
git-p4.allowSubmit
به طور
پیشفرض،
هر شاخهای
میتواند
به عنوان
منبع برای
یک عملیات git p4
submit استفاده
شود. این
متغیر
پیکربندی،
در صورت
تنظیم،
تنها به
شاخههای
نامبرده
اجازه
میدهد به
عنوان
منابع
ارسال
استفاده
شوند. نام
شاخهها
باید
نامهای
کوتاه
باشند (بدون
"refs/heads/") و باید
با کاما (",") و
بدون فاصله
از هم جدا
شوند.
git-p4.skipUserNameCheck
اگر
کاربری که git p4
submit را اجرا
میکند در
نقشه
کاربران p4
وجود
نداشته
باشد، git p4
خارج
میشود. این
گزینه
میتواند
برای اجبار
به ارسال در
هر صورت
استفاده
شود.
git-p4.attemptRCSCleanup
در صورت
فعال بودن،
git p4 submit تلاش
خواهد کرد
کلیدواژههای
RCS مانند ($Header$ و
غیره) را
پاکسازی
کند. در غیر
این صورت
این موارد
باعث تعارض
ادغام شده و
مانع از
انجام
ارسال
میشوند.
این گزینه
در حال حاضر
باید
آزمایشی در
نظر گرفته
شود.
git-p4.exportLabels
صادر
کردن
تگهای گیت
به
برچسبهای
p4، مطابق با
--export-labels.
git-p4.labelExportRegexp
تنها
برچسبهای p4
که با این
عبارت
باقاعده
مطابقت
دارند صادر
خواهند شد.
مقدار
پیشفرض
برابر است
با [a-zA-Z0-9_\-.]+$.
git-p4.conflict
مشخص
کردن رفتار
submit هنگام
یافتن
تعارض با p4،
مطابق با --conflict.
رفتار
پیشفرض
برابر است
با ask.
git-p4.disableRebase
پس از یک
ارسال،
شاخه را در
برابر p4/master
بازنشانی
پایه
نکنید.
git-p4.disableP4Sync
پس از
ارسال، p4/master را
با Perforce
همگامسازی
نکنید.
مستلزم git-p4.disableRebase
است.
همگامسازی
با origin/master در
صورت امکان
همچنان
انجام
میشود.
•مجموعهتغییرات
(changesets) از p4 با
استفاده از Git
fast-import وارد
میشوند.
•شبیهسازی
یا
همگامسازی
نیازی به
کلاینت p4
ندارد؛
محتویات
فایل با
استفاده از
p4 print
جمعآوری
میشوند.
•ارسال (Submit)
نیازمند
کلاینت p4
است، که در
همان مکان
مخزن گیت
قرار ندارد.
وصلهها (patches)
یکییکی بر
روی این
کلاینت p4
اعمال شده و
از آنجا
ارسال
میشوند.
•هر
کامیت
واردشده
توسط git p4 یک
خط در
انتهای
پیام لاگ
دارد که
مکان انبار p4
و شماره
تغییر را
نشان
میدهد. این
خط توسط
عملیاتهای
بعدی git p4 sync
استفاده
میشود تا
مشخص شود
کدام
تغییرات p4
جدید
هستند.