REPO(1) راهنمای Repo REPO(1)

repo - ابزار بررسی و استخراج مانیفست در repo

repo manifest [-o {-|NAME.xml}] [-m MANIFEST.xml] [-r]

خلاصه

ابزار بررسی و بازرسی مانیفست

نمایش این پیام راهنما و خروج
ذخیره نسخه‌ها (revisions) به‌عنوان HEAD فعلی
مانیفست موقت برای استفاده در این همگام‌سازی (sync)
اگر در حالت -r باشد، فیلد upstream را نمی‌نویسد (تنها در صورتی کاربرد دارد که نام شاخه‌ها برای یک مانیفست sha1 حساس باشد)
اگر در حالت -r باشد، فیلد dest-branch را نمی‌نویسد (تنها در صورتی کاربرد دارد که نام شاخه‌ها برای یک مانیفست sha1 حساس باشد)
قالب خروجی: xml, json (پیش‌فرض: xml)
قالب‌بندی خروجی برای خوانایی آسان‌تر توسط انسان
نادیده گرفتن مانیفست‌های محلی
فایلی که مانیفست در آن ذخیره می‌شود. (پیشوند نام فایل برای چنددرختی [multi-tree].)

نمایش تمام خروجی‌ها
تنها نمایش خطاها

شروع عملیات از بیرونی‌ترین مانیفست
عدم اجرای عملیات روی مانیفست‌های بیرونی
تنها روی این (زیر)مانیفست عملیات انجام شود
انجام عملیات روی این مانیفست و زیرمانیفست‌های آن

برای مشاهده راهنمای دقیق، دستور `repo help manifest` را اجرا کنید.

با گزینه -o، مانیفست فعلی را برای بازرسی استخراج می‌کند. مانیفست و پوشه local_manifests/ (در صورت وجود) با یکدیگر ترکیب می‌شوند تا یک فایل مانیفست واحد ایجاد شود. این فایل را می‌توان برای استفاده در فراخوانی‌های بعدی 'repo init' در یک مخزن Git ذخیره کرد.

از گزینه -r می‌توان برای تولید یک فایل مانیفست با نسخه‌های پروژه‌ای که روی هش کامیت فعلی تنظیم شده‌اند، استفاده کرد. این‌ها با عنوان «مانیفست‌های قفل‌شده بر نسخه» شناخته می‌شوند، چرا که از شاخه خاصی پیروی نمی‌کنند. در این حالت، مشخصه 'upstream' روی مرجعی تنظیم می‌شود که هنگام تولید مانیفست روی آن بوده‌ایم. مشخصه 'dest-branch' به منظور تعیین مرجع دوردستی تنظیم می‌شود که تغییرات از طریق 'repo upload' به آن ارسال می‌شوند.

قالب‌های خروجی متعددی از طریق --format پشتیبانی می‌شوند. خروجی پیش‌فرض XML است و قالب‌ها به‌طور کلی «فشرده» هستند. برای نسخه‌های خواناتر توسط انسان از --pretty استفاده کنید.

قالب مانیفست repo

یک مانیفست repo ساختار یک کلاینت repo را شرح می‌دهد؛ یعنی پوشه‌هایی که قابل مشاهده هستند و اینکه از کجا باید با git دریافت شوند.

ساختار اصلی یک مانیفست، یک مخزن خالی (bare) در Git است که یک پرونده XML منفرد `default.xml` را در ریشه دایرکتوری نگهداری می‌کند.

مانیفست‌ها ذاتاً دارای کنترل نسخه هستند، زیرا درون یک مخزن Git نگهداری می‌شوند. به‌روزرسانی‌های مانیفست‌ها به‌طور خودکار توسط کلاینت‌ها در طول `repo sync` دریافت می‌شوند.

[TOC]

قالب فایل XML

یک فایل XML مانیفست (مانند `default.xml`) تقریباً با DTD زیر مطابقت دارد:

```xml <!DOCTYPE manifest [

<!ELEMENT manifest (notice?,
remote*, default?, manifest-server?, submanifest*?, remove-project*, project*, extend-project*, repo-hooks?, superproject?, contactinfo?, include*)>
<!ELEMENT notice (#PCDATA)>
<!ELEMENT remote (annotation*)> <!ATTLIST remote name ID #REQUIRED> <!ATTLIST remote alias CDATA #IMPLIED> <!ATTLIST remote fetch CDATA #REQUIRED> <!ATTLIST remote pushurl CDATA #IMPLIED> <!ATTLIST remote review CDATA #IMPLIED> <!ATTLIST remote revision CDATA #IMPLIED>
<!ELEMENT default EMPTY> <!ATTLIST default remote IDREF #IMPLIED> <!ATTLIST default revision CDATA #IMPLIED> <!ATTLIST default dest-branch CDATA #IMPLIED> <!ATTLIST default upstream CDATA #IMPLIED> <!ATTLIST default sync-j CDATA #IMPLIED> <!ATTLIST default sync-j-max CDATA #IMPLIED> <!ATTLIST default sync-c CDATA #IMPLIED> <!ATTLIST default sync-s CDATA #IMPLIED> <!ATTLIST default sync-tags CDATA #IMPLIED>
<!ELEMENT manifest-server EMPTY> <!ATTLIST manifest-server url CDATA #REQUIRED>
<!ELEMENT submanifest EMPTY> <!ATTLIST submanifest name ID #REQUIRED> <!ATTLIST submanifest remote IDREF #IMPLIED> <!ATTLIST submanifest project CDATA #IMPLIED> <!ATTLIST submanifest manifest-name CDATA #IMPLIED> <!ATTLIST submanifest revision CDATA #IMPLIED> <!ATTLIST submanifest path CDATA #IMPLIED> <!ATTLIST submanifest groups CDATA #IMPLIED> <!ATTLIST submanifest default-groups CDATA #IMPLIED>
<!ELEMENT project (annotation*,
project*, copyfile*, linkfile*)>
<!ATTLIST project name
CDATA #REQUIRED>
<!ATTLIST project path
CDATA #IMPLIED>
<!ATTLIST project remote
IDREF #IMPLIED>
<!ATTLIST project revision
CDATA #IMPLIED>
<!ATTLIST project dest-branch CDATA #IMPLIED> <!ATTLIST project groups CDATA #IMPLIED> <!ATTLIST project sync-c CDATA #IMPLIED> <!ATTLIST project sync-s CDATA #IMPLIED> <!ATTLIST project sync-tags CDATA #IMPLIED> <!ATTLIST project upstream CDATA #IMPLIED> <!ATTLIST project clone-depth CDATA #IMPLIED> <!ATTLIST project force-path CDATA #IMPLIED>
<!ELEMENT annotation EMPTY> <!ATTLIST annotation name CDATA #REQUIRED> <!ATTLIST annotation value CDATA #REQUIRED> <!ATTLIST annotation keep CDATA "true">.IP <!ELEMENT copyfile EMPTY> <!ATTLIST copyfile src CDATA #REQUIRED> <!ATTLIST copyfile dest CDATA #REQUIRED>
<!ELEMENT linkfile EMPTY> <!ATTLIST linkfile src CDATA #REQUIRED> <!ATTLIST linkfile dest CDATA #REQUIRED>
<!ELEMENT extend-project (annotation*,
copyfile*, linkfile*)>
<!ATTLIST extend-project name
CDATA #REQUIRED>
<!ATTLIST extend-project path
CDATA #IMPLIED>
<!ATTLIST extend-project dest-path
CDATA #IMPLIED>
<!ATTLIST extend-project groups
CDATA #IMPLIED>
<!ATTLIST extend-project revision
CDATA #IMPLIED>
<!ATTLIST extend-project remote
CDATA #IMPLIED>
<!ATTLIST extend-project dest-branch CDATA #IMPLIED> <!ATTLIST extend-project upstream CDATA #IMPLIED> <!ATTLIST extend-project base-rev CDATA #IMPLIED>
<!ELEMENT remove-project EMPTY> <!ATTLIST remove-project name CDATA #IMPLIED> <!ATTLIST remove-project path CDATA #IMPLIED> <!ATTLIST remove-project optional CDATA #IMPLIED> <!ATTLIST remove-project base-rev CDATA #IMPLIED>
<!ELEMENT repo-hooks EMPTY> <!ATTLIST repo-hooks in-project CDATA #REQUIRED> <!ATTLIST repo-hooks enabled-list CDATA #REQUIRED>
<!ELEMENT superproject EMPTY> <!ATTLIST superproject name CDATA #REQUIRED> <!ATTLIST superproject remote IDREF #IMPLIED> <!ATTLIST superproject revision CDATA #IMPLIED>
<!ELEMENT contactinfo EMPTY> <!ATTLIST contactinfo bugurl CDATA #REQUIRED>
<!ELEMENT include EMPTY> <!ATTLIST include name CDATA #REQUIRED> <!ATTLIST include groups CDATA #IMPLIED> <!ATTLIST include revision CDATA #IMPLIED>

]> ```

به‌منظور سازگاری میان نسخه‌های مختلف repo، تمامی عنصرهای ناشناخته بدون هشدار نادیده گرفته می‌شوند. با این حال، repo تمام نام‌های ممکن را برای استفاده در آینده برای خود رزرو می‌کند. اگر مایل به استفاده از عنصرهای سفارشی هستید، فضای نام `x-*` برای این منظور اختصاص یافته است، و repo تضمین می‌کند که هرگز نام‌های متناظری را تخصیص ندهد.

شرحی از عنصرها و مشخصه‌های آن‌ها در ادامه آمده است.

عنصر manifest

عنصر ریشه در فایل.

عنصر notice

متن دلخواهی که پس از پایان `repo sync` به کاربران نمایش داده می‌شود. محتوا دقیقاً همان‌گونه که در مانیفست آمده است منتقل و نشان داده می‌شود.

عنصر remote

یک یا چند عنصر remote می‌توانند تعیین شوند. هر عنصر remote یک نشانی گیت (Git URL) مشترک میان یک یا چند پروژه و (به‌صورت اختیاری) سرور بازبینی Gerrit را که آن پروژه‌ها تغییرات را از طریقش بارگذاری می‌کنند، مشخص می‌نماید.

مشخصه `name`: یک نام کوتاه و یکتا برای این فایل مانیفست. نام تعیین‌شده در اینجا به‌عنوان نام remote در .git/config هر پروژه استفاده می‌شود، و بنابراین به‌طور خودکار برای دستورهایی مانند `git fetch`، `git remote`، `git pull` و `git push` در دسترس خواهد بود.

مشخصه `alias`: در صورت تعیین، نام مستعار برای بازنویسی و جایگزینی `name` جهت تنظیم به‌عنوان نام remote در .git/config هر پروژه به کار می‌رود. مقدار آن بر خلاف مشخصه `name` که باید در فایل مانیفست یکتا باشد، می‌تواند تکراری باشد. این ویژگی به هر پروژه اجازه می‌دهد نام remote یکسانی داشته باشد که در واقع به نشانی‌های remote متفاوتی اشاره می‌کند.

مشخصه `fetch`: پیشوند نشانی گیت برای تمامی پروژه‌هایی که از این remote استفاده می‌کنند. نام هر پروژه به این پیشوند الحاق می‌شود تا نشانی واقعی مورد استفاده برای کلون کردن پروژه تشکیل شود.

مشخصه `pushurl`: پیشوند نشانی «push» گیت برای تمام پروژه‌هایی که از این remote استفاده می‌کنند. نام هر پروژه به این پیشوند اضافه می‌شود تا نشانی واقعی مورد استفاده برای «git push» پروژه را تشکیل دهد. این مشخصه اختیاری است؛ در صورت عدم تعیین، «git push» از همان نشانی مشخصه `fetch` استفاده خواهد کرد.

مشخصه `review`: نام میزبان (Hostname) سرور Gerrit که بازبینی‌ها توسط `repo upload` به آن بارگذاری می‌شوند. این مشخصه اختیاری است؛ در صورت عدم تعیین، دستور `repo upload` کار نخواهد کرد.

مشخصه `revision`: نام یک شاخه گیت (مانند `main` یا `refs/heads/main`). ریموت‌هایی که revision اختصاصی خود را دارند، revision پیش‌فرض را بازنویسی خواهند کرد.

عنصر default

حداکثر یک عنصر default می‌تواند مشخص شود. مشخصه‌های remote و revision آن زمانی استفاده می‌شوند که یک عنصر project مشخصه remote یا revision اختصاصی خود را تعیین نکرده باشد.

مشخصه `remote`: نام یک عنصر remote که پیش‌تر تعریف شده است. عنصرهای project که فاقد مشخصه remote اختصاصی هستند از این remote استفاده خواهند کرد.

مشخصه `revision`: نام یک شاخه گیت (مانند `main` یا `refs/heads/main`). عنصرهای project که فاقد مشخصه revision اختصاصی هستند از این revision استفاده خواهند کرد.

مشخصه `dest-branch`: نام یک شاخه گیت (مانند `main`). عنصرهای project که `dest-branch` اختصاصی خود را تنظیم نکرده‌اند این مقدار را به ارث خواهند برد. در صورت تنظیم نشدن این مقدار، پروژه‌ها به‌طور پیش‌فرض از `revision` استفاده خواهند کرد.

مشخصه `upstream`: نام ارجاع (ref) گیت که مقدار sha1 در آن یافت می‌شود. در هنگام همگام‌سازی مانیفست قفل‌شده با revision در حالت -c استفاده می‌شود تا از نیاز به همگام‌سازی کل فضای ref جلوگیری شود. عنصرهای project که `upstream` اختصاصی خود را تنظیم نکرده‌اند این مقدار را به ارث می‌برند.

مشخصه `sync-j`: تعداد کارهای موازی (jobs) مورد استفاده هنگام همگام‌سازی.

مشخصه `sync-j-max`: حداکثر تعداد کارهای موازی مورد استفاده هنگام همگام‌سازی.

مشخصه `sync-c`: مقدار true را تعیین کنید تا تنها شاخه گیت داده‌شده (مشخص‌شده در مشخصه `revision`) به جای کل فضای ref همگام‌سازی شود. عنصرهای project که فاقد مشخصه sync-c هستند از این مقدار استفاده خواهند کرد.

مشخصه `sync-s`: مقدار true را تعیین کنید تا زیرپروژه‌ها (sub-projects) نیز همگام‌سازی شوند.

مشخصه `sync-tags`: مقدار false را تعیین کنید تا به جای سایر برچسب‌های ref، تنها شاخه گیت داده‌شده (مشخص‌شده در مشخصه `revision`) همگام‌سازی شود.

عنصر manifest-server

حداکثر یک manifest-server می‌تواند مشخص شود. مشخصه url برای تعیین نشانی یک سرور مانیفست استفاده می‌شود که یک سرویس XML RPC است.

برای جزئیات بیشتر به [مستندات smart sync](./smart-sync.md) مراجعه کنید.

عنصر submanifest

یک یا چند عنصر submanifest می‌توانند مشخص شوند. هر عنصر یک مانیفست منفرد را توصیف می‌کند که باید به‌عنوان فرزند checkout شود.

مشخصه `name`: یک نام یکتا (درون (sub)manifest جاری) برای این submanifest. این مشخصه به‌عنوان مقداری پیش‌فرض برای `revision` در ادامه عمل می‌کند. همین نام می‌تواند برای submanifestهایی با (sub)manifestهای والد مختلف استفاده شود.

مشخصه `remote`: نام یک عنصر remote که پیش‌تر تعریف شده است. در صورت ارائه نشدن، remote ارائه‌شده توسط عنصر default استفاده خواهد شد.

مشخصه `project`: نام پروژه مانیفست. نام پروژه به نشانی fetch مربوط به remote الحاق می‌شود تا نشانی واقعی برای پیکربندی remote گیت تولید گردد. این نشانی به شکل زیر تشکیل می‌شود:

${remote_fetch}/${project_name}.git

که در آن ${remote_fetch} مشخصه fetch مربوط به remote و ${project_name} مشخصه name مربوط به project است. پسوند «.git» همواره الحاق می‌شود چرا که repo فرض می‌کند بالادست (upstream) مجموعه‌ای از مخازن bare گیت است. اگر پروژه عنصری والد داشته باشد، نام آن پیشوند نام والد را خواهد گرفت.

در صورتی که از Gerrit برای بازبینی کد استفاده می‌شود، نام پروژه باید با نامی که Gerrit می‌شناسد مطابقت داشته باشد.

مقدار `project` نباید خالی باشد، و نمی‌تواند یک مسیر مطلق باشد یا از مؤلفه‌های مسیر «.» یا «..» استفاده کند. این مقدار همواره نسبت به تنظیمات fetch ریموت تفسیر می‌شود، بنابراین اگر مسیر پایه متفاوتی مورد نیاز است، یک remote دیگر با تنظیمات جدید مورد نیاز تعریف کنید..PP اگر ارائه نشود، remote و project مربوط به این مانیفست استفاده خواهند شد: مقدار `remote` نمی‌تواند ارائه شود.

پروژه‌های یک submanifest و submanifestهای آن به گروه submanifest::path:<path_prefix> افزوده می‌شوند.

صفت `manifest-name`: نام فایل مانیفست در پروژهٔ مانیفست. اگر ارائه نشود، از `default.xml` استفاده می‌شود.

صفت `revision`: نام یک شاخهٔ Git (مانند «main» یا «refs/heads/main»)، یک برچسب (مانند «refs/tags/stable»)، یا هش یک کامیت. اگر ارائه نشود، از `name` استفاده می‌شود.

صفت `path`: یک مسیر اختیاری نسبت به دایرکتوری بالایی (top directory) کلاینت repo که دایرکتوری بالایی کلاینت repo مربوط به submanifest باید در آنجا قرار گیرد. اگر ارائه نشود، از `revision` استفاده می‌شود.

مقدار `path` نباید یک مسیر مطلق باشد یا از مؤلفه‌های مسیر «.» یا «..» استفاده کند.

صفت `groups`: مجموعه‌ای از گروه‌های اضافی که همهٔ پروژه‌های موجود در submanifest شامل‌شده به آن‌ها تعلق دارند. این عمل پیوست و بازگشتی است، به این معنی که تمام پروژه‌ها در submanifestها همهٔ گروه‌های submanifest والد را به ارث می‌برند. ساختار نحوی آن مشابه عنصر متناظر در `project` است.

صفت `default-groups`: فهرست گروه‌های مانیفست برای همگام‌سازی (sync) در صورتی که هیچ پارامتر `--groups=` هنگام init مشخص نشده باشد. هنگامی که آن فهرست خالی باشد، این فهرست به جای «default» به عنوان فهرست گروه‌های همگام‌سازی استفاده می‌شود.

عنصر project

یک یا چند عنصر project می‌توانند مشخص شوند. هر عنصر، یک مخزن تک Git را برای کلون شدن در فضای کاری کلاینت repo توصیف می‌کند. می‌توانید با ایجاد یک project تودرتو، Git-submoduleها را مشخص کنید. Git-submoduleها به طور خودکار شناسایی شده و صفات والد خود را به ارث می‌برند، اما این صفات می‌توانند توسط یک عنصر project صریح لغو (override) شوند.

صفت `name`: یک نام یکتا برای این پروژه. نام پروژه به نشانی واکشی (fetch URL) ریموت آن پیوست می‌شود تا نشانی واقعی برای پیکربندی remote مربوط به Git تولید شود. نشانی به این صورت ساخته می‌شود:

${remote_fetch}/${project_name}.git

که در آن ${remote_fetch} صفت fetch ریموت و ${project_name} صفت name پروژه است. پسوند «.git» همیشه اضافه می‌شود چرا که repo فرض می‌کند upstream مجموعه‌ای از مخازن bare مربوط به Git است. اگر پروژه یک عنصر والد داشته باشد، نام آن با نام والد پیشوند خواهد خورد.

اگر Gerrit برای بازبینی کد (code review) استفاده می‌شود، نام پروژه باید با نامی که Gerrit می‌شناسد مطابقت داشته باشد.

مقدار «name» نباید خالی باشد، و نباید یک مسیر مطلق بوده یا از مؤلفه‌های مسیر «.» یا «..» استفاده کند. این مقدار همواره نسبت به تنظیمات fetch ریموت تفسیر می‌شود، بنابراین اگر یک مسیر پایهٔ متفاوت نیاز است، یک remote دیگر با تنظیمات مورد نیاز جدید تعریف کنید. این محدودیت‌ها برای [Local Manifests] اعمال نمی‌شوند.

صفت `path`: یک مسیر اختیاری نسبت به دایرکتوری بالایی کلاینت repo که دایرکتوری کاری Git برای این پروژه باید در آن قرار گیرد. در صورت مشخص نشدن، «name» پروژه استفاده می‌شود. اگر پروژه دارای یک عنصر والد باشد، مسیر آن با مسیر والد پیشوند خواهد خورد.

مقدار «path» نباید یک مسیر مطلق باشد یا از مؤلفه‌های مسیر «.» یا «..» استفاده کند. این محدودیت‌ها برای [Local Manifests] اعمال نمی‌شوند.

اگر می‌خواهید فایل‌هایی را در ریشهٔ checkout قرار دهید (مانند یک README یا Makefile یا یک اسکریپت ساخت دیگر)، به جای آن از عناصر [copyfile] یا [linkfile] استفاده کنید.

صفت `remote`: نام یک عنصر remote که قبلاً تعریف شده است. اگر ارائه نشود، remote ارائه‌شده توسط عنصر default استفاده می‌شود.

صفت `revision`: نام شاخهٔ Git که مانیفست می‌خواهد برای این پروژه دنبال کند. نام‌ها می‌توانند نسبت به refs/heads (مانند فقط «main») یا مطلق (مانند «refs/heads/main») باشند. برچسب‌ها (tags) و/یا SHA-1های صریح در تئوری باید کار کنند، اما به طور گسترده آزمایش نشده‌اند. اگر ارائه نشود، در صورت امکان revision ارائه‌شده توسط عنصر remote استفاده می‌شود، وگرنه از عنصر default استفاده خواهد شد.

صفت `dest-branch`: نام یک شاخهٔ Git (مانند `main`). هنگام استفاده از `repo upload`، تغییرات برای بازبینی کد روی این شاخه ارسال خواهند شد. اگر هم در اینجا و هم در عنصر default نامشخص باشد، به جای آن از `revision` استفاده می‌شود.

صفت `groups`: مجموعه‌ای از گروه‌ها که این پروژه به آن‌ها تعلق دارد، با فاصله یا کاما از هم جدا می‌شوند. همهٔ پروژه‌ها به گروه «all» تعلق دارند، و هر پروژه به طور خودکار به گروهی با نام:`name` و مسیر:`path` خود تعلق دارد. به عنوان مثال برای `<project name="monkeys" path="barrel-of"/>`، آن تعریف پروژه به طور ضمنی در این گروه‌های مانیفست قرار دارد: default، name:monkeys، و path:barrel-of. اگر پروژه‌ای را در گروه «notdefault» قرار دهید، به طور خودکار توسط repo دانلود نخواهد شد. اگر پروژه دارای یک عنصر والد باشد، `name` و `path` در اینجا مقادیر پیشونددار خواهند بود.

صفت `sync-c`: برای همگام‌سازی صرفاً شاخهٔ مشخص‌شدهٔ Git (تعیین‌شده در صفت `revision`) به جای کل فضای ref، روی true تنظیم کنید.

صفت `sync-s`: برای همگام‌سازی زیرپروژه‌ها نیز روی true تنظیم کنید.

صفت `upstream`: نام ref مربوط به Git که در آن یک sha1 یافت می‌شود. هنگام همگام‌سازی یک مانیفست قفل‌شده با revision در حالت -c برای جلوگیری از نیاز به همگام‌سازی کل فضای ref استفاده می‌شود.

صفت `clone-depth`: عمق دریافت (fetch) این پروژه را تنظیم می‌کند. در صورت مشخص شدن، این مقدار هر مقداری را که در خط فرمان با گزینهٔ --depth به repo init داده شده است لغو می‌کند (override).

صفت `force-path`: برای وادار کردن این پروژه به ایجاد مخزن آینه‌ای محلی (local mirror) بر اساس صفت `path` (در صورت ارائه) به جای صفت `name`، روی true تنظیم کنید. این صفت تنها در همگام‌سازی آینه‌های محلی اعمال می‌شود و هنگام همگام‌سازی پروژه‌ها در یک دایرکتوری کاری کلاینت نادیده گرفته خواهد شد.

عنصر extend-project

صفات پروژهٔ نام‌برده‌شده را اصلاح می‌کند.

این عنصر عمدتاً در یک فایل مانیفست محلی (local manifest) کاربرد دارد، تا صفات یک پروژهٔ موجود را بدون جایگزینی کامل تعریف موجود پروژه اصلاح کند. این کار باعث استحکام بیشتر مانیفست محلی در برابر تغییرات مانیفست اصلی می‌شود.

عنصر `extend-project` می‌تواند شامل عناصر فرزند `annotation`، `copyfile` و `linkfile` نیز باشد. این‌ها به تعریف پروژه افزوده می‌شوند. یک `copyfile` یا `linkfile` با یک `dest` که از قبل در پروژه وجود دارد، فایل اصلی را بازنویسی (overwrite) خواهد کرد.

صفت `path`: در صورت تعیین، تغییرات را به جای تمام پروژه‌ها با نام داده‌شده، به پروژه‌های تحویل‌گرفته‌شده (checked out) در مسیر مشخص‌شده محدود می‌کند.

صفت `dest-path`: در صورت تعیین، مسیری نسبت به دایرکتوری بالایی کلاینت repo است که دایرکتوری کاری Git برای این پروژه باید در آن قرار گیرد. این صفت برای جابه‌جایی یک پروژه در checkout از طریق لغو تنظیمات `path` موجود استفاده می‌شود.

صفت `groups`: مجموعه‌ای از گروه‌های اضافی که این پروژه به آن‌ها تعلق دارد. ساختار نحوی آن مشابه عنصر متناظر در `project` است.

صفت `revision`: در صورت تعیین، revision پروژهٔ اصلی را بازنویسی می‌کند (override). ساختار نحوی آن مشابه عنصر متناظر در `project` است.

صفت `remote`: در صورت تعیین، remote پروژهٔ اصلی را لغو می‌کند. ساختار نحوی آن مشابه عنصر متناظر در `project` است.

صفت `dest-branch`: در صورت تعیین، dest-branch پروژهٔ اصلی را لغو می‌کند. ساختار نحوی آن مشابه عنصر متناظر در `project` است.

صفت `upstream`: در صورت تعیین، upstream پروژهٔ اصلی را لغو می‌کند. ساختار نحوی آن مشابه عنصر متناظر در `project` است.

صفت `base-rev`: در صورت تعیین، بررسی‌ای در برابر revision مورد گسترش اضافه می‌کند. اگر revisionهای در حال گسترش از زمان تعیین base-rev تغییر کرده باشند، تجزیهٔ مانیفست با شکست مواجه شده و فهرستی از عدم‌تطابق‌های extend ارائه می‌دهد. این صفت برای استفاده در مانیفست‌های لایه‌ای با revisionهای هش طراحی شده تا از پنهان کردن revisionهای جدیدتر upstream توسط شاخه‌های وصله (patch branches) جلوگیری کند. همچنین refهای نام‌گذاری‌شده مانند شاخه‌ها یا تگ‌ها را مقایسه می‌کند، اما اگر شاخه‌ها به عنوان base-rev استفاده شوند ممکن است گمراه‌کننده باشد. ساختار نحوی آن مشابه عنصر متناظر در `project` است.

عنصر annotation

صفر یا چند عنصر annotation می‌توانند به عنوان فرزندان یک عنصر project، یک عنصر extend-project یا یک عنصر remote مشخص شوند. هر عنصر یک جفت نام-مقدار (name-value) را توصیف می‌کند. برای پروژه‌ها، این جفت نام-مقدار در حین اجرای دستور 'forall' با پیشوند `REPO__` به محیط هر پروژه صادر (export) خواهد شد. علاوه بر این، یک صفت اختیاری "keep" وجود دارد که مقادیر غیرحساس به حروف بزرگ و کوچک "true" (پیش‌فرض) یا "false" را می‌پذیرد. این صفت مشخص می‌کند که آیا هنگام برون‌ریزی با زیردستور manifest، یادداشت (annotation) حفظ شود یا خیر.

عنصر copyfile

صفر یا چند عنصر copyfile می‌توانند به عنوان فرزندان یک عنصر project یا یک عنصر extend-project مشخص شوند. هر عنصر یک جفت فایل src-dest را توصیف می‌کند؛ در طول دستور `repo sync`، فایل "src" در محل "dest" کپی خواهد شد.

مقدار "src" نسبت به پروژه است و "dest" نسبت به بالای درخت (top of the tree). کپی کردن از مسیرهای خارج از پروژه یا به مسیرهای خارج از کلاینت repo مجاز نیست.

مقادیر "src" و "dest" باید فایل باشند. دایرکتوری‌ها یا پیوندهای نمادین (symlinks) مجاز نیستند. مسیرهای میانی نیز نباید پیوند نمادین باشند.

دایرکتوری‌های والد "dest" در صورت وجود نداشتن، به طور خودکار ایجاد خواهند شد..PP فایل‌ها به همان ترتیبی که در مانیفست‌ها مشخص شده‌اند کپی می‌شوند. اگر چندین عنصر مبدا و مقصد یکسانی را مشخص کنند، تنها بر اساس نخستین رخداد و به عنوان یک مورد اعمال خواهند شد. فایل‌ها پیش از ایجاد هرگونه پیوند تعیین‌شده توسط عنصرهای linkfile کپی می‌شوند.

عنصر linkfile

دقیقاً مانند copyfile است، اما به جای کپی کردن، یک پیوند نمادین (symlink) می‌سازد.

پیوند نمادین در "dest" (به صورت نسبی نسبت به بالای درخت) ایجاد شده و به مسیری اشاره می‌کند که با "src" مشخص شده است که مسیری درون پروژه است.

دایرکتوری‌های والد "dest" در صورت عدم وجود، به‌طور خودکار ایجاد می‌شوند.

هدف پیوند نمادین می‌تواند یک فایل یا دایرکتوری باشد، اما نباید به خارج از کلاینت repo اشاره کند.

پیوندها به همان ترتیبی که در مانیفست‌ها مشخص شده‌اند ایجاد می‌شوند. اگر چندین عنصر مبدا و مقصد یکسانی را مشخص کنند، تنها بر اساس نخستین رخداد و به عنوان یک مورد اعمال خواهند شد. پیوندها پس از کپی شدن فایل‌های تعیین‌شده از طریق عنصرهای copyfile ایجاد می‌شوند.

عنصر remove-project

پروژه‌ای را از جدول داخلی مانیفست حذف می‌کند و احتمالاً به عنصر بعدی project در همان فایل مانیفست اجازه می‌دهد تا پروژه را با مبدأیی دیگر جایگزین کند.

این عنصر بیشتر در فایل‌های مانیفست محلی (local manifest) کاربرد دارد، جایی که کاربر می‌تواند پروژه‌ای را حذف کرده و احتمالاً آن را با تعریف خود جایگزین کند.

مشخصه `name` پروژه یا `path` پروژه می‌تواند برای تعیین هدف حذف به کار رود، به این معنی که وجود یکی از آن‌ها الزامی است. اگر تنها name مشخص شود، تمامی پروژه‌های دارای آن نام حذف خواهند شد.

اگر هر دو مشخصه name و path مشخص شوند، تنها پروژه‌هایی با نام و مسیر یکسان حذف می‌شوند، به این معنی که پروژه‌هایی با همان نام ولی در مکان‌های دیگر نگه داشته می‌شوند.

اگر تنها path مشخص شود، پروژه منطبق بدون در نظر گرفتن نام آن حذف می‌شود. در غیر این صورت، منطق مانند حالتی رفتار می‌کند که هر دو مشخص شده باشند.

مشخصه `optional`: برای نادیده گرفتن عنصرهای remove-project فاقد عنصر `project` منطبق، روی true تنظیم کنید.

مشخصه `base-rev`: در صورت تعیین، بررسی‌هایی را نسبت به نگارش (revision) مورد نظر برای حذف اضافه می‌کند. اگر نگارش‌های در حال حذف از زمان تنظیم base-rev تغییر کرده باشند، تجزیه مانیفست با شکست مواجه شده و فهرستی از موارد عدم تطابق ارائه می‌دهد. این ویژگی برای استفاده در مانیفست‌های لایه‌ای با نگارش‌های هش طراحی شده تا مانع از پنهان‌سازی نگارش‌های جدیدتر بالادست توسط شاخه‌های وصله (patch) شود. همچنین ارجاعات نام‌گذاری شده مانند شاخه‌ها یا تگ‌ها را مقایسه می‌کند، اما اگر از شاخه‌ها به عنوان base-rev استفاده شود ممکن است گمراه‌کننده باشد. ساختار دستوری آن مشابه عنصر متناظر در `project` است.

عنصر repo-hooks

نکته: برای نحوه استفاده از قلاب‌های repo به [مستندات کاربردی](./repo-hooks.md) مراجعه کنید.

در هر زمان تنها یک عنصر repo-hooks می‌تواند تعیین شود. تلاش برای تعریف مجدد آن باعث خطای تجزیه خواهد شد.

مشخصه `in-project`: پروژه‌ای که قلاب‌ها در آن تعریف شده‌اند. مقدار آن باید با مشخصه `name` (**نه** مشخصه `path`) از یک عنصر `project` که پیش‌تر تعریف شده مطابقت داشته باشد.

مشخصه `enabled-list`: فهرستی از قلاب‌های مورد استفاده، جدا شده با فاصله یا کاما.

عنصر superproject

*** *یادداشت*: این بخش در حال حاضر در دست توسعه است. ***

نکته: برای اطلاعات زمینه‌ای به [مستندات ابرپروژه‌های git](https://en.wikibooks.org/wiki/Git/Submodules_and_Superprojects) مراجعه کنید.

این عنصر برای مشخص کردن URL مربوط به ابرپروژه (superproject) استفاده می‌شود. این عنصر "name" و "remote" را به عنوان مشخصه داراست. تنها مشخصه "name" الزامی است و بقیه دارای پیش‌فرض‌های منطقی هستند. حداکثر یک superproject می‌تواند تعیین شود. تلاش برای تعریف مجدد آن باعث خطای تجزیه می‌شود.

مشخصه `name`: یک نام منحصر‌به‌فرد برای ابرپروژه. این مشخصه معنایی مشابه با مشخصه name در project دارد. برای اطلاعات بیشتر به [عنصر project](#element-project) مراجعه کنید.

مشخصه `remote`: نام یک عنصر remote که پیش‌تر تعریف شده است. در صورت عدم تعیین، از ریموت مشخص‌شده توسط عنصر default استفاده خواهد شد.

مشخصه `revision`: نام شاخه Git که مانیفست می‌خواهد برای این ابرپروژه دنبال کند. در صورت عدم ارائه، در صورت امکان از نگارش تعیین‌شده توسط عنصر remote استفاده می‌شود، در غیر این صورت از عنصر default استفاده خواهد شد.

عنصر contactinfo

*** *یادداشت*: این بخش در حال حاضر در دست توسعه است. ***

این عنصر به نویسندگان مانیفست اجازه می‌دهد تا اطلاعات تماس خود را ثبت کنند. دارای مشخصه الزامی "bugurl" است. این عنصر می‌تواند تکرار شود، و هر ورودی جدیدتر، موارد قبلی را بازنویسی خواهد کرد. این به نویسندگانی که مانیفست‌ها را گسترش می‌دهند اجازه می‌دهد اطلاعات تماس خود را تعیین کنند.

مشخصه `bugurl`: نشانی URL برای ثبت گزارش باگ در ارتباط با مالک مانیفست.

عنصر include

این عنصر قابلیت گنجاندن یک فایل مانیفست دیگر را در مانیفست مبدأ فراهم می‌کند. قوانین عادی برای مانیفست مقصد اعمال می‌شود - یعنی باید به خودی خود یک مانیفست قابل استفاده باشد.

مشخصه `name`: مانیفستی که باید گنجانده شود، مشخص‌شده به صورت نسبی با ریشه مخزن مانیفست.

مقدار "name" نباید یک مسیر مطلق باشد یا از بخش‌های مسیری مانند "." یا ".." استفاده کند. این محدودیت‌ها برای [مانیفست‌های محلی] اعمال نمی‌شوند.

مشخصه `groups`: مجموعه‌ای از گروه‌های اضافی که تمام پروژه‌های درون مانیفست گنجانده‌شده به آن‌ها تعلق می‌گیرند. این عملکرد به صورت الحاقی و بازگشتی است، به این معنی که تمام پروژه‌ها در مانیفست‌های گنجانده‌شده، تمامی گروه‌های include والد را با خود به همراه دارند. این موضوع همچنین برای تمام عنصرهای extend-project در مانیفست‌های گنجانده‌شده نیز اعمال می‌شود. ساختار دستوری مشابه عنصر متناظر در `project` دارد.

مشخصه `revision`: نام یک شاخه پیش‌فرض در Git (مانند `main` یا `refs/heads/main`) که تمام پروژه‌های درون مانیفست گنجانده‌شده به آن تعلق دارند. این عملکرد بازگشتی است، به این معنی که برای تمامی پروژه‌ها در تمامی مانیفست‌هایی که در نتیجه این عنصر اضافه شده‌اند اعمال خواهد شد.

مانیفست‌های محلی (Local Manifests)

ریموت‌ها و پروژه‌های بیشتر می‌توانند از طریق فایل‌های مانیفست محلی ذخیره‌شده در مسیر `$TOP_DIR/.repo/local_manifests/*.xml` اضافه شوند.

به عنوان مثال:

$ ls .repo/local_manifests
local_manifest.xml another_local_manifest.xml
$ cat .repo/local_manifests/local_manifest.xml
<?xml version="1.0" encoding="UTF-8"?> <manifest>
<project path="manifest"
name="tools/manifest" />
<project path="platform-manifest"
name="platform/manifest" />
</manifest>

کاربران می‌توانند پیش از اجرای `repo sync`، پروژه‌هایی را به مانیفست(های) محلی اضافه کنند تا به repo دستور دهند به‌طور خودکار این پروژه‌های اضافی را دانلود و مدیریت کند.

فایل‌های مانیفست ذخیره‌شده در `$TOP_DIR/.repo/local_manifests/*.xml` به ترتیب حروف الفبا بارگذاری خواهند شد.

پروژه‌های برگرفته از فایل‌های مانیفست محلی به گروه local::<local manifest filename> اضافه می‌شوند.

مسیر قدیمی `$TOP_DIR/.repo/local_manifest.xml` دیگر پشتیبانی نمی‌شود..SS [copyfile]: #Element-copyfile [linkfile]: #Element-linkfile [Local Manifests]:

#local-manifests

مارس ۲۰۲۶ repo manifest