ساخت مخزن (Repository creation)

clone

تهیهٔ یک رونوشت از یک مخزن موجود:

hg clone [OPTION]... SOURCE [DEST]

ایجاد یک رونوشت از یک مخزن موجود در یک دایرکتوری جدید.

اگر نام دایرکتوری مقصد مشخص نشده باشد، به‌طور پیش‌فرض نام پایهٔ (basename) مبدأ در نظر گرفته می‌شود.

مکان مبدأ به فایل .hg/hgrc مخزن جدید افزوده می‌شود تا به عنوان پیش‌فرضی برای pullهای آینده استفاده شود.

تنها مسیرهای محلی و نشانی‌های ssh:// به عنوان مقصد پشتیبانی می‌شوند. برای مقصدهای ssh://، هیچ دایرکتوری کاری یا فایل .hg/hgrc در سمت دوردست (remote) ایجاد نخواهد شد.

اگر در مخزن مبدأ نشانکی (bookmark) به نام '@' تنظیم شده باشد، آن بازنگری به‌طور پیش‌فرض در مخزن جدید استخراج (checked out) خواهد شد.

برای استخراج یک نسخهٔ خاص از -u/--update، یا از -U/--noupdate برای ایجاد یک شبیه‌سازی (clone) بدون دایرکتوری کاری استفاده کنید.

برای دریافت تنها زیرمجموعه‌ای از مجموعه‌تغییرات (changesets)، یک یا چند شناسهٔ بازنگری را با -r/--rev یا شاخه‌ها را با -b/--branch مشخص کنید. مخزن شبیه‌سازی‌شدهٔ حاصل تنها شامل مجموعه‌تغییرات مشخص‌شده و نیاکان آن‌ها خواهد بود. این گزینه‌ها (یا 'clone src#rev dest') متضمن استفاده از --pull هستند، حتی برای مخازن مبدأ محلی.

در حالت عادیِ شبیه‌سازی، سمت دوردست داده‌های مخزن را به یک قالب تبادل مشترک تبدیل می‌کند و طرف گیرنده این داده‌ها را به قالب ذخیره‌سازی محلی خود برمی‌گرداند. گزینهٔ --stream حالت شبیه‌سازی متفاوتی را فعال می‌کند که اساساً فایل‌های مخزن را از سمت دوردست با کمترین پردازش داده کپی می‌کند. این کار بار پردازشی (CPU) شبیه‌سازی را چه از راه دور و چه به‌صورت محلی به‌طور چشمگیری کاهش می‌دهد. با این حال، معمولاً اندازهٔ داده‌های منتقل‌شده را ۳۰ تا ۴۰ درصد افزایش می‌دهد. این امر در مواردی که پهنای باند و توان ورودی/خروجی (I/O) فراوان است، به‌ویژه برای مخازن بزرگ‌تر، می‌تواند منجر به شبیه‌سازی بسیار سریع‌تر شود. یکی از اثرهای جانبی شبیه‌سازی با --stream این است که تنظیمات و الزامات ذخیره‌سازی روی سرور دوردست به‌صورت محلی اعمال می‌شوند: یک کلاینت امروزی ممکن است قالب ذخیره‌سازی قدیمی یا ناکارآمد مورد استفادهٔ سرور دوردست را به ارث ببرد، یا یک کلاینت قدیمی Mercurial ممکن است نتواند از یک سرور دوردست مدرن Mercurial شبیه‌سازی را انجام دهد.

نکته (Note)

مشخص کردن یک برچسب (tag)، مجموعه‌تغییرات برچسب‌خورده را شامل می‌شود اما مجموعه‌تغییراتی را که حاوی آن برچسب است در بر نمی‌گیرد.

برای افزایش کارایی، هر زمان که مبدأ و مقصد روی یک سیستم‌فایل باشند، از پیوندهای سخت (hardlinks) برای شبیه‌سازی استفاده می‌شود (توجه داشته باشید این موضوع تنها بر داده‌های مخزن اعمال می‌شود، نه بر دایرکتوری کاری). برخی سیستم‌های فایل مانند AFS، پیوند سخت را به‌نادرستی پیاده‌سازی می‌کنند اما خطایی نیز گزارش نمی‌دهند. در این موارد، از گزینهٔ --pull برای جلوگیری از ایجاد پیوندهای سخت استفاده کنید.

ابزار Mercurial دایرکتوری کاری را به اولین بازنگری قابل‌اعمال از این فهرست به‌روزرسانی (update) خواهد کرد:

هنگام شبیه‌سازی از سرورهایی که از آن پشتیبانی می‌کنند، Mercurial ممکن است داده‌های از پیش تولیدشده را از یک نشانی اینترنتی اعلام‌شده توسط سرور، یا به‌صورت درون‌خطی از همان جریان واکشی کند. وقتی این کار انجام می‌شود، قلاب‌هایی (hooks) که روی مجموعه‌تغییرات و changegroupهای دریافتی عمل می‌کنند ممکن است بیش از یک بار فعال شوند؛ یک بار برای هر بستهٔ (bundle) از پیش تولیدشده و همچنین برای هر دادهٔ باقی‌ماندهٔ دیگر. علاوه بر این، در صورت بروز خطا، مخزن ممکن است به یک شبیه‌سازی ناقص بازگردانده (rolled back) شود. این رفتار ممکن است در نسخه‌های آینده تغییر کند. برای اطلاعات بیشتر hg help -e clonebundles را ببینید.

مثال‌ها:

برای جزئیات مربوط به مشخص کردن URLها، hg help urls را ببینید.

در صورت موفقیت 0 را برمی‌گرداند.

گزینه‌ها:

گزینهٔ مشخص‌شده با [+] را می‌توان چندین بار مشخص کرد

init

ایجاد یک مخزن جدید در دایرکتوری داده‌شده:

hg init [-e CMD] [--remotecmd CMD] [DEST]

یک مخزن جدید در دایرکتوری داده‌شده مقداردهی اولیه می‌کند. اگر دایرکتوری داده‌شده وجود نداشته باشد، ایجاد خواهد شد.

اگر هیچ دایرکتوری‌ای داده نشود، از دایرکتوری جاری استفاده می‌شود.

امکان مشخص کردن یک نشانی اینترنتی ssh:// به عنوان مقصد وجود دارد. برای اطلاعات بیشتر hg help urls را ببینید.

در صورت موفقیت 0 را برمی‌گرداند.

گزینه‌ها:

مدیریت مخزن دوردست (Remote repository management)

incoming

نمایش مجموعه‌تغییرهای جدیدِ یافت‌شده در مبدأ:

hg incoming [-p] [-n] [-M] [-f] [-r REV]... [--bundle FILENAME] [SOURCE]

نمایش مجموعه‌تغییرهای جدیدِ یافت‌شده در مسیر/نشانی اینترنتی مشخص‌شده یا مکان پیش‌فرض واکشی (pull). این‌ها مجموعه‌تغییرهایی هستند که در زمان اجرای این دستور توسط hg pull واکشی می‌شدند.

برای جزئیات قالب‌های معتبر مبدأ، pull را ببینید.

با -B/--bookmarks، نتیجهٔ مقایسهٔ بوک‌مارک‌ها بین مخازن محلی و دوردست نمایش داده می‌شود. با -v/--verbose، وضعیت هر بوک‌مارک نیز مطابق زیر نمایش می‌یابد:

BM1               01234567890a added
BM2               1234567890ab advanced
BM3               234567890abc diverged
BM4               34567890abcd changed

عملی که هنگام دریافت (pull) به صورت محلی انجام می‌شود به وضعیت هر بوک‌مارک بستگی دارد:

از نقطه نظر رفتار واکشی، بوک‌مارک‌هایی که فقط در مخزن دوردست وجود دارند به عنوان added در نظر گرفته می‌شوند، حتی اگر در واقع به صورت محلی حذف شده باشند.

برای مخزن دوردست، در صورتی که پس از incoming دستور pull اجرا شود، استفاده از --bundle از بارگیری دوبارهٔ مجموعه‌تغییرها جلوگیری می‌کند.

مثال‌ها:

اگر تغییرات ورودی وجود داشته باشد 0 و در غیر این صورت 1 را برمی‌گرداند.

گزینه‌ها:

گزینه‌های مشخص‌شده با [+] را می‌توان چندین بار تعیین کرد

outgoing

نمایش مجموعه‌تغییراتی که در مقصد یافت نشدند:

hg outgoing [-M] [-p] [-n] [-f] [-r REV]... [DEST]...

نمایش مجموعه‌تغییراتی که در مخزن مقصدِ مشخص‌شده یا مکان پیش‌فرض push یافت نمی‌شوند. این‌ها مجموعه‌تغییراتی هستند که در صورت درخواست push، ارسال خواهند شد.

برای جزئیات قالب‌های معتبر مقصد، pull را ببینید.

با -B/--bookmarks، نتیجه مقایسه نشانک‌ها (bookmarks) بین مخازن محلی و دوردست نمایش داده می‌شود. با -v/--verbose، وضعیت هر نشانک نیز مانند زیر نمایش داده می‌شود:

BM1               01234567890a added
BM2                            deleted
BM3               234567890abc advanced
BM4               34567890abcd diverged
BM5               4567890abcde changed

اقدام انجام‌شده هنگام ارسال (push) به وضعیت هر نشانک بستگی دارد:

از دیدگاه رفتار عملیات push، نشانک‌هایی که تنها در مخزن دوردست وجود دارند، به عنوان deleted در نظر گرفته می‌شوند، حتی اگر در واقع در سمت دوردست اضافه شده باشند.

در صورت وجود تغییرات ارسالی (outgoing)، مقدار 0 و در غیر این صورت 1 را برمی‌گرداند.

گزینه‌ها:

گزینه علامت‌گذاری‌شده با [+] می‌تواند چندین بار مشخص شود

paths

نمایش نام‌های مستعار مخازن ریموت:

hg paths [NAME]

نمایش تعریف نام نمادین مسیر NAME. اگر نامی مشخص نشود، تعریف تمام نام‌های موجود نمایش داده می‌شود.

گزینه -q/--quiet هنگام جستجوی NAME تمام خروجی‌ها را سرکوب می‌کند و هنگام فهرست کردن تمام تعاریف، تنها نام مسیرها را نشان می‌دهد.

نام‌های مسیر در بخش [paths] فایل پیکربندی شما و در /etc/mercurial/hgrc تعریف می‌شوند. در صورت اجرا در داخل یک مخزن، .hg/hgrc نیز استفاده می‌شود.

نام‌های مسیر default و default-push معنای ویژه‌ای دارند. هنگام انجام عملیات push یا pull، در صورتی که مکانی در خط فرمان مشخص نشده باشد، این نام‌ها به‌عنوان جایگزین استفاده می‌شوند. هنگامی که default-push تنظیم شده باشد، برای push و از default برای pull استفاده خواهد شد؛ در غیر این صورت default به‌عنوان جایگزین برای هر دو به کار می‌رود. هنگام clone کردن یک مخزن، منبع clone به‌صورت default در .hg/hgrc نوشته می‌شود.

نکته

default و default-push برای تمام عملیات‌های ورودی (مانند hg incoming) و خروجی (مانند hg outgoing، hg email و hg bundle) اعمال می‌شوند.

برای اطلاعات بیشتر، hg help urls را ببینید.

قالب:

کلیدواژه‌های زیر پشتیبانی می‌شوند. همچنین hg help templates را ببینید.

در صورت موفقیت 0 را برمی‌گرداند.

گزینه‌ها:

hg push [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [DEST]...

اگر از -r/--rev استفاده شود، بازبینی (revision) مشخص‌شده و تمام نیاکان آن به مخزن دوردست ارسال خواهند شد.

اگر از -B/--bookmark استفاده شود، بازبینی بوکمارک‌شدهٔ مشخص، نیاکان آن و خود بوکمارک به مخزن دوردست ارسال خواهند شد. مشخص کردن . معادل تعیین نام بوکمارک فعال است. برای ارسال تمام بوکمارک‌های جاری از گزینهٔ --all-bookmarks استفاده کنید.

لطفاً برای جزئیات مهم دربارهٔ نشانی‌های اینترنتی ssh:// بخش hg help urls را ببینید. اگر DESTINATION حذف شود، از یک مسیر پیش‌فرض استفاده خواهد شد.

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

گزینهٔ --pushvars رشته‌هایی را به سرور می‌فرستد که با پیشوند HG_USERVAR_ تبدیل به متغیرهای محیطی می‌شوند. برای مثال، --pushvars ENABLE_FEATURE=true متغیر HG_USERVAR_ENABLE_FEATURE=true را به عنوان بخشی از محیط قلاب‌های سمت سرور در اختیار آن‌ها قرار می‌دهد.

گزینهٔ pushvars می‌تواند امکان بازنویسی قلاب‌ها توسط کاربر و همچنین تنظیم سطوح اشکال‌زدایی (debug) را فراهم کند. یک نمونه، داشتن قلابی است که کامیت‌های حاوی نشانگرهای تعارض (conflict markers) را مسدود می‌کند، اما به کاربر اجازه می‌دهد در صورتی که فایل برای اهداف آزمایشی از نشانگرهای تعارض استفاده کرده یا قالب فایل حاوی رشته‌هایی شبیه به نشانگرهای تعارض باشد، قلاب را بازنویسی (override) کند.

به‌طور پیش‌فرض، سرورها --pushvars را نادیده می‌گیرند. برای فعال‌سازی آن، موارد زیر را به فایل پیکربندی خود بیفزایید:

[push]
pushvars.server = true

در صورت موفقیت‌آمیز بودن push مقدار 0، و در صورتی که چیزی برای ارسال وجود نداشته باشد مقدار 1 را برمی‌گرداند.

گزینه‌ها:

گزینه‌های دارای علامت [+] را می‌توان چندین بار مشخص کرد.SS serve

راه‌اندازی وب‌سرور مستقل:

hg serve [OPTION]...

یک مرورگر مخزن و سرور pull محلی تحت HTTP را راه‌اندازی می‌کند. می‌توانید از این قابلیت برای اشتراک‌گذاری و مرور موقت (ad-hoc) مخازن استفاده کنید. توصیه می‌شود برای سرویس‌دهی به یک مخزن در بازه‌های زمانی طولانی‌تر، از یک وب‌سرور واقعی استفاده نمایید.

لطفاً توجه داشته باشید که سرور کنترل دسترسی را پیاده‌سازی نمی‌کند. این بدان معناست که به‌طور پیش‌فرض، هر کسی می‌تواند از سرور بخواند و هیچ‌کس به طور پیش‌فرض نمی‌تواند روی آن بنویسد. گزینهٔ web.allow-push را روی * تنظیم کنید تا به همه اجازهٔ push کردن به سرور داده شود. اگر نیاز به احراز هویت کاربران دارید، باید از یک وب‌سرور واقعی استفاده کنید.

به‌طور پیش‌فرض، سرور گزارش دسترسی‌ها را در stdout و خطاها را در stderr ثبت می‌کند. از گزینه‌های -A/--accesslog و -E/--errorlog برای ثبت گزارش‌ها در فایل استفاده کنید.

برای اینکه سرور یک شماره پورت آزاد را برای گوش دادن انتخاب کند، شماره پورت را 0 مشخص کنید؛ در این حالت، سرور شماره پورتی را که استفاده می‌کند چاپ خواهد کرد.

در صورت موفقیت 0 را برمی‌گرداند.

گزینه‌ها:

گزینهٔ علامت‌گذاری‌شده با [+] می‌تواند چندین بار مشخص شود.SS ایجاد تغییرات

commit

ثبت فایل‌های مشخص‌شده یا تمامی تغییرات باقی‌مانده:

hg commit [OPTION]... [FILE]...

تغییرات فایل‌های مشخص‌شده را در مخزن ثبت می‌کند. بر خلاف یک SCM متمرکز، این یک عملیات محلی است. برای روشی جهت توزیع فعالانهٔ تغییرات خود، hg push را ببینید.

اگر فهرستی از فایل‌ها مشخص نشود، تمامی تغییرات گزارش‌شده توسط hg status ثبت خواهند شد.

اگر در حال ثبت نتیجهٔ یک ادغام (merge) هستید، هیچ نام فایل یا فیلترهای -I/-X را مشخص نکنید.

اگر هیچ پیام ثبتی مشخص نشده باشد، Mercurial ویرایشگر پیکربندی‌شدهٔ شما را اجرا می‌کند که در آن می‌توانید پیامی وارد کنید. در صورتی که ثبت با شکست مواجه شود، یک نسخهٔ پشتیبان از پیام خود را در .hg/last-message.txt خواهید یافت.

پرچم --close-branch می‌تواند برای علامت‌گذاری نوک (head) شاخهٔ جاری به عنوان بسته‌شده استفاده شود. هنگامی که تمام نوک‌های یک شاخه بسته شوند، آن شاخه بسته‌شده تلقی شده و دیگر در فهرست نمایش داده نخواهد شد.

پرچم --amend می‌تواند برای اصلاح والد دایرکتوری کاری با یک ثبت جدید استفاده شود که علاوه بر تغییراتی که در حال حاضر توسط hg status گزارش می‌شوند، حاوی تغییرات موجود در والد نیز هست (در صورت وجود). ثبت قدیمی در یک بستهٔ پشتیبان (backup bundle) در .hg/strip-backup ذخیره می‌شود (برای نحوهٔ بازیابی آن، hg help bundle و hg help unbundle را ببینید).

پیام، کاربر و تاریخ از ثبت اصلاح‌شده گرفته می‌شوند مگر آنکه مشخص شده باشند. هنگامی که پیامی در خط فرمان مشخص نشده باشد، ویرایشگر با پیامِ ثبت اصلاح‌شده باز خواهد شد.

امکان اصلاح مجموعه‌تغییرات (changeset) عمومی (نگاه کنید به hg help phases) یا مجموعه‌تغییراتی که فرزند دارند وجود ندارد.

برای فهرستی از قالب‌های معتبر -d/--date به hg help dates مراجعه کنید.

در صورت موفقیت 0، و در صورتی که چیزی تغییر نکرده باشد 1 را برمی‌گرداند.

مثال‌ها:

گزینه‌ها:

گزینه‌های علامت‌گذاری‌شده با [+] می‌توانند چندین بار مشخص شوند

abort

لغو یک عملیات ناتمام (آزمایشی):

hg abort

یک عملیات چندمرحله‌ای مانند graft، histedit، rebase، merge و unshelve را در صورتی که در وضعیتی ناتمام باشند لغو می‌کند.

از --dry-run/-n برای اجرای آزمایشی دستور استفاده کنید.

گزینه‌ها:

backout

معکوس کردن اثر changeset پیشین:

hg backout [OPTION]... [-r] REV

یک changeset جدید را آماده می‌کند که در آن اثر REV در دایرکتوری کاری فعلی خنثی شده است. اگر هیچ تداخلی وجود نداشته باشد، فوراً کامیت خواهد شد.

اگر REV والد دایرکتوری کاری باشد، این changeset جدید به‌طور خودکار کامیت می‌شود (مگر اینکه --no-commit مشخص شده باشد).

نکته

از hg backout نمی‌توان برای اصلاح یک merge ناخواسته یا نادرست استفاده کرد.

مثال‌ها:

به‌طور پیش‌فرض، changeset در انتظار یک والد خواهد داشت که تاریخچه خطی را حفظ می‌کند. با --merge، این changeset در انتظار در عوض دو والد خواهد داشت: والد قدیمی دایرکتوری کاری و یک فرزند جدید از REV که به‌سادگی REV را خنثی می‌کند.

قبل از نسخه 1.7، رفتار بدون --merge معادل تعیین --merge و به دنبال آن hg update --clean . برای لغو merge و باقی گذاشتن فرزند REV به عنوان یک head بود تا به طور جداگانه ادغام شود.

برای فهرستی از قالب‌های معتبر برای -d/--date به hg help dates مراجعه کنید.

برای روشی جهت بازگرداندن فایل‌ها به وضعیت یک بازبینی دیگر، به hg help revert مراجعه کنید.

در صورت موفقیت 0، و اگر چیزی برای backout وجود نداشته باشد یا فایل‌های حل‌نشده باقی مانده باشند، 1 برمی‌گرداند.

گزینه‌ها:

گزینه‌های مشخص‌شده با [+] را می‌توان چندین بار تعیین کرد.SS continue

یک عملیات متوقف‌شده را از سر می‌گیرد (آزمایشی):

hg continue

یک عملیات چندمرحله‌ای مانند graft، histedit، rebase، merge و unshelve را در صورتی که در وضعیت متوقف‌شده باشند، به پایان می‌رساند.

برای اجرای آزمایشی دستور از --dry-run/-n استفاده کنید.

گزینه‌ها:

graft

تغییرات را از سایر شاخه‌ها به شاخهٔ فعلی کپی می‌کند:

hg graft [OPTION]... [-r REV]... REV...

این دستور از منطق ادغام (merge) در Mercurial برای کپی کردن تغییرات مجزا از سایر شاخه‌ها بدون ادغام شاخه‌ها در گراف تاریخچه استفاده می‌کند. این عمل گاهی با عنوان 'backporting' یا 'cherry-picking' شناخته می‌شود. به‌طور پیش‌فرض، graft کاربر، تاریخ و توضیحات را از دسته‌تغییرات (changesets) مبدأ کپی می‌کند.

دسته‌تغییراتی که نیاکان بازبینی فعلی باشند، قبلاً graft شده باشند، یا از نوع ادغام (merge) باشند، نادیده گرفته خواهند شد.

اگر --log مشخص شده باشد، توضیحی به شکل زیر به انتهای پیام‌های گزارش اضافه خواهد شد:

(grafted from CHANGESETHASH)

اگر --force مشخص شده باشد، بازبینی‌ها حتی اگر از قبل نیاکان مقصد باشند یا به مقصد graft شده باشند، اعمال خواهند شد. این مورد زمانی مفید است که بازبینی‌ها از آن زمان واگردانی (backed out) شده باشند.

اگر یک ادغام graft به تداخل بیانجامد، فرایند graft متوقف می‌شود تا ادغام فعلی بتواند به‌صورت دستی رفع شود. پس از برطرف شدن همهٔ تداخل‌ها، فرایند graft را می‌توان با گزینهٔ -c/--continue ادامه داد.

گزینهٔ -c/--continue تمام گزینه‌های قبلی را مجدداً اعمال می‌کند.

گزینهٔ --base اطلاعات بیشتری را دربارهٔ چگونگی استفادهٔ درونی graft از merge با یک بازبینی پایهٔ سفارشی نشان می‌دهد. از --base می‌توان برای مشخص کردن نیاکانی غیر از نخستین و تنها والد استفاده کرد.

دستور:

hg graft -r 345 --base 234

بنابراین کم‌وبیش معادل دستور زیر است:

hg diff --from 234 --to 345 | hg import

اما از ادغام برای حل تداخل‌ها و ردگیری فایل‌های جابه‌جاشده استفاده می‌کند.

بنابراین می‌توان نتیجهٔ یک ادغام را با مشخص کردن یکی از والدین ادغام به‌عنوان base، در قالب یک commit واحد منتقل (backport) کرد و در نتیجه تغییرات طرف دیگر را به‌طور مؤثر graft نمود.

همچنین می‌توان با مشخص کردن نیاکانی دیگر به‌عنوان base، چندین دسته‌تغییر را یکپارچه (collapse) کرده و تاریخچه را پاکسازی نمود، بسیار شبیه به rebase --collapse --keep.

پیام commit را می‌توان پس از انجام کار با استفاده از commit --amend اصلاح کرد.

برای استفاده از غیرنیاکان به‌عنوان base جهت واگردانی تغییرات، دستور backout و گزینهٔ پنهان --parent را ببینید.

گزینهٔ آزمایشی --to امکان graft کردن یک بازبینی را به‌صورت درون‌حافظه‌ای و مستقل از نسخهٔ کاری (working copy) فراهم می‌کند. تداخل‌های ادغام در حال حاضر پشتیبانی نمی‌شوند و چنانچه ابزار پیکربندی‌شده نتواند تداخل‌های پیش‌آمده را مدیریت کند، عملیات لغو خواهد شد.

از آنجا که عملیات در حافظه انجام می‌شود، فایل‌های روی دیسک تغییر نخواهند کرد و ممکن است برخی قلاب‌ها (hooks) اجرا نشوند.

مثال‌ها:

برای اطلاعات بیشتر دربارهٔ مشخص کردن بازبینی‌ها، hg help revisions را ببینید.

در صورت موفقیت 0 و در صورت وجود فایل‌های حل‌نشده 1 را برمی‌گرداند.

گزینه‌ها:

گزینه علامت‌گذاری‌شده با [+] می‌تواند چندین بار مشخص شود

merge

ادغام بازبینی دیگر در دایرکتوری کاری:

hg merge [-P] [[-r] REV]

دایرکتوری کاری فعلی با تمام تغییرات ایجادشده در بازبینی درخواست‌شده از زمان آخرین بازبینی والد مشترک به‌روزرسانی می‌شود.

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

--tool می‌تواند برای مشخص کردن ابزار ادغام استفاده‌شده جهت ادغام فایل‌ها به کار رود. این گزینه متغیر محیطی HGMERGE و فایل‌های پیکربندی شما را لغو (نادیده) می‌کند. برای گزینه‌ها به hg help merge-tools مراجعه کنید.

اگر هیچ بازبینی‌ای مشخص نشود، والد دایرکتوری کاری یک بازبینی head باشد و شاخه فعلی دقیقاً شامل یک head دیگر باشد، به طور پیش‌فرض با آن head دیگر ادغام می‌شود. در غیر این صورت، باید بازبینی مشخصی برای ادغام ارائه شود.

برای اطلاعات درباره مدیریت تداخل‌های فایل به hg help resolve مراجعه کنید.

برای لغو یک ادغام ثبت‌نشده، از hg merge --abort استفاده کنید که نسخه تمیزی از والد ادغام اصلی را واکشی کرده (check out) و تمام تغییرات را از بین می‌برد.

در صورت موفقیت 0 و در صورت وجود فایل‌های حل‌نشده 1 را بازمی‌گرداند.

گزینه‌ها:

bookmarks

ایجاد یک نشانک (bookmark) جدید یا فهرست کردن نشانک‌های موجود:

hg bookmarks [OPTIONS]... [NAME]...

نشانک‌ها (Bookmarks) برچسب‌هایی روی مجموعه‌های تغییرات (changesets) هستند که به ردیابی خطوط توسعه کمک می‌کنند. نشانک‌ها نسخه‌بندی نمی‌شوند (unversioned) و می‌توان آن‌ها را جابه‌جا کرد، نامشان را تغییر داد و حذف کرد. حذف یا جابه‌جا کردن یک نشانک هیچ اثری بر مجموعه‌های تغییرات مرتبط با آن ندارد.

ایجاد یک نشانک یا به‌روزرسانی (update) به آن موجب می‌شود که به عنوان 'فعال' ('active') علامت‌گذاری شود. نشانک فعال با یک '*' مشخص می‌شود. هنگامی که یک کامیت (commit) ایجاد می‌شود، نشانک فعال به کامیت جدید پیشروی می‌کند. اجرای سادهٔ hg update نیز در صورت امکان، نشانک فعال را به جلو خواهد برد. به‌روزرسانی به جایی غیر از موقعیت نشانک، موجب غیرفعال شدن آن می‌شود.

نشانک‌ها را می‌توان بین مخازن push و pull کرد (ببینید: hg help push و hg help pull)‌. اگر یک نشانک به اشتراک گذاشته‌شده واگرا شود، یک 'نشانک واگرا' (divergent bookmark) جدید به شکل 'name@path' ایجاد خواهد شد. استفاده از hg merge این واگرایی را برطرف خواهد کرد.

مشخص کردن نشانک به عنوان '.' در گزینه‌های -m/-d/-l، معادل مشخص کردن نام نشانک فعال است.

نشانکی با نام '@' این ویژگی خاص را دارد که در صورت وجود، hg clone به‌طور پیش‌فرض آن را checkout می‌کند.

قالب (Template):

کلیدواژه‌های زیر علاوه بر کلیدواژه‌ها و توابع رایج قالب مانند {bookmark} پشتیبانی می‌شوند. همچنین ببینید: hg help templates.

مثال‌ها:

گزینه‌ها:

hg branch [-fC] [NAME]

بدون آرگومان، نام شاخهٔ فعلی را نمایش می‌دهد. با یک آرگومان، نام شاخهٔ دایرکتوری کاری را تنظیم می‌کند (شاخه تا زمان ثبت (commit) بعدی در مخزن وجود نخواهد داشت). رویهٔ استاندارد توصیه می‌کند که توسعهٔ اصلی روی شاخهٔ 'default' انجام شود.

مگر اینکه -f/--force مشخص شده باشد، دستور branch اجازه نخواهد داد نام شاخه‌ای را تعیین کنید که از قبل وجود دارد.

برای بازنشانی شاخهٔ دایرکتوری کاری به شاخهٔ والدِ دایرکتوری کاری و لغو تغییر شاخهٔ قبلی، از -C/--clean استفاده کنید.

از دستور hg update برای جابه‌جایی به یک شاخهٔ موجود استفاده کنید. از hg commit --close-branch برای بسته‌شده علامت‌گذاری کردن سرشاخهٔ (head) این شاخه استفاده کنید. هنگامی که تمام سرشاخه‌های یک شاخه بسته شوند، شاخه بسته‌شده در نظر گرفته می‌شود.

در صورت موفقیت 0 را برمی‌گرداند.

گزینه‌ها:

گزینه‌های دارای علامت [+] را می‌توان چندین بار مشخص کرد

branches

فهرست کردن شاخه‌های نام‌دار مخزن:

hg branches [-c]

فهرست کردن شاخه‌های نام‌دار مخزن با مشخص کردن شاخه‌های غیرفعال. اگر -c/--closed مشخص شده باشد، شاخه‌هایی که بسته‌شده علامت‌گذاری شده‌اند را نیز فهرست می‌کند (ببینید: hg commit --close-branch).

از دستور hg update برای جابه‌جایی به یک شاخهٔ موجود استفاده کنید.

قالب:

کلیدواژه‌های زیر علاوه بر کلیدواژه‌ها و توابع متداول قالب نظیر {branch} پشتیبانی می‌شوند. همچنین hg help templates را ببینید.

مقدار 0 را برمی‌گرداند.

گزینه‌ها:

گزینه‌های دارای علامت [+] را می‌توان چندین بار مشخص کرد.SS phase

تنظیم یا نمایش نام فاز جاری:

hg phase [-p|-d|-s] [-f] [-r] [REV...]

بدون آرگومان، نام فاز بازبینی(های) جاری را نمایش می‌دهد.

با استفاده از یکی از گزینه‌های -p/--public، -d/--draft یا -s/--secret، مقدار فاز بازبینی‌های مشخص‌شده تغییر می‌کند.

مگر اینکه -f/--force مشخص شده باشد، hg phase مجموعه‌تغییرها را از یک فاز پایین‌تر به فازی بالاتر منتقل نخواهد کرد. ترتیب فازها به شرح زیر است:

public < draft < secret

در صورت موفقیت 0، و اگر برخی از فازها قابل تغییر نباشند 1 برمی‌گرداند.

(برای اطلاعات بیشتر درباره مفهوم فازها، hg help phases را ببینید.)

گزینه‌ها:

گزینه‌های علامت‌گذاری‌شده با [+] را می‌توان چندین بار مشخص کرد

tag

افزودن یک یا چند برچسب برای بازبینی جاری یا داده‌شده:

hg tag [-f] [-l] [-m TEXT] [-d DATE] [-u USER] [-r REV] NAME...

نام‌گذاری یک بازبینی خاص با استفاده از <name>.

برچسب‌ها برای نام‌گذاری بازبینی‌های خاصی از مخزن به کار می‌روند و برای مقایسهٔ بازبینی‌های مختلف، بازگشت به نسخه‌های مهم پیشین یا علامت‌گذاری نقاط شاخه به‌عنوان انتشارها و غیره بسیار کاربردی هستند. تغییر یک برچسب موجود معمولاً مجاز نیست؛ برای نادیده‌گرفتن این محدودیت از -f/--force استفاده کنید.

اگر هیچ بازبینی‌ای مشخص نشود، والد دایرکتوری کاری استفاده خواهد شد.

به منظور تسهیل کنترل نسخه، توزیع، و ادغام برچسب‌ها، آنها در فایلی با نام ".hgtags" ذخیره می‌شوند که مشابه دیگر فایل‌های پروژه مدیریت شده و در صورت نیاز می‌توان آن را به‌صورت دستی ویرایش کرد. این امر همچنین بدان معناست که برچسب‌گذاری یک کامیت جدید ایجاد می‌کند. فایل ".hg/localtags" برای برچسب‌های محلی (که میان مخازن به اشتراک گذاشته نمی‌شوند) استفاده می‌شود.

کامیت‌های برچسب معمولاً در رأس یک شاخه انجام می‌شوند. اگر والد دایرکتوری کاری رأس شاخه نباشد، hg tag متوقف می‌شود؛ برای اجبار کامیت برچسب به قرارگیری بر پایهٔ یک مجموعه‌تغییر غیر رأس، از -f/--force استفاده کنید.

برای دیدن فهرستی از قالب‌های معتبر برای -d/--date، hg help dates را ببینید.

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

در صورت موفقیت 0 برمی‌گرداند.

گزینه‌ها:

مدیریت محتوای فایل (File content management)

annotate

نمایش اطلاعات changeset خط به خط برای هر فایل:

hg annotate [-r REV] [-f] [-a] [-u] [-d] [-n] [-c] [-l] FILE...

فهرست کردن تغییرات در فایل‌ها، به همراه نمایش شناسه بازبینی (revision id) مربوط به هر خط.

این دستور برای پی بردن به اینکه چه زمانی و توسط چه کسی تغییری ایجاد شده است مفید است.

اگر از --file، --user، یا --date استفاده کنید، شماره بازبینی نمایش داده نمی‌شود مگر اینکه --number را نیز مشخص کرده باشید.

بدون گزینه -a/--text، دستور annotate از پردازش فایل‌هایی که به عنوان دودویی (باینری) تشخیص می‌دهد خودداری خواهد کرد. با گزینه -a، دستور annotate فایل را در هر صورت حاشیه‌نویسی می‌کند، اگرچه نتایج آن احتمالاً نه مفید خواهند بود و نه مطلوب.

از گزینه‌های -L/--line-range FILE,M:N برای محدود کردن خروجی به خطوط M تا N در FILE استفاده کنید. این گزینه با --no-follow ناسازگار است و نمی‌تواند با آرگومان‌های الگوی فایل ترکیب شود. هنگام ترکیب با --rev، محدوده‌های خط به وضعیت فایل در بازبینی درخواست‌شده اشاره دارند.

قالب:

علاوه بر کلیدواژه‌ها و توابع متداول قالب، کلیدواژه‌های زیر نیز پشتیبانی می‌شوند. همچنین hg help templates را ببینید.

و هر مدخل از {lines} علاوه بر {date}، {node}، {rev}، {user} و غیره، زیرکلیدواژه‌های زیر را فراهم می‌کند:

برای ساختار نحو گسترش فهرست، hg help templates.operators را ببینید.

در صورت موفقیت 0 را برمی‌گرداند.

گزینه‌ها:

cat

خروجی دادن بازبینی فعلی یا مشخص‌شدهٔ فایل‌ها:

hg cat [OPTION]... FILE...

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

خروجی می‌تواند درون یک فایل قرار گیرد، که در این حالت نام فایل با استفاده از یک رشتهٔ الگو مشخص می‌شود. دستور hg help templates را ببینید. علاوه بر کلیدواژه‌های معمول الگو، قواعد قالب‌بندی زیر نیز پشتیبانی می‌شوند:

الگو:

علاوه بر کلیدواژه‌ها و توابع معمول الگو، کلیدواژه‌های زیر نیز پشتیبانی می‌شوند. همچنین hg help templates را ببینید.

در صورت موفقیت 0 را برمی‌گرداند.

گزینه‌ها:

گزینه‌های علامت‌گذاری‌شده با [+] را می‌توان چندین بار مشخص کرد.SS copy

نشانه‌گذاری فایل‌ها به عنوان رونوشت‌شده برای commit بعدی:

hg copy [OPTION]... (SOURCE... DEST | --forget DEST...)

dest را به عنوان دارای رونوشت‌های فایل‌های منبع نشانه‌گذاری می‌کند. اگر dest یک دایرکتوری باشد، رونوشت‌ها در آن دایرکتوری قرار می‌گیرند. اگر dest یک فایل باشد، منبع باید فقط یک فایل منفرد باشد.

به طور پیش‌فرض، این دستور محتوای فایل‌ها را به همان صورتی که در دایرکتوری کاری وجود دارند کپی می‌کند. اگر با -A/--after فراخوانی شود، عملیات ثبت می‌شود، اما هیچ کپی‌کردنی انجام نمی‌گیرد.

برای لغو نشانه‌گذاری یک فایل مقصد به عنوان رونوشت‌شده، از --forget استفاده کنید. با این گزینه، نشانه‌گذاری تمام آرگومان‌های (موقعیتی) داده‌شده به عنوان رونوشت برداشته می‌شود. فایل(های) مقصد در جای خود باقی خواهند ماند (همچنان ردگیری می‌شوند). توجه داشته باشید که hg copy --forget رفتاری مشابه با hg rename --forget دارد.

این دستور به طور پیش‌فرض با commit بعدی اعمال می‌شود.

در صورت موفقیت 0 و در صورت بروز خطا 1 را برمی‌گرداند.

گزینه‌ها:

گزینه‌ای که با علامت [+] مشخص شده را می‌توان چندین بار تعیین کرد

diff

مقایسه (diff) مخزن (یا فایل‌های انتخاب‌شده):

hg diff [OPTION]... ([-c REV] | [--from REV1] [--to REV2]) [FILE]...

نمایش تفاوت‌های میان بازبینی‌ها برای فایل‌های مشخص‌شده.

تفاوت‌های میان فایل‌ها با استفاده از قالب unified diff نمایش داده می‌شوند.

نکته

دستور hg diff ممکن است برای ادغام‌ها (merges) نتایج غیرمنتظره‌ای تولید کند، چرا که در صورت مشخص نشدن بازبینی‌ها، به طور پیش‌فرض با changeset والد اول دایرکتوری کاری مقایسه می‌کند. برای مقایسه با نواحی تداخل، می‌توانید از --config diff.merge=yes استفاده کنید.

به طور پیش‌فرض، فایل‌های دایرکتوری کاری با والد اول آن مقایسه می‌شوند. برای مشاهده تفاوت‌ها نسبت به یک بازبینی دیگر، از --from استفاده کنید. برای مشاهده تفاوت تا یک بازبینی دیگر، از --to استفاده کنید. برای نمونه، hg diff --from .^ تفاوت‌ها از والدِ والد (grandparent) رونوشت کاری تا رونوشت کاری را نشان می‌دهد، hg diff --to . تفاوت از رونوشت کاری تا والد آن را نشان می‌دهد (یعنی معکوس حالت پیش‌فرض)، و hg diff --from 1.0 --to 1.2 تفاوت بین این دو بازبینی را نشان خواهد داد.

همچنین می‌توانید -c/--change را به همراه یک بازبینی مشخص کنید تا تغییرات موجود در آن changeset را نسبت به والد اولش مشاهده نمایید (یعنی hg diff -c 42 معادل hg diff --from 42^ --to 42 است).

بدون گزینه -a/--text، دستور diff از تولید تفاوت برای فایل‌هایی که باینری تشخیص می‌دهد خودداری می‌کند. با گزینه -a، دستور diff در هر صورت تفاوت را تولید خواهد کرد که احتمالاً با نتایج نامطلوبی همراه است.

برای تولید تفاوت‌ها در قالب توسعه‌یافته git diff، از گزینه -g/--git استفاده کنید. برای اطلاعات بیشتر، hg help diffs را بخوانید.

مثال‌ها:

در صورت موفقیت 0 را برمی‌گرداند.

گزینه‌ها:

گزینهٔ علامت‌گذاری‌شده با [+] را می‌توان چندین بار مشخص کرد

grep

جستجوی یک الگو در فایل‌های مشخص‌شده:

hg grep [--diff] [OPTION]... PATTERN [FILE]...

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

به‌طور پیش‌فرض، grep فایل‌های مخزن را در دایرکتوری کاری جستجو کرده و فایل‌هایی را که در آن‌ها تطابق پیدا کند چاپ می‌کند. برای مشخص کردن نسخه‌های پیشین به جای دایرکتوری کاری، از پرچم --rev استفاده کنید.

برای جستجو در تفاوت‌های نسخه‌های پیشین که شامل تغییری در وضعیت تطابق هستند (“-” برای تطابقی که به عدم تطابق تبدیل می‌شود، یا “+” برای عدم تطابقی که به تطابق تبدیل می‌شود)، از پرچم --diff استفاده کنید.

مقدار PATTERN می‌تواند هر عبارت باقاعدهٔ Python (تقریباً سازگار با Perl) باشد.

اگر هیچ FILE مشخص نشود و پرچم --rev نیز ارائه نشده باشد، تمام فایل‌های دایرکتوری کاری جستجو می‌شوند. هنگام استفاده از پرچم --rev و مشخص کردن FILEها، از آرگومان --follow برای دنبال کردن فایل‌های مشخص‌شده در طول تغییر نام‌ها و کپی‌ها استفاده کنید.

الگو:

علاوه‌بر کلمات کلیدی و توابع رایج الگو، کلمات کلیدی زیر نیز پشتیبانی می‌شوند. همچنین ببینید: hg help templates.

و هر مدخل از {texts} زیرکلیدواژه‌های زیر را فراهم می‌کند.

برای نحو بسط فهرست به hg help templates.operators مراجعه کنید.

در صورت یافتن تطابق، مقدار 0 و در غیر این صورت مقدار 1 را برمی‌گرداند.

گزینه‌ها:

گزینهٔ علامت‌گذاری‌شده با [+] می‌تواند چندین بار مشخص شود

پیمایش تغییرات

bisect

جستجوی دودویی در مجموعه‌تغییرها:

hg bisect [-gbsr] [-U] [-c CMD] [REV]

این دستور به یافتن مجموعه‌تغییرهایی که باعث بروز مشکل شده‌اند کمک می‌کند. برای استفاده، نخستین مجموعه‌تغییری را که می‌دانید دارای مشکل است به‌عنوان بد (bad) علامت‌گذاری کنید، سپس جدیدترین مجموعه‌تغییری را که عاری از مشکل است به‌عنوان خوب (good) مشخص نمایید. دستور bisect دایرکتوری کاری شما را برای آزمایش به یک بازبینی به‌روزرسانی می‌کند (مگر اینکه گزینهٔ -U/--noupdate مشخص شده باشد). پس از انجام آزمایش‌ها، دایرکتوری کاری را به‌عنوان خوب یا بد علامت‌گذاری کنید؛ سپس bisect یا به یک مجموعه‌تغییر کاندید دیگر به‌روزرسانی می‌شود یا اعلام می‌کند که بازبینی بد را یافته است.

به‌عنوان یک میان‌بُر، می‌توانید از آرگومان بازبینی (revision) نیز برای علامت‌گذاری یک بازبینی به‌عنوان خوب یا بد بدون نیاز به checkout اولیهٔ آن استفاده کنید.

اگر دستوری را مشخص کنید، برای bisection خودکار استفاده خواهد شد. متغیر محیطی HG_NODE شامل شناسهٔ مجموعه‌تغییری خواهد بود که آزمایش می‌شود. وضعیت خروج دستور برای علامت‌گذاری بازبینی‌ها به‌عنوان خوب یا بد استفاده خواهد شد: وضعیت 0 به معنای خوب، 125 به معنای نادیده گرفتن بازبینی، 127 (فرمان یافت نشد) موجب لغو bisection می‌شود، و هر وضعیت خروج غیرصفر دیگر به معنای بد بودن بازبینی است.

چند مثال:

برای اطلاعات بیشتر دربارهٔ گزارهٔ bisect() به hg help revisions.bisect مراجعه کنید.

در صورت موفقیت 0 را برمی‌گرداند.

گزینه‌ها:

heads

نمایش سرشاخه‌ها (branch heads):

hg heads [-ct] [-r STARTREV] [REV]...

بدون هیچ آرگومانی، تمام سرشاخه‌های باز موجود در مخزن را نمایش می‌دهد. سرشاخه‌ها دسته‌تغییرهایی (changesets) هستند که هیچ نواده‌ای روی همان شاخه ندارند. آن‌ها جایی هستند که توسعه معمولاً در آن اتفاق می‌افتد و اهداف معمول برای عملیات به‌روزرسانی (update) و ادغام (merge) هستند.

اگر یک یا چند REV مشخص شوند، تنها سرشاخه‌های باز روی شاخه‌های مرتبط با دسته‌تغییرهای مشخص‌شده نشان داده می‌شوند. این بدان معناست که می‌توانید از hg heads . برای دیدن سرشاخه‌ها در شاخهٔ فعلیِ دریافت‌شده (checked-out) استفاده کنید.

اگر -c/--closed مشخص شده باشد، سرشاخه‌های علامت‌گذاری‌شده به عنوان بسته‌شده را نیز نمایش می‌دهد (ببینید hg commit --close-branch).

اگر STARTREV مشخص شده باشد، تنها سرشاخه‌هایی نمایش داده خواهند شد که از نوادگان STARTREV باشند.

اگر -t/--topo مشخص شده باشد، سازوکار شاخه‌های نام‌گذاری‌شده نادیده گرفته شده و تنها سرشاخه‌های توپولوژیکی (دسته‌تغییرهای بدون فرزند) نمایش داده خواهند شد.

در صورت یافتن سرشاخه‌های منطبق، 0 و در غیر این صورت 1 را بازمی‌گرداند.

گزینه‌ها:

identify

شناسایی دایرکتوری کاری یا بازنگری (revision) مشخص‌شده:

hg identify [-nibtB] [-r REV] [SOURCE]

خلاصه‌ای از وضعیت مخزن در REV را با استفاده از یک یا دو شناسهٔ هش والد چاپ می‌کند؛ در صورتی که دایرکتوری کاری تغییرات ثبت‌نشده داشته باشد یک «+»، سپس نام شاخه (اگر پیش‌فرض نباشد)، فهرستی از برچسب‌ها و فهرستی از چوب‌الف‌ها (bookmarks) به دنبال آن می‌آید.

هنگامی که REV داده نشود، خلاصه‌ای از وضعیت کنونی مخزن شامل دایرکتوری کاری را چاپ می‌کند. برای دریافت اطلاعات والدِ دایرکتوری کاری بدون بررسی تغییرات ثبت‌نشده، ‎-r.‎ را مشخص کنید.

مشخص کردن یک مسیر به ریشهٔ مخزن یا یک بستهٔ (bundle) مرکوریال باعث می‌شود عملیات جستجو روی آن مخزن/بسته انجام شود.

قالب:

علاوه بر کلیدواژه‌ها و توابع عمومی قالب، کلیدواژه‌های زیر نیز پشتیبانی می‌شوند. همچنین ببینید hg help templates.

مثال‌ها:

برای تولید اطلاعات بیشتر دربارهٔ بازنگری‌های خاص، از جمله شناسه‌های هش کامل، به hg log مراجعه کنید.

در صورت موفقیت 0 را بازمی‌گرداند.

گزینه‌ها:

log

نمایش تاریخچه بازنگری‌های کل مخزن یا فایل‌ها:

hg log [OPTION]... [FILE]

چاپ تاریخچه بازنگری‌های فایل‌های مشخص‌شده یا کل پروژه.

اگر هیچ بازه‌ای از بازنگری‌ها مشخص نشود، پیش‌فرض tip:0 خواهد بود مگر اینکه --follow تنظیم شده باشد.

تاریخچه فایل بدون دنبال کردن تاریخچه تغییر نام یا رونوشت فایل‌ها نمایش داده می‌شود. از -f/--follow همراه با نام فایل برای دنبال کردن تاریخچه در میان تغییر نام‌ها و رونوشت‌ها استفاده کنید. گزینه --follow بدون نام فایل، تنها نیاکان بازنگری‌های شروع را نشان می‌دهد. بازنگری‌های شروع را می‌توان با -r/--rev مشخص کرد که مقدار پیش‌فرض آن والد دایرکتوری کاری است.

به‌طور پیش‌فرض این دستور شماره بازنگری و شناسه changeset، برچسب‌ها، والدین غیربدیهی، کاربر، تاریخ و زمان، و خلاصه‌ای برای هر کامیت را چاپ می‌کند. هنگامی که سوییچ -v/--verbose استفاده شود، فهرست فایل‌های تغییریافته و پیام کامل کامیت نمایش داده می‌شوند.

با --graph بازنگری‌ها به‌صورت یک گراف جهت‌دار بدون دور (DAG) در قالب هنر اسکی با جدیدترین changeset در بالا نمایش داده می‌شوند. ‏'o' یک changeset است، '@' والد دایرکتوری کاری است، '%' یک changeset درگیر در تعارض ادغام حل‌نشده است، '_' شاخه را می‌بندد، 'x' منسوخ‌شده است، '*' ناپایدار است، و '+' نمایانگر یک انشعاب است که در آن changeset خطوط پایین‌تر، والد ادغام 'o' در همان خط است. مسیرها در DAG با '|'، '/' و غیره نمایش داده می‌شوند. قرار گرفتن ':' به‌جای '|' نشان می‌دهد که یک یا چند بازنگری در یک مسیر نادیده گرفته شده‌اند.

از گزینه‌های -L/--line-range FILE,M:N برای دنبال کردن تاریخچه خطوط از M تا N در FILE استفاده کنید. با -p/--patch تنها تکه‌تغییرهای تفاوت (diff hunks) اثرگذار بر بازه خطوط مشخص‌شده نمایش داده خواهند شد. این گزینه نیازمند --follow است؛ و می‌تواند چندین بار مشخص شود. در حال حاضر، این گزینه با --graph سازگار نیست. این گزینه آزمایشی است.

نکته

دستور hg log --patch ممکن است برای مجموعه‌تغییرهای ادغام، خروجی تفاوت (diff) غیرمنتظره‌ای تولید کند، زیرا تنها changeset ادغام را با والد اول آن مقایسه خواهد کرد. همچنین، تنها فایل‌هایی که با هر دو والد متفاوت باشند در files: ظاهر خواهند شد.

نکته

به دلایل کارایی، hg log FILE ممکن است تغییرات تکراری ایجادشده در شاخه‌ها را نادیده بگیرد و موارد حذف‌شده یا تغییرات حالت فایل را نشان ندهد. برای مشاهده تمام این دست تغییرات، از سوییچ --removed استفاده کنید.

نکته

تاریخچه حاصل از گزینه‌های -L/--line-range به گزینه‌های diff بستگی دارد؛ برای نمونه اگر فاصله‌های خالی نادیده گرفته شوند، تغییرات مربوطه‌ای که فقط شامل فاصله‌های خالی در بازه خطوط مشخص‌شده هستند فهرست نخواهند شد.

چند مثال:

برای فهرستی از قالب‌های معتبر برای -d/--date، دستور hg help dates را ببینید.

برای اطلاعات بیشتر درباره تعیین و ترتیب‌بندی بازبینی‌ها، دستور hg help revisions را ببینید.

برای اطلاعات بیشتر درباره سبک‌های از پیش بسته‌بندی‌شده و تعیین قالب‌های سفارشی، دستور hg help templates را ببینید. قالب پیش‌فرضی که توسط دستور log استفاده می‌شود را می‌توان از طریق تنظیم پیکربندی command-templates.log سفارشی‌سازی کرد.

در صورت موفقیت 0 را برمی‌گرداند.

گزینه‌ها:

گزینه‌های مشخص‌شده با [+] می‌توانند چندین بار تعیین شوند

hg parents [-r REV] [FILE]

hg log -r "p1()+p2()" or
hg log -r "p1(REV)+p2(REV)" or
hg log -r "max(::p1() and file(FILE))+max(::p2() and file(FILE))" or
hg log -r "max(::p1(REV) and file(FILE))+max(::p2(REV) and file(FILE))"

tip

نمایش بازبینی tip (منسوخ‌شده):

hg tip [-p] [-g]

بازبینی tip (که معمولاً صرفاً tip نامیده می‌شود) جدیدترین دسته‌تغییر (changeset) افزوده‌شده به مخزن (و بنابراین جدیدترین head تغییریافته) است.

اگر به‌تازگی یک commit انجام داده باشید، آن commit همان tip خواهد بود. اگر به‌تازگی تغییراتی را از یک مخزن دیگر pull کرده باشید، tip آن مخزن به tip فعلی تبدیل می‌شود. برچسب "tip" خاص است و نمی‌توان نام آن را تغییر داد یا آن را به دسته‌تغییر دیگری اختصاص داد.

این دستور منسوخ شده است؛ لطفاً به جای آن از hg heads استفاده کنید.

در صورت موفقیت 0 را برمی‌گرداند.

گزینه‌ها:

add

افزودن فایل‌های مشخص‌شده در کامیت بعدی:

hg add [OPTION]... [FILE]...

زمان‌بندی فایل‌ها برای قرار گرفتن تحت کنترل نسخه و افزوده شدن به مخزن.

فایل‌ها در کامیت بعدی به مخزن افزوده خواهند شد. برای لغو یک افزودن پیش از آن، hg forget را ببینید.

اگر هیچ نامی مشخص نشود، تمام فایل‌ها به مخزن افزوده می‌شوند (به‌جز فایل‌های منطبق با .hgignore).

مثال‌ها:

در صورت افزوده شدن موفقیت‌آمیز تمام فایل‌ها، مقدار 0 را برمی‌گرداند.

گزینه‌ها:

گزینهٔ علامت‌گذاری‌شده با [+] می‌تواند چندین بار مشخص شود.SS addremove

افزودن تمام فایل‌های جدید، حذف تمام فایل‌های مفقود:

hg addremove [OPTION]... [FILE]...

تمام فایل‌های جدید را افزوده و تمام فایل‌های مفقود را از مخزن حذف می‌کند.

مگر در حالتی که نام‌ها مشخص شده باشند، فایل‌های جدید در صورتی که با هر یک از الگوهای موجود در .hgignore تطابق داشته باشند نادیده گرفته می‌شوند. همانند add، این تغییرات در کامیت بعدی اعمال می‌شوند.

از گزینهٔ -s/--similarity برای شناسایی فایل‌های تغییر نام‌یافته استفاده کنید. این گزینه درصدی بین 0 (غیرفعال) و 100 (فایل‌ها باید یکسان باشند) را به عنوان پارامتر خود دریافت می‌کند. با پارامتری بزرگ‌تر از 0، این گزینه هر فایل حذف‌شده را با هر فایل اضافه‌شده مقایسه می‌کند و مواردی را که به اندازه کافی مشابه باشند به عنوان تغییر نام ثبت می‌کند. شناسایی فایل‌های تغییر نام‌یافته از این طریق می‌تواند هزینه‌بر و سنگین باشد. پس از استفاده از این گزینه، می‌توان از hg status -C برای بررسی اینکه کدام فایل‌ها به عنوان جابه‌جا‌شده یا تغییر نام‌یافته شناسایی شده‌اند استفاده کرد. در صورت مشخص نشدن، مقدار پیش‌فرض -s/--similarity برابر 100 است و تنها تغییر نام فایل‌های کاملاً یکسان شناسایی می‌شود.

مثال‌ها:

در صورت افزوده شدن موفقیت‌آمیز تمام فایل‌ها، 0 برمی‌گرداند.

گزینه‌ها:

گزینه‌های علامت‌گذاری‌شده با [+] را می‌توان چندین بار مشخص کرد.SS files

فهرست کردن فایل‌های ردیابی‌شده:

hg files [OPTION]... [FILE]...

چاپ فایل‌های تحت کنترل Mercurial در دایرکتوری کاری یا در بازبینی (revision) مشخص‌شده برای فایل‌های داده‌شده (به‌استثنای فایل‌های حذف‌شده). فایل‌ها را می‌توان به‌صورت نام فایل یا مجموعه‌فایل (fileset) مشخص کرد.

اگر فایلی برای تطابق داده نشود، این دستور نام تمام فایل‌های تحت کنترل Mercurial را چاپ می‌کند.

قالب (Template):

علاوه بر کلیدواژه‌ها و توابع عمومی قالب، کلیدواژه‌های زیر نیز پشتیبانی می‌شوند. همچنین hg help templates را ببینید.

مثال‌ها:

برای اطلاعات بیشتر در مورد تعیین الگوهای فایل، hg help patterns و hg help filesets را ببینید.

در صورت یافتن تطابق، مقدار 0 و در غیر این صورت مقدار 1 را برمی‌گرداند.

گزینه‌ها:

گزینه‌های دارای علامت [+] را می‌توان چندین بار تعیین کرد.SS forget

فراموش کردن فایل‌های مشخص‌شده در کامیت بعدی:

hg forget [OPTION]... FILE...

فایل‌های مشخص‌شده را علامت‌گذاری می‌کند تا پس از کامیت بعدی دیگر ردگیری نشوند.

این کار فایل‌ها را فقط از شاخهٔ جاری حذف می‌کند، نه از کل تاریخچهٔ پروژه، و آن‌ها را از دایرکتوری کاری حذف نمی‌کند.

برای حذف فایل از دایرکتوری کاری، hg remove را ببینید.

برای لغو فراموشی پیش از کامیت بعدی، hg add را ببینید.

مثال‌ها:

در صورت موفقیت، ۰ را برمی‌گرداند.

گزینه‌ها:

گزینه‌های علامت‌گذاری‌شده با [+] می‌توانند چندین بار مشخص شوند

locate

یافتن فایل‌های منطبق با الگوهای مشخص (منسوخ‌شده):

hg locate [OPTION]... [PATTERN]...

چاپ فایل‌های تحت کنترل Mercurial در دایرکتوری کاری که نام آن‌ها با الگوهای داده‌شده مطابقت دارد.

به‌طور پیش‌فرض، این دستور تمام دایرکتوری‌های موجود در دایرکتوری کاری را جستجو می‌کند. برای جستجوی تنها دایرکتوری جاری و زیردایرکتوری‌های آن، از "--include ." استفاده کنید.

اگر هیچ الگویی برای مطابقت داده نشود، این دستور نام تمام فایل‌های تحت کنترل Mercurial در دایرکتوری کاری را چاپ می‌کند.

اگر می‌خواهید خروجی این دستور را به دستور "xargs" بفرستید، از گزینهٔ -0 هم در این دستور و هم در "xargs" استفاده کنید. این کار از بروز مشکل تلقی شدن نام‌فایل‌های منفرد حاوی فاصله به عنوان چندین نام‌فایل توسط "xargs" جلوگیری می‌کند.

برای دستوری با کاربردهای متنوع‌تر، hg help files را ببینید.

در صورت یافتن تطابق، ۰ و در غیر این صورت، ۱ را برمی‌گرداند.

گزینه‌ها:

گزینه‌های علامت‌گذاری‌شده با [+] می‌توانند چندین بار مشخص شوند.SS purge

فایل‌هایی را که توسط Mercurial ردیابی نمی‌شوند حذف می‌کند:

hg purge [OPTION]... [DIR]...

فایل‌های ناشناخته برای Mercurial را حذف می‌کند. این دستور برای آزمایش تغییرات محلی و ثبت‌نشده در یک درخت منبع در غیر این صورت پاکیزه، مفید است.

این بدان معناست که purge به‌طور پیش‌فرض موارد زیر را حذف خواهد کرد:

اما موارد زیر را دست‌نخورده باقی می‌گذارد:

می‌توان از گزینه‌های --files و --dirs برای هدایت purge به حذف فقط فایل‌ها، فقط دایرکتوری‌ها، یا هر دو استفاده کرد. اگر هیچ‌کدام از این گزینه‌ها داده نشوند، هر دو حذف خواهند شد.

اگر دایرکتوری‌ها در خط فرمان داده شوند، فقط فایل‌های درون این دایرکتوری‌ها در نظر گرفته می‌شوند.

هنگام استفاده از purge مراقب باشید، زیرا ممکن است به‌طور بازگشت‌ناپذیری فایل‌هایی را که فراموش کرده‌اید به مخزن اضافه کنید، حذف نمایید. اگر فقط می‌خواهید فهرست فایل‌هایی را که این برنامه حذف می‌کند چاپ کنید، از گزینهٔ --print استفاده نمایید.

گزینه‌ها:

گزینهٔ علامت‌گذاری‌شده با [+] را می‌توان چندین بار مشخص کرد

hg remove [OPTION]... FILE...

در صورت موفقیت 0، و در صورت مواجهه با هرگونه هشدار 1 برمی‌گرداند.

گزینه‌ها:

گزینه با علامت [+] را می‌توان چندین بار مشخص کرد

hg rename [OPTION]... SOURCE... DEST

resolve

ادغام مجدد یا تنظیم/مشاهدهٔ وضعیت ادغام فایل‌ها:

hg resolve [OPTION]... [FILE]...

ادغام‌های دارای تداخل حل‌نشده اغلب نتیجهٔ ادغام غیرتعاملی با استفاده از تنظیمات پیکربندی internal:merge یا یک ابزار ادغام خط فرمانی مانند diff3 هستند. دستور resolve برای مدیریت فایل‌های درگیر در یک ادغام، پس از اجرای hg merge و پیش از اجرای hg commit استفاده می‌شود (یعنی دایرکتوری کاری باید دو والد داشته باشد). برای اطلاعات دربارهٔ پیکربندی ابزارهای ادغام به hg help merge-tools مراجعه کنید.

دستور resolve می‌تواند به روش‌های زیر استفاده شود:

نکته

Mercurial به شما اجازه نخواهد داد فایل‌های دارای تداخل ادغام حل‌نشده را commit کنید. باید پیش از آنکه پس از یک ادغام دارای تداخل commit کنید، از hg resolve -m ... استفاده نمایید.

قالب:

کلیدواژه‌های زیر علاوه بر کلیدواژه‌ها و توابع عمومی قالب پشتیبانی می‌شوند. همچنین ببینید hg help templates.

در صورت موفقیت 0، و در صورتی که تلاش برای حل هر فایلی ناموفق باشد 1 برمی‌گرداند.

گزینه‌ها:

revert

بازگرداندن فایل‌ها به وضعیت استخراج‌شده (checkout):

hg revert [OPTION]... [-r REV] [NAME]...

نکته

برای استخراج (checkout) بازبینی‌های پیشین، باید از hg update REV استفاده کنید. برای لغو یک ادغام اعمال‌نشده (و از دست رفتن تغییراتتان)، از hg merge --abort استفاده کنید.

در صورت مشخص نشدن بازبینی، فایل‌ها یا دایرکتوری‌های مشخص‌شده را به محتوایی که در والد دایرکتوری کاری داشتند بازمی‌گرداند. این کار محتوای فایل‌ها را به یک وضعیت تغییرنیافته بازمی‌گرداند و افزودن‌ها، حذف‌ها، رونوشت‌ها و تغییر نام‌های زمان‌بندی‌شده را لغو می‌کند. اگر دایرکتوری کاری دارای دو والد باشد، باید صراحتاً یک بازبینی را مشخص کنید.

با استفاده از گزینه‌های -r/--rev یا -d/--date، فایل‌ها یا دایرکتوری‌های داده‌شده را به وضعیتشان در یک بازبینی مشخص بازگردانید. از آنجا که revert والدین دایرکتوری کاری را تغییر نمی‌دهد، این امر باعث می‌شود این فایل‌ها تغییریافته به نظر برسند. این می‌تواند برای «خنثی‌سازی» (back out) بخشی یا تمام یک تغییر پیشین مفید باشد. برای یک روش مرتبط، hg backout را ببینید.

فایل‌های تغییریافته پیش از بازگردانی با پسوند .orig ذخیره می‌شوند. برای غیرفعال کردن این نسخه‌های پشتیبان، از --no-backup استفاده کنید. امکان ذخیرهٔ فایل‌های پشتیبان در یک دایرکتوری سفارشی نسبت به ریشهٔ مخزن با تنظیم گزینهٔ پیکربندی ui.origbackuppath وجود دارد.

برای فهرستی از قالب‌های معتبر برای -d/--date، به hg help dates مراجعه کنید.

برای روشی جهت معکوس کردن اثر یک changeset پیشین، به hg help backout مراجعه کنید.

در صورت موفقیت 0 را برمی‌گرداند.

گزینه‌ها:

گزینه‌های دارای علامت [+] را می‌توان چندین بار مشخص کرد.SS root

چاپ ریشه (بالاترین سطح) دایرکتوری کاری فعلی:

hg root

چاپ دایرکتوری ریشهٔ مخزن فعلی.

قالب:

کلیدواژه‌های زیر علاوه بر کلیدواژه‌ها و توابع عمومی قالب پشتیبانی می‌شوند. همچنین hg help templates را ببینید.

در صورت موفقیت ۰ را برمی‌گرداند.

گزینه‌ها:

shelve

ذخیره و کنار گذاشتن تغییرات دایرکتوری کاری:

hg shelve [OPTION]... [FILE]...

عملیات بایگانی موقت (shelve) فایل‌هایی را که «hg status» به عنوان غیرتمیز (not clean) گزارش می‌کند دریافت کرده، تغییرات را در یک بسته (یک تغییر بایگانی‌شده) ذخیره می‌کند و فایل‌ها را بازگردانی (revert) می‌نماید تا وضعیت آن‌ها در دایرکتوری کاری پاک شود.

برای بازگرداندن این تغییرات به دایرکتوری کاری، از «hg unshelve» استفاده کنید؛ این دستور حتی در صورت انتقال به کامیتی دیگر نیز کار خواهد کرد.

هنگامی که هیچ فایلی مشخص نشده باشد، «hg shelve» تمام فایل‌های غیرتمیز را ذخیره می‌کند. اگر فایل‌ها یا دایرکتوری‌های خاصی نام برده شوند، تنها تغییرات مربوط به همان فایل‌ها بایگانی موقت می‌شوند.

در بایگانی موقت ساده (زمانی که فایلی مشخص نشده باشد، بدون حالت تعاملی و گزینه‌های include و exclude)، اطلاعات مربوط به قرار داشتن دایرکتوری کاری روی شاخهٔ تازه ایجادشده حفظ می‌شود؛ به عبارت دیگر، زمانی که دایرکتوری کاری روی شاخه‌ای متفاوت از اولین والد خود قرار دارد. در این شرایط، unshelve اطلاعات شاخه را به دایرکتوری کاری بازمی‌گرداند.

هر تغییر بایگانی‌شده دارای نامی است که یافتن بعدی آن را آسان‌تر می‌کند. نام پیش‌فرض تغییر بایگانی‌شده بر پایهٔ نشانک (bookmark) فعال، یا در صورت نبود نشانک فعال، بر اساس شاخهٔ نام‌دار فعلی تعیین می‌شود. برای تعیین نامی دیگر، از --name استفاده کنید.

برای دیدن فهرستی از تغییرات بایگانی‌شدهٔ موجود، از گزینهٔ --list استفاده کنید. برای هر تغییر بایگانی‌شده، نام، قدمت و شرح آن چاپ خواهد شد؛ برای جزئیات بیشتر از --patch یا --stat استفاده کنید.

برای حذف تغییرات بایگانی‌شدهٔ مشخص، از --delete استفاده کنید. برای حذف تمام تغییرات بایگانی‌شده، از --cleanup استفاده کنید.

گزینه‌ها:

گزینهٔ علامت‌گذاری‌شده با [+] می‌تواند چندین بار مشخص شود.SS status

نمایش فایل‌های تغییریافته در دایرکتوری کاری:

hg status [OPTION]... [FILE]...

نمایش وضعیت فایل‌ها در مخزن. اگر نام‌هایی مشخص شوند، فقط فایل‌های منطبق نمایش داده می‌شوند. فایل‌هایی که بدون تغییر (clean) یا نادیده‌گرفته‌شده (ignored) هستند یا مبدأ یک عملیات رونوشت/انتقال (copy/move) می‌باشند، فهرست نمی‌شوند مگر آنکه -c/--clean، -i/--ignored، -C/--copies یا -A/--all مشخص شده باشند. مگر در صورتی که گزینه‌های توصیف‌شده با «فقط نمایش ...» مشخص شده باشند، گزینه‌های -mardu استفاده می‌شوند.

گزینهٔ -q/--quiet فایل‌های ردگیری‌نشده (ناشناخته و نادیده‌گرفته‌شده) را پنهان می‌کند، مگر اینکه صراحتاً با -u/--unknown یا -i/--ignored درخواست شده باشند.

نکته

hg status ممکن است در صورتی که دسترسی‌ها تغییر کرده باشند یا یک ادغام (merge) رخ داده باشد، با diff ناهمخوان به نظر برسد. قالب استاندارد diff تغییرات دسترسی را گزارش نمی‌کند و diff تنها تغییرات را نسبت به یکی از والدین ادغام گزارش می‌دهد.

اگر یک بازبینی (revision) مشخص شود، به عنوان بازبینی پایه استفاده می‌شود. اگر دو بازبینی مشخص شوند، تفاوت‌های میان آن‌ها نمایش داده می‌شود. گزینهٔ --change نیز می‌تواند به عنوان میان‌بری برای فهرست کردن فایل‌های تغییریافتهٔ یک بازبینی نسبت به نخستین والد آن استفاده شود.

کدهای مورد استفاده برای نمایش وضعیت فایل‌ها عبارتند از:

M = modified (تغییریافته)
A = added (اضافه‌شده)
R = removed (حذف‌شده)
C = clean (بدون تغییر)
! = missing (مفقود - حذف‌شده با دستوری غیر از hg، اما همچنان ردگیری‌شده)
? = not tracked (ردگیری‌نشده)
I = ignored (نادیده‌گرفته‌شده)
  = مبدأ فایل قبلی (همراه با --copies)

گزینهٔ -t/--terse در صورتی که تمام فایل‌های درون یک دایرکتوری وضعیت یکسانی داشته باشند، با نمایش تنها نام دایرکتوری خروجی را خلاصه می‌کند. این گزینه آرگومانی می‌پذیرد که وضعیت‌های مورد نظر برای خلاصه‌سازی را مشخص می‌کند: 'm' برای 'modified' (تغییریافته)، 'a' برای 'added' (اضافه‌شده)، 'r' برای 'removed' (حذف‌شده)، 'd' برای 'deleted' (مفقود)، 'u' برای 'unknown' (ناشناخته)، 'i' برای 'ignored' (نادیده‌گرفته‌شده) و 'c' برای clean (بدون تغییر).

این گزینه تنها وضعیت‌هایی را که مشخص شده‌اند خلاصه می‌کند. توجه داشته باشید که فایل‌های بدون تغییر و نادیده‌گرفته‌شده با '--terse ic' نمایش داده نمی‌شوند مگر آنکه گزینه‌های -c/--clean و -i/--ignored نیز استفاده شده باشند.

گزینهٔ -v/--verbose هنگامی که مخزن در وضعیت ادغام ناتمام، shelve، rebase و غیره باشد، اطلاعات لازم را نمایش می‌دهد. می‌توانید این رفتار را با فعال کردن گزینهٔ commands.status.verbose به صورت پیش‌فرض فعال کنید.

می‌توانید با تنظیم commands.status.skipstates روی یک یا چند مورد از این موارد، از نمایش برخی از این وضعیت‌ها صرف‌نظر کنید: 'bisect'، 'graft'، 'histedit'، 'merge'، 'rebase' یا 'unshelve'.

قالب:

کلیدواژه‌های زیر علاوه بر کلیدواژه‌ها و توابع مشترک قالب پشتیبانی می‌شوند. همچنین ببینید hg help templates.

مثال‌ها:

در صورت موفقیت 0 بازمی‌گرداند.

گزینه‌ها:

گزینه‌های دارای علامت [+] را می‌توان چندین بار مشخص کرد

summary

خلاصه‌سازی وضعیت دایرکتوری کاری:

hg summary [--remote]

این دستور خلاصه‌ای کوتاه از وضعیت دایرکتوری کاری، شامل والدین، شاخه، وضعیت کامیت، فاز و به‌روزرسانی‌های موجود را تولید می‌کند.

با گزینهٔ --remote، این دستور مسیرهای پیش‌فرض را برای تغییرات ورودی و خروجی بررسی می‌کند. این عمل ممکن است زمان‌بر باشد.

در صورت موفقیت 0 را برمی‌گرداند.

گزینه‌ها:

unshelve

بازگردانی یک تغییر بایگانی‌شده (shelved) به دایرکتوری کاری:

hg unshelve [OPTION]... [[-n] SHELVED]

این دستور یک نام اختیاری از تغییر بایگانی‌شده را برای بازگردانی می‌پذیرد. اگر نامی داده نشود، تازه‌ترین تغییر بایگانی‌شده استفاده می‌شود.

اگر یک تغییر بایگانی‌شده با موفقیت اعمال شود، بسته‌ای (bundle) که حاوی تغییرات بایگانی‌شده است به یک مکان پشتیبان (.hg/shelve-backup) منتقل می‌شود.

از آنجا که می‌توانید یک تغییر بایگانی‌شده را روی هر کامیت دلخواهی بازگردانی کنید، ممکن است عملیات unshelve منجر به تداخل (conflict) بین تغییرات شما و کامیت‌هایی شود که روی آن‌ها unshelve می‌کنید. در صورت وقوع این امر، باید تداخل را حل کرده، سپس از --continue برای تکمیل عملیات unshelve استفاده کنید. (بسته تا زمانی که عملیات unshelve را با موفقیت تکمیل نکنید منتقل نخواهد شد.)

(به عنوان جایگزین، می‌توانید از --abort برای لغو عملیات unshelve که منجر به تداخل شده است استفاده کنید. این کار تغییرات بازگردانی‌شده را برمی‌گرداند و بسته را در جای خود باقی می‌گذارد.)

اگر تغییر بایگانی‌شدهٔ خام (بدون گزینه‌های تعاملی، include و exclude) روی شاخه‌ای تازه ایجاد شده انجام گرفته باشد، اطلاعات شاخه را به دایرکتوری کاری بازمی‌گرداند.

پس از یک unshelve موفق، تغییرات بایگانی‌شده در یک دایرکتوری پشتیبان ذخیره می‌شوند. تنها N نسخهٔ پشتیبان اخیر نگهداری می‌شوند. مقدار پیش‌فرض N برابر ۱۰ است اما می‌توان آن را با استفاده از گزینهٔ پیکربندی shelve.maxbackups بازنویسی کرد.

برچسب زمانی بر حسب ثانیه برای تعیین ترتیب نسخه‌های پشتیبان استفاده می‌شود. جهت ایمنی، اگر برچسب زمانی یکسان مانع از تعیین ترتیب دقیق آن‌ها شود، بیش از maxbackups نسخهٔ پشتیبان نگهداری می‌شود.

تغییرات انتخاب‌شده را می‌توان با پرچم --interactive بازگردانی کرد. دایرکتوری کاری با تغییرات انتخاب‌شده به‌روزرسانی می‌شود و تنها تغییرات انتخاب‌نشده به صورت بایگانی‌شده باقی می‌مانند. نکته: کل بایگانی ابتدا قبل از اجرای تعاملی روی دایرکتوری کاری اعمال می‌شود. بنابراین، صرف نظر از اینکه کدام تغییرات unshelve خواهند شد، تمام تداخلات بین دایرکتوری کاری و بایگانی پدیدار خواهند شد.

گزینه‌ها:

archive

ایجاد یک بایگانی فاقد نسخه‌بندی از یک بازبینی مخزن:

hg archive [OPTION]... DEST

به‌طور پیش‌فرض، بازبینی استفاده‌شده والد دایرکتوری کاری است؛ برای تعیین یک بازبینی متفاوت از -r/--rev استفاده کنید.

نوع بایگانی به‌طور خودکار بر اساس پسوند فایل تشخیص داده می‌شود (برای تعیین دستی، از -t/--type استفاده کنید).

مثال‌ها:

انواع معتبر عبارتند از:

نام دقیق بایگانی یا دایرکتوری مقصد با استفاده از یک رشته قالب مشخص می‌شود؛ برای جزئیات به hg help export مراجعه کنید.

به ابتدای نام هر عضوی که به فایل بایگانی افزوده می‌شود، یک پیشوند دایرکتوری اضافه می‌گردد. برای مشخص کردن یک رشته قالب برای پیشوند، از -p/--prefix استفاده کنید. پیش‌فرض، نام پایه (basename) بایگانی با حذف پسوندها است.

در صورت موفقیت، 0 برمی‌گرداند.

گزینه‌ها:

گزینه علامت‌گذاری‌شده با [+] می‌تواند چندین بار مشخص شود.SS bundle

ایجاد یک فایل بسته (bundle):

hg bundle [-f] [-t BUNDLESPEC] [-a] [-r REV]... [--base REV]... FILE [DEST]...

تولید یک فایل بسته (bundle) حاوی داده‌هایی که قرار است به مخزن دیگری منتقل شوند.

برای ایجاد بسته‌ای شامل تمام مجموعه‌تغییرها (changesets)، از -a/--all (یا --base null) استفاده کنید. در غیر این صورت، hg فرض می‌کند که مقصد تمام گره‌های مشخص‌شده با پارامترهای --base را دارد. در غیر این حالت، hg فرض خواهد کرد که مخزن حاوی تمام گره‌های موجود در مقصد است، یا default-push/default اگر مقصدی مشخص نشده باشد، که در آن مقصد همان مخازنی است که از طریق آرگومان DEST مشخص می‌کنید.

می‌توانید قالب بسته را با گزینهٔ -t/--type تغییر دهید. برای مستندات مربوط به این قالب، hg help bundlespec را ببینید. به‌طور پیش‌فرض، مناسب‌ترین قالب استفاده می‌شود و فشرده‌سازی نیز به‌طور پیش‌فرض بر روی bzip2 تنظیم شده است.

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

اعمال بسته‌ها تمام محتویات مجموعه‌تغییر از جمله مجوزها، اطلاعات رونوشت/تغییر نام و تاریخچهٔ بازبینی‌ها را حفظ می‌کند.

در صورت موفقیت 0، و اگر تغییری یافت نشود 1 را برمی‌گرداند.

گزینه‌ها:

گزینه‌های دارای علامت [+] را می‌توان چندین بار مشخص کرد.SS export

تخلیه سرآیند و diffها برای یک یا چند changeset:

hg export [OPTION]... [-o OUTFILESPEC] [-r] [REV]...

چاپ سرآیند changeset و diffها برای یک یا چند بازنگری (revision). اگر هیچ بازنگری‌ای مشخص نشود، والد دایرکتوری کاری استفاده می‌شود.

اطلاعات نشان‌داده‌شده در سرآیند changeset عبارتند از: نویسنده، تاریخ، نام شاخه (در صورت غیرپیش‌فرض بودن)، هش changeset، والد(ها) و توضیحات ثبت (commit).

نکته

hg export ممکن است برای changesetهای ادغام (merge) خروجی diff غیرمنتظره‌ای تولید کند، زیرا changeset ادغام را تنها با نخستین والد آن مقایسه خواهد کرد.

خروجی می‌تواند درون یک فایل نوشته شود، که در این حالت نام فایل با استفاده از یک رشته الگو (template) مشخص می‌شود. hg help templates را ببینید. علاوه بر کلیدواژه‌های رایج الگو، قواعد قالب‌بندی زیر نیز پشتیبانی می‌شوند:

بدون گزینه -a/--text، دستور export از تولید diff برای فایل‌هایی که باینری تشخیص دهد خودداری می‌کند. با -a، دستور export در هر صورت یک diff تولید خواهد کرد، احتمالاً با نتایجی نامطلوب.

با -B/--bookmark، changesetهای قابل دسترس توسط نشانک (bookmark) داده‌شده انتخاب می‌شوند.

از گزینه -g/--git برای تولید diffها در قالب diff گسترش‌یافته git استفاده کنید. برای اطلاعات بیشتر hg help diffs را ببینید.

با گزینه --switch-parent، مقایسه (diff) در برابر والد دوم انجام خواهد شد. این گزینه می‌تواند برای بازبینی یک ادغام مفید باشد.

الگو (Template):

کلیدواژه‌های زیر علاوه بر کلیدواژه‌ها و توابع رایج الگو پشتیبانی می‌شوند. همچنین hg help templates را ببینید.

مثال‌ها:

در صورت موفقیت 0 را برمی‌گرداند.

گزینه‌ها:

گزینه علامت‌گذاری‌شده با [+] می‌تواند چندین بار مشخص شود.SS import

وارد کردن مجموعه‌ای مرتب از وصله‌ها:

hg import [OPTION]... PATCH...

فهرستی از وصله‌ها را وارد کرده و آن‌ها را به‌صورت تک‌تک کامیت می‌کند (مگر اینکه --no-commit مشخص شده باشد).

برای خواندن یک وصله از ورودی استاندارد (stdin)، از «-» به‌عنوان نام وصله استفاده کنید. اگر یک URL مشخص شده باشد، وصله از آنجا بارگیری خواهد شد.

دستور import ابتدا تغییرات را روی دایرکتوری کاری اعمال می‌کند (مگر اینکه --bypass مشخص شده باشد)؛ اگر تغییرات معلق و اعمال‌نشده‌ای وجود داشته باشد، عملیات import متوقف خواهد شد.

از --bypass برای اعمال و ثبت (commit) مستقیم وصله‌ها در مخزن، بدون دستکاری دایرکتوری کاری استفاده کنید. بدون --exact، وصله‌ها بر روی بازبینی والد دایرکتوری کاری اعمال خواهند شد.

شما می‌توانید یک وصله را مستقیماً از یک پیام ایمیل وارد کنید. حتی وصله‌های پیوست‌شده نیز کار می‌کنند (برای استفاده از بخش بدنه، نوع آن باید text/plain یا text/x-patch باشد). هدرهای From و Subject در پیام ایمیل به‌عنوان ثبت‌کننده و پیام کامیت پیش‌فرض استفاده می‌شوند. تمامی بخش‌های متن ساده (text/plain) در بدنه، قبل از اولین diff، به پیام کامیت اضافه می‌شوند.

اگر وصله واردشده توسط hg export ایجاد شده باشد، کاربر و توضیحات موجود در وصله بر مقادیر هدرها و بدنه پیام اولویت دارند. مقادیری که در خط فرمان با -m/--message و -u/--user مشخص می‌شوند، این مقادیر را بازنویسی می‌کنند.

اگر --exact مشخص شده باشد، import قبل از اعمال هر وصله، دایرکتوری کاری را روی والد آن وصله تنظیم می‌کند و در صورتی که changeset حاصل شناسه‌ای متفاوت از شناسه ثبت‌شده در وصله داشته باشد، عملیات متوقف می‌شود. این کار در برابر حالت‌های گوناگونی که قالب‌های قابل‌حمل وصله و سامانه‌های ایمیل ممکن است در انتقال داده‌ها یا متاداده‌های Mercurial با خطا مواجه شوند محافظت می‌کند. برای انتقال بدون اتلاف داده، به hg bundle مراجعه کنید.

از --partial استفاده کنید تا مطمئن شوید که حتی در صورت عدم اعمال برخی قطعات (hunks)، یک changeset از وصله ایجاد می‌شود. قطعاتی که اعمال آن‌ها با شکست مواجه شود در یک فایل <target-file>.rej نوشته می‌شوند. سپس می‌توان تعارض‌ها را پیش از اجرای hg commit --amend جهت به‌روزرسانی changeset ایجادشده، به‌صورت دستی حل کرد. این پرچم برای این تعبیه شده تا کاربران بتوانند وصله‌هایی را که به‌صورت جزئی اعمال می‌شوند بدون از دست دادن متاداده‌های مرتبط (نویسنده، تاریخ، توضیحات و...) وارد کنند.

نکته

هنگامی که هیچ قطعه‌ای به‌صورت تمیز اعمال نشود، hg import --partial یک changeset خالی ایجاد کرده و فقط متاداده‌های وصله را وارد می‌کند.

با استفاده از -s/--similarity، دستور hg تلاش خواهد کرد تغییر نام‌ها و رونوشت‌ها را در وصله درست همانند hg addremove شناسایی کند.

استفاده از برنامه‌های خارجی patch برای اعمال وصله با تنظیم گزینه پیکربندی ui.patch امکان‌پذیر است. برای ابزار داخلی پیش‌فرض، میزان تقریب (fuzz) را می‌توان از طریق patch.fuzz پیکربندی کرد. برای اطلاعات بیشتر درباره فایل‌های پیکربندی و نحوه استفاده از این گزینه‌ها، به hg help config مراجعه کنید.

برای فهرستی از قالب‌های معتبر برای -d/--date، به hg help dates مراجعه کنید.

مثال‌ها:

در صورت موفقیت 0، و در صورت موفقیت جزئی 1 را بازمی‌گرداند (به --partial مراجعه کنید).

گزینه‌ها:

unbundle

اعمال یک یا چند فایل بسته (bundle):

hg unbundle [-u] FILE...

اعمال یک یا چند فایل بسته تولیدشده توسط hg bundle.

در صورت موفقیت 0، و اگر یک به‌روزرسانی فایل‌های حل‌نشده داشته باشد 1 را برمی‌گرداند.

گزینه‌ها:

نگهداری مخزن (Repository maintenance)

admin::narrow-client

ابزارهای مدیریت کلاینت مرتبط با narrow. (آزمایشی):

hg admin::narrow-client

این دستور آزمایشی است و در معرض تغییر قرار دارد.

گزینه‌ها:

admin::narrow-server

ابزارهای مدیریت سرور مرتبط با narrow. (آزمایشی):

hg admin::narrow-server

این دستور آزمایشی است و در معرض تغییر قرار دارد.

گزینه‌ها:

manifest

نمایش مانیفست پروژه در بازبینی (revision) جاری یا مشخص‌شده:

hg manifest [-r REV]

چاپ فهرستی از فایل‌های تحت کنترل نسخه برای بازبینی مشخص‌شده. اگر بازبینی مشخص نشود، اولین والد دایرکتوری کاری استفاده می‌شود، یا در صورتی که هیچ بازبینی واکشی (check out) نشده باشد، از بازبینی تهی (null) استفاده خواهد شد.

با گزینه -v، مجوزهای فایل، پیوندهای نمادین (symlinks) و بیت‌های اجرایی چاپ می‌شوند. با گزینه --debug، هَش‌های بازبینی فایل چاپ می‌شوند.

اگر گزینه --all مشخص شود، فهرست تمام فایل‌ها از تمام بازبینی‌ها چاپ خواهد شد. این شامل فایل‌های حذف‌شده و تغییرنام‌یافته نیز می‌شود.

در صورت موفقیت، مقدار ۰ را برمی‌گرداند.

گزینه‌ها:

recover

بازگردانی یک تراکنش قطع‌شده (ناتمام):

hg recover

بازیابی از یک commit یا pull ناتمام و قطع‌شده.

این دستور تلاش می‌کند وضعیت مخزن را پس از یک عملیات ناتمام اصلاح کند. تنها زمانی باید از آن استفاده کرد که Mercurial آن را پیشنهاد دهد.

در صورت موفقیت ۰، و در صورتی که چیزی برای بازیابی نباشد یا verify شکست بخورد، ۱ را برمی‌گرداند.

گزینه‌ها:

verify

بررسی صحت و یکپارچگی مخزن:

hg verify

بررسی صحت و یکپارچگی مخزن جاری.

این دستور یک بررسی جامع از یکپارچگی مخزن انجام می‌دهد و درهم‌سازها (hashes) و چکسام‌های هر مدخل در changelog، manifest و فایل‌های ردیابی‌شده، و همچنین یکپارچگی ارجاعات متقابل (crosslinks) و شاخص‌های آن‌ها را اعتبارسنجی می‌کند.

لطفاً برای اطلاعات بیشتر دربارهٔ بازیابی از خرابی مخزن، https://mercurial-scm.org/wiki/RepositoryCorruption را ببینید.

برای یک رابط کاربری جایگزین با کنترل بسیار بیشتر روی فرایند اعتبارسنجی و گزارش خطای بهتر، hg help admin::verify را امتحان کنید.

در صورت موفقیت 0، و در صورت مواجهه با خطا 1 برمی‌گرداند.

گزینه‌ها:

config

نمایش تنظیمات پیکربندی ادغام‌شده از تمام فایل‌های hgrc:

hg config [-u] [NAME]...

بدون هیچ آرگومانی، نام‌ها و مقادیر تمام موارد پیکربندی چاپ می‌شود.

با یک آرگومان به شکل section.name، تنها مقدار آن مورد پیکربندی چاپ می‌شود.

با چندین آرگومان، نام‌ها و مقادیر تمام موارد پیکربندی که با نام‌های بخش یا section.name مطابقت دارند، چاپ می‌شود.

با --edit، یک ویرایشگر روی فایل پیکربندی در سطح کاربر باز می‌شود. با --global، فایل پیکربندی سراسری سیستم ویرایش می‌شود. با --local، فایل پیکربندی در سطح مخزن ویرایش می‌شود.

با --source، منبع (نام فایل و شماره خط) برای هر مورد پیکربندی چاپ می‌شود.

برای اطلاعات بیشتر درباره فایل‌های پیکربندی، hg help config را ببینید.

پرچم --non-shared برای ویرایش فایل پیکربندی .hg/hgrc-not-shared به کار می‌رود. این فایل در حالت share-safe میان اشتراک‌ها به اشتراک گذاشته نمی‌شود.

قالب (Template):

کلیدواژه‌های زیر پشتیبانی می‌شوند. همچنین hg help templates را ببینید.

پرچم --shared می‌تواند برای ویرایش فایل پیکربندی مخزن مبدأ اشتراکی استفاده شود. این پرچم تنها زمانی کار می‌کند که با استفاده از ویژگی آزمایشی share safe اشتراک‌گذاری انجام داده باشید.

در صورت موفقیت 0، و در صورتی که NAME وجود نداشته باشد 1 را برمی‌گرداند.

گزینه‌ها:

hg help [-eck] [-s PLATFORM] [TOPIC]

version

نمایش اطلاعات نگارش و حق‌نشر:

hg version

قالب:

کلیدواژه‌های زیر پشتیبانی می‌شوند. همچنین ببینید: hg help templates.

و هر مدخل از {extensions} افزون بر {ver} زیرکلیدواژه‌های زیر را فراهم می‌کند.

گزینه‌ها:

admin::chainsaw-update

دریافت و به‌روزرسانی به یک بازبینی مشخص، تحت هر شرایطی، (آزمایشی):

hg admin::chainsaw-update [OPTION] --rev REV --source SOURCE --dest DEST

زمینهٔ کاربرد: برخی سیستم‌های ادغام مداوم (CI)، ابزارهای بسته‌بندی یا استقرار.

نتیجهٔ نهایی مطلوب: مخزن محلی در REPO_PATH مشخص‌شده، دارای آخرین تغییرات تا بازبینی داده‌شده و با یک دایرکتوری کاری تمیز و به‌روزرسانی‌شده به بازبینی مورد نظر.

دستور chainsaw-update از یک مبدأ دریافت (pull) می‌کند، سپس دایرکتوری کاری را به بازبینی مشخص‌شده به‌روزرسانی می‌نماید و بر هر مانعی که بر سر راه باشد فائق می‌آید.

به‌طور پیش‌فرض، این دستور موارد زیر را انجام می‌دهد:

از این دستور برای هیچ کاری جز انجام یک سری به‌روزرسانی‌های خودکار (بدون نظارت)، با دسترسی انحصاری کامل به مخزن در هر بار و بدون هیچ کار محلی دیگر جز اجرای اسکریپت‌های ساخت (build)، استفاده نکنید. در صورتی که مخزن محلی یک اشتراک باشد (رجوع کنید به hg help share)، دسترسی نوشتن انحصاری به مبدأ اشتراک نیز الزامی است.

توصیه می‌شود این دستورها با متغیر محیطی HGPLAIN اجرا شوند (رجوع کنید به hg scripting).

انگیزه: در سیستم‌های ادغام و تحویل مداوم (CI/CD)، قفل‌های ساختگی یا باقی‌مانده از منابع رایج اتلاف وقت (هم زمان کاری و هم زمان تقویمی) هستند. اسکریپت‌های CI/CD تمایل دارند با اقدامات متقابل، که اغلب در شرایط اضطراری ایجاد می‌شوند، گسترش یافته و حجیم شوند. همچنین، با این‌که نگه‌داشتن مخازن از یک وظیفه (job) به وظیفهٔ بعدی ایده‌آل است (به‌ویژه برای مخازن بزرگ)، انجام یک کلون مجدد استثنایی بسیار بهتر از دست دادن مهلت انتشار است.

گزینه‌ها:

انواع موجود (Available Types)

رشته‌های <type> زیر برای باندل در دسترس هستند:

موتورهای فشرده‌سازی موجود (Available Compression Engines)

موتورهای <compression> زیر برای باندل قابل استفاده هستند:

می‌توان به ابتدای نام موتورهای فشرده‌سازی عبارت stream را افزود تا یک باندل جریانی (streaming bundle) ایجاد شود. این‌ها باندل‌هایی هستند که تولید و مصرف آن‌ها بسیار کارآمد است، اما سازگاری آن‌ها با کلاینت‌های قدیمی‌تر تضمین‌شده نیست..SS "گزینه‌های موجود (Available Options)"

گزینه‌های زیر وجود دارند:

مثال‌ها (EXAMPLES)

حالت (Mode)

‏Mercurial می‌تواند از سامانه‌های گوناگونی برای نمایش رنگ استفاده کند. حالت‌های پشتیبانی‌شده عبارتند از ansi، win32 و terminfo. برای جزئیات درباره نحوه کنترل حالت، hg help config.color را ببینید.

جلوه‌ها (Effects)

علاوه بر رنگ، جلوه‌های دیگری مانند متن پررنگ (bold) و زیرخط‌دار (underlined) نیز در دسترس هستند. به‌طور پیش‌فرض، پایگاه داده terminfo برای یافتن کدهای ترمینالِ مربوط به تغییر رنگ و جلوه استفاده می‌شود. اگر terminfo در دسترس نباشد، جلوه‌ها با تابع کنترلی ECMA-48 SGR (معروف به کدهای گریز ANSI) رندر می‌شوند.

جلوه‌های موجود در حالت terminfo عبارتند از 'blink'، 'bold'، 'dim'، 'inverse'، 'invisible'، 'italic'، 'standout' و 'underline'؛ در حالت ECMA-48، گزینه‌ها عبارتند از 'bold'، 'inverse'، 'italic' و 'underline'. نحوه رندر شدن هر جلوه به شبیه‌ساز ترمینال بستگی دارد. ممکن است برخی از آن‌ها برای یک نوع ترمینال خاص در دسترس نباشند و بدون هشدار نادیده گرفته شوند.

اگر مدخل terminfo برای ترمینال شما فاقد کدهای یک جلوه باشد یا کدهای نادرستی داشته باشد، می‌توانید آن کدها را در پیکربندی خود اضافه کرده یا بازنویسی کنید:

[color]
terminfo.dim = \E[2m

که در آن 'E' با یک نویسه گریز (escape) جایگزین می‌شود.

برچسب‌ها (Labels)

متن بسته به برچسب‌هایی که دارد جلوه‌های رنگی دریافت می‌کند. بسیاری از دستورهای پیش‌فرض Mercurial متن برچسب‌دار تولید می‌کنند. شما همچنین می‌توانید با استفاده از تابع label، برچسب‌های اختصاصی خود را در قالب‌ها تعریف کنید؛ hg help templates را ببینید. برای دریافت جلوه‌ها، برچسب‌ها باید دارای یک نقطه باشند، مانند log.secret یا branch.active. یک بخش منفرد از متن ممکن است بیش از یک برچسب داشته باشد. در این صورت، جلوه‌های داده‌شده به آخرین برچسب بر سایر جلوه‌ها ارجحیت خواهند داشت (آن‌ها را لغو می‌کنند). این شامل جلوه ویژه "none" نیز می‌شود که سایر جلوه‌ها را خنثی می‌کند.

برچسب‌ها معمولاً نامرئی هستند. برای دیدن این برچسب‌ها و موقعیت آن‌ها در متن، از گزینه سراسری --color=debug استفاده کنید. یک متن پایه ممکن است به چندین برچسب وابسته باشد، مانند:

موارد زیر جلوه‌های پیش‌فرض برای برخی برچسب‌های پیش‌فرض هستند. جلوه‌های پیش‌فرض را می‌توان از طریق فایل پیکربندی بازنویسی کرد:

[color]
status.modified = blue bold underline red_background
status.added = green bold
status.removed = red bold blue_background
status.deleted = cyan bold underline
status.unknown = magenta bold underline
status.ignored = black bold
# مقدار 'none' تمام جلوه‌ها را خاموش می‌کند
status.clean = none
status.copied = none
qseries.applied = blue bold underline
qseries.unapplied = black bold
qseries.missing = red bold
diff.diffline = bold
diff.extended = cyan bold
diff.file_a = red bold
diff.file_b = green bold
diff.hunk = magenta
diff.deleted = red
diff.inserted = green
diff.changed = white
diff.tab =
diff.trailingwhitespace = bold red_background
# خالی است تا سبک برچسب دربرگیرنده را به ارث ببرد
changeset.public =
changeset.draft =
changeset.secret =
resolve.unresolved = red bold
resolve.resolved = green bold
bookmarks.active = green
branches.active = none
branches.closed = black bold
branches.current = green
branches.inactive = none
tags.normal = green
tags.local = black bold
rebase.rebased = blue
rebase.remaining = red bold
shelve.age = cyan
shelve.newest = green bold
shelve.name = blue bold
histedit.remaining = red bold

از آن‌جا که تنها هشت رنگ استاندارد وجود دارد، Mercurial به شما اجازه می‌دهد در صورت استفاده از حالت terminfo، برای سایر جایگاه‌های رنگی (color slots) که ممکن است برای نوع ترمینال شما در دسترس باشند، نام‌های رنگی تعریف کنید. برای نمونه:
color.brightblue = 12
color.pink = 207
color.orange = 202

جهت تنظیم 'brightblue' روی جایگاه رنگی 12 (کاربردی برای ترمینال‌های 16 رنگی که رنگ‌های روشن‌تری در هشت جایگاه بالایی تعریف کرده‌اند)، و 'pink' و 'orange' برای رنگ‌های موجود در مکعب رنگ پیش‌فرض ترمینال 256 رنگ xterm. این رنگ‌های تعریف‌شده سپس می‌توانند همانند هر یک از هشت رنگ از پیش‌تعریف‌شده استفاده شوند، از جمله افزودن پسوند '_background' برای تنظیم پس‌زمینه به آن رنگ.

دستورها (Commands)

دستورهای زیر هنوز در دسترس هستند، اما استفاده از آن‌ها دیگر توصیه نمی‌شود:

locate

این دستور با hg files جایگزین شده است.

parents

این دستور می‌تواند با hg summary یا hg log به همراه revsetهای مناسب جایگزین شود. برای اطلاعات بیشتر hg help revsets را ببینید.

tip

جایگزین توصیه‌شده hg heads است.

گزینه‌ها (Options)

وضعیت کنونی قابلیت (Current feature status)

این قابلیت هنوز در حال توسعه است.

ناپایداری (Instability)

بازنویسی مجموعه‌تغییرات ممکن است باعث ایجاد ناپایداری شود.

دو نوع اصلی از ناپایداری وجود دارد: یتیم‌شدگی (orphaning) و واگرایی (diverging).

یتیم‌ها (orphans) مجموعه‌تغییراتی هستند که پس از بازنویسی نیاکانشان، جا مانده‌اند. واگرایی دو حالت دارد:

می‌توان با استفاده از پیکربندی زیر از ایجاد محلیِ مجموعه‌تغییرات یتیم جلوگیری کرد:

[experimental]
evolution.createmarkers = true
evolution.exchange = true

همچنین می‌توانید آن گزینه را صراحتاً فعال کنید:

[experimental]
evolution.createmarkers = true
evolution.exchange = true
evolution.allowunstable = true

گزاره‌ها (Predicates)

گزاره‌های زیر پشتیبانی می‌شوند:

نام پرچم‌ها (Flag names)

پرچم‌های مربوط به هر دستور در hg help برای آن دستور فهرست شده‌اند. علاوه بر این، برخی از پرچم‌ها مانند --repository سراسری هستند و می‌توانند با هر دستوری به کار روند - این پرچم‌ها در hg help -v دیده می‌شوند، و می‌توان آن‌ها را پیش یا پس از دستور مشخص کرد.

هر پرچم دست‌کم یک نام بلند دارد، مانند --repository. برخی پرچم‌ها ممکن است یک نام کوتاه یک‌حرفی نیز داشته باشند، مانند معادل آن -R. استفاده از نام کوتاه یا بلند یکسان بوده و اثر یکسانی دارد. نام بلند را می‌توان به هر پیشوند یکتایی خلاصه‌نویسی کرد. برای مثال، hg commit --amend را می‌توان به hg commit --am خلاصه کرد.

پرچم‌هایی که نام کوتاه دارند را می‌توان در یکدیگر ادغام نیز کرد - برای نمونه، برای مشخص کردن هر دو پرچم --edit (کوتاه -e) و --interactive (کوتاه -i)، می‌توان چنین نوشت:

hg commit -ei

اگر هر یک از پرچم‌های ادغام‌شده مقداری بپذیرد (یعنی بولی نباشد)، باید آخرین پرچم باشد و مقدار در ادامهٔ آن بیاید:

hg commit -im 'Message'

پرچم‌های خط فرمان Mercurial می‌توانند رشته، عدد، بولی یا فهرستی از رشته‌ها باشند.

تعیین مقادیر پرچم

با فرض وجود پرچم 'flagname' با نام کوتاه 'f'، نحوهای دستوری زیر مجاز هستند:

--flagname=foo
--flagname foo
-f foo
-ffoo

این نحو برای تمامی پرچم‌های غیربولی (رشته‌ها، اعداد یا فهرست‌ها) اعمال می‌شود.

تعیین پرچم‌های بولی

پرچم‌های بولی پارامتر مقدار نمی‌پذیرند. برای مشخص کردن یک پرچم بولی، از نام پرچم برای تنظیم آن روی true، یا از همان نام همراه با پیشوند 'no-' برای تنظیم آن روی false استفاده کنید:

hg commit --interactive
hg commit --no-interactive

تعیین پرچم‌های فهرستی

پرچم‌های فهرستی چندین مقدار می‌پذیرند. برای تعیین آن‌ها، پرچم را چندین بار وارد کنید:

hg files --include mercurial --include tests

تنظیم مقادیر پیش‌فرض پرچم

به‌منظور تنظیم یک مقدار پیش‌فرض برای یک پرچم در فایل hgrc، توصیه می‌شود از نام‌های مستعار (alias) استفاده کنید:

[alias]
commit = commit --interactive

برای اطلاعات بیشتر دربارهٔ فایل‌های hgrc، بخش hg help config را ببینید.

بازنویسی پرچم‌ها در خط فرمان

اگر یک پرچم غیرفهرستی یکسان چندین بار در خط فرمان مشخص شود، آخرین مقدار مشخص‌شده استفاده می‌شود:

hg commit -m "Ignored value" -m "Used value"

این مورد شامل استفاده از نام‌های مستعار نیز می‌شود - برای مثال، اگر داشته باشیم:

[alias]
committemp = commit -m "Ignored value"

آنگاه دستور زیر آن -m را بازنویسی خواهد کرد:

hg committemp -m "Used value"

هر پرچم دارای یک مقدار پیش‌فرض است، و همچنین می‌توانید همان‌طور که در بالا توضیح
داده شد، مقادیر پیش‌فرض خود را در hgrc تنظیم کنید.
به‌جز پرچم‌های فهرستی (list flags)، مقادیر پیش‌فرض را می‌توان در خط فرمان به‌سادگی
با مشخص کردن پرچم در همان محل بازنویسی کرد.

پرچم‌های پنهان

برخی از پرچم‌ها به‌طور پیش‌فرض در راهنمای دستور نمایش داده نمی‌شوند - به‌ویژه پرچم‌هایی که آزمایشی، منسوخ‌شده یا پیشرفته در نظر گرفته شده‌اند. برای نمایش همهٔ پرچم‌ها، پرچم --verbose را به دستور help اضافه کنید:

hg help --verbose commit

خلاصه (Synopsis)

سیستم Mercurial از فایلی به نام .hgignore در دایرکتوری ریشهٔ مخزن استفاده می‌کند تا رفتار خود را هنگام جستجوی فایل‌هایی که در حال حاضر ردگیری نمی‌شوند، کنترل کند.

توضیحات (Description)

دایرکتوری کاری یک مخزن Mercurial اغلب شامل فایل‌هایی است که نباید توسط Mercurial ردگیری شوند. این موارد شامل فایل‌های پشتیبان ایجادشده توسط ویرایشگرها و خروجی‌های ساخت ایجادشده توسط کامپایلرها هستند. می‌توان با فهرست کردن این فایل‌ها در یک فایل .hgignore در ریشهٔ دایرکتوری کاری، آن‌ها را نادیده گرفت. فایل .hgignore باید به‌صورت دستی ایجاد شود. این فایل معمولاً تحت کنترل نسخه قرار می‌گیرد تا این تنظیمات با push و pull به مخازن دیگر نیز منتقل شوند.

یک فایل ردگیری‌نشده در صورتی نادیده گرفته می‌شود که مسیر آن نسبت به دایرکتوری ریشهٔ مخزن، یا هر پیشوندی از آن مسیر، با هر الگویی در .hgignore مطابقت داشته باشد.

برای مثال، فرض کنید یک فایل ردگیری‌نشده به نام file.c در مسیر a/b/file.c درون مخزن خود داریم. Mercurial فایل file.c را نادیده می‌گیرد اگر هر الگویی در .hgignore با a/b/file.c، a/b یا a مطابقت داشته باشد.

علاوه بر این، یک فایل پیکربندی Mercurial می‌تواند به مجموعه‌ای از فایل‌های نادیده‌گیری مختص کاربر یا سراسری ارجاع دهد. برای جزئیات نحوهٔ پیکربندی این فایل‌ها، کلید پیکربندی ignore را در بخش [ui] در hg help config مشاهده کنید.

برای کنترل نحوهٔ مدیریت فایل‌هایی که Mercurial اداره می‌کند، بسیاری از دستورها از گزینه‌های -I و -X پشتیبانی می‌کنند؛ برای جزئیات به hg help <command> و hg help patterns مراجعه کنید.

فایل‌هایی که از قبل ردگیری می‌شوند، حتی در صورت حضور در .hgignore، تحت تأثیر آن قرار نمی‌گیرند. یک فایل ردگیری‌نشده مانند X را می‌توان صریحاً با دستور hg add X اضافه کرد، حتی اگر X توسط یک الگو در .hgignore مستثنی شده باشد.

نحو (Syntax)

یک فایل نادیده‌گیری، یک فایل متنی ساده متشکل از فهرستی از الگوها است که در هر سطر یک الگو قرار می‌گیرد. خطوط خالی نادیده گرفته می‌شوند. نویسهٔ # به عنوان نویسهٔ توضیح و نویسهٔ \ به عنوان نویسهٔ گریز (escape) در نظر گرفته می‌شود.

سیستم Mercurial از چندین نحو برای الگوها پشتیبانی می‌کند. نحو پیش‌فرض مورداستفاده، عبارت‌های منظم به سبک Python/Perl است.

برای تغییر نحو مورداستفاده، از سطری با قالب زیر استفاده کنید:

syntax: NAME

که در آن NAME یکی از موارد زیر است:

نحو انتخاب‌شده هنگام پردازش تمام الگوهای بعدی معتبر باقی می‌ماند، تا زمانی که نحو دیگری تعیین شود.

الگوهای glob و regexp هیچ‌کدام ریشه‌دار نیستند. یک الگوی دارای نحو glob به شکل *.c با فایلی که به .c ختم می‌شود در هر دایرکتوری مطابقت خواهد داشت، و یک الگوی regexp به شکل \.c$ نیز همین کار را انجام می‌دهد. برای ریشه‌دار کردن یک الگوی regexp، آن را با ^ شروع کنید. برای دستیابی به همین نتیجه با نحو glob، باید از rootglob استفاده کنید.

زیردایرکتوری‌ها می‌توانند با افزودن subinclude:path/to/subdir/.hgignore به .hgignore ریشه، تنظیمات .hgignore مختص به خود را داشته باشند. برای جزئیات بیشتر دربارهٔ subinclude: و include:، به hg help patterns مراجعه کنید.

نکته (Note)

الگوهایی که در جایی غیر از .hgignore مشخص شده‌اند، همیشه ریشه‌دار هستند. لطفاً برای جزئیات به hg help patterns مراجعه کنید.

در اینجا نمونه‌ای از یک فایل چشم‌پوشی (ignore) آمده است.

# use glob syntax.
syntax: glob
*.elc
*.pyc
*~
# switch to regexp syntax.
syntax: regexp
^\.pc/

اشکال‌زدایی (Debugging)

برای بررسی اینکه آیا و چرا یک فایل نادیده گرفته شده است، یا برای مشاهدهٔ الگوی ترکیبی چشم‌پوشی، از دستور debugignore استفاده کنید. برای جزئیات به hg help debugignore مراجعه کنید.

دستورها و نشانی‌های URL

دستورهای وب زیر و نشانی‌های URL آن‌ها در دسترس هستند:

/annotate/{revision}/{path}

اطلاعات مجموعه‌تغییر را برای هر خط از یک فایل نمایش می‌دهد.

آرگومان‌های رشتهٔ پرس‌وجوی ignorews، ignorewsamount، ignorewseol و ignoreblanklines معنایی مشابه با معادل‌هایشان در پیکربندی [annotate] دارند. این آرگومان‌ها از منطق ارزیابی بولی hgrc برای تفسیر مقدار استفاده می‌کنند؛ برای نمونه 0 و false نادرست و 1 و true درست هستند. اگر تعریف نشوند، از تنظیمات پیش‌فرض کارساز استفاده می‌شود.

الگوی fileannotate رندر می‌شود.

/archive/{revision}.{format}[/{path}]

دریافت یک بایگانی از محتوای مخزن.

محتوا و نوع بایگانی توسط پارامتر مسیر URL تعیین می‌شود. format پسوند فایل مربوط به نوع بایگانی تولیدی است؛ مانند zip یا tar.bz2. ممکن است همهٔ انواع بایگانی توسط پیکربندی کارساز شما مجاز نباشند.

پارامتر اختیاری URL با نام path محتوایی را که باید در بایگانی گنجانده شود کنترل می‌کند. در صورت حذف، هر فایلی در بازبینی مشخص‌شده در بایگانی حضور خواهد داشت. در صورت درج، تنها فایل مشخص‌شده یا محتویات دایرکتوری مشخص‌شده در بایگانی قرار خواهند گرفت.

هیچ الگویی برای این گرداننده استفاده نمی‌شود. محتوای خام و دودویی تولید می‌شود.

/bookmarks

اطلاعات مربوط به نشانک‌ها (bookmarks) را نمایش می‌دهد.

هیچ آرگومانی پذیرفته نمی‌شود.

الگوی bookmarks رندر می‌شود.

/branches

اطلاعات مربوط به شاخه‌ها را نمایش می‌دهد.

همهٔ شاخه‌های شناخته‌شده در خروجی گنجانده می‌شوند، حتی شاخه‌های بسته.

هیچ آرگومانی پذیرفته نمی‌شود.

الگوی branches رندر می‌شود.

/changelog[/{revision}]

اطلاعات مربوط به چندین مجموعه‌تغییر را نمایش می‌دهد.

اگر آرگومان اختیاری URL با نام revision وجود نداشته باشد، اطلاعات همهٔ مجموعه‌تغییرها با شروع از tip رندر خواهد شد. اگر آرگومان revision حضور داشته باشد، مجموعه‌تغییرها با شروع از بازبینی مشخص‌شده نمایش داده می‌شوند.

اگر revision غایب باشد، آرگومان رشتهٔ پرس‌وجوی rev می‌تواند تعریف شود. این کار جستجویی را برای مجموعه‌تغییرها انجام خواهد داد.

آرگومان rev می‌تواند یک بازبینی تکی، یک مجموعه بازبینی، یا یک کلیدواژهٔ لفظی برای جستجو در داده‌های مجموعه‌تغییر باشد (معادل hg log -k).

آرگومان رشتهٔ پرس‌وجوی revcount بیشینهٔ تعداد مجموعه‌تغییرها را برای رندر مشخص می‌کند.

برای مواردی به جز جستجو، الگوی changelog رندر خواهد شد..SS /changeset[/{revision}]

نمایش اطلاعات درباره یک مجموعه‌تغییر (changeset).

آرگومان مسیر URL، شناسه مجموعه‌تغییری است که باید نمایش داده شود. برای مشاهده مقادیر مجاز، hg help revisions را ببینید. در صورت عدم تعریف، مجموعه‌تغییر tip نمایش داده خواهد شد.

قالب changeset رندر می‌شود. محتویات قالب‌های changesettag، changesetbookmark، filenodelink، filenolink و قالب‌های متعدد مربوط به diff ممکن است همگی برای تولید خروجی به کار روند.

/comparison/{revision}/{path}

نمایش مقایسه بین نسخه‌های قدیم و جدید یک فایل بر اساس تغییرات اعمال‌شده در یک بازبینی (revision) خاص.

این بخش شبیه به گرداننده diff است؛ با این تفاوت که این ساختار به جای یک diff یکپارچه (unified diff)، یک diff ستونی یا کنار هم (side-by-side) ارائه می‌دهد.

آرگومان رشته پرس‌وجوی context می‌تواند برای کنترل خطوط بافت (context) در diff استفاده شود.

قالب filecomparison رندر می‌شود.

/diff/{revision}/{path}

نمایش نحوه تغییر یک فایل در یک کامیت مشخص.

قالب filediff رندر می‌شود.

این گرداننده تحت هر دو مسیر /diff و /filediff ثبت شده است. در کدهای مدرن از /diff استفاده می‌شود.

/file/{revision}[/{path}]

نمایش اطلاعات درباره یک دایرکتوری یا فایل در مخزن.

اطلاعات مربوط به path که به عنوان پارامتر URL مشخص شده است رندر خواهد شد.

اگر path یک دایرکتوری باشد، اطلاعات مربوط به ورودی‌های آن دایرکتوری رندر می‌شود. این حالت معادل گرداننده manifest است.

اگر path یک فایل باشد، اطلاعات آن فایل از طریق قالب filerevision نمایش داده خواهد شد.

اگر path تعریف نشود، اطلاعات دایرکتوری ریشه رندر خواهد شد.

/diff/{revision}/{path}

نمایش نحوه تغییر یک فایل در یک کامیت مشخص.

قالب filediff رندر می‌شود.

این گرداننده تحت هر دو مسیر /diff و /filediff ثبت شده است. در کدهای مدرن از /diff استفاده می‌شود.

/filelog/{revision}/{path}

نمایش اطلاعات درباره تاریخچه یک فایل در مخزن.

آرگومان رشته پرس‌وجوی revcount می‌تواند برای تعیین حداکثر تعداد ورودی‌ها جهت نمایش تعریف شود.

قالب filelog رندر خواهد شد.

/graph[/{revision}]

نمایش اطلاعات درباره توپولوژی گرافیکی مخزن.

اطلاعات ارائه‌شده توسط این گرداننده می‌تواند برای ساخت نمایش‌های بصری از توپولوژی مخزن استفاده شود.

پارامتر URL مربوط به revision مجموعه‌تغییر آغازین را کنترل می‌کند. در صورت عدم وجود، مقدار پیش‌فرض tip است.

آرگومان رشته پرس‌وجوی revcount می‌تواند تعداد مجموعه‌تغییرهایی که اطلاعات آن‌ها نمایش داده می‌شود را مشخص کند.

آرگومان رشته پرس‌وجوی graphtop می‌تواند مجموعه‌تغییر آغازین را جهت تولید متغیر jsdata (که برای رندر نمودار در JavaScript استفاده می‌شود) تعیین کند. به طور پیش‌فرض، مقداری برابر با revision دارد.

این گرداننده قالب graph را رندر خواهد کرد..SS /help[/{topic}]

رندر کردن مستندات راهنما.

این دستور وب تقریباً معادل hg help است. اگر یک topic تعریف شده باشد، آن مبحث راهنما رندر خواهد شد. در غیر این صورت، فهرستی از مباحث راهنمای موجود رندر می‌شود.

هنگام درخواست راهنما برای یک موضوع، قالب help رندر خواهد شد. برای فهرست موضوعات راهنما، قالب helptopics رندر می‌شود.

/log[/{revision}[/{path}]]

نمایش تاریخچهٔ مخزن یا فایل.

برای نشانی‌های وب به شکل /log/{revision}، فهرستی از مجموعه‌تغییرها (changesets) با شروع از شناسهٔ changeset مشخص‌شده نمایش داده می‌شود. اگر {revision} تعریف نشده باشد، مقدار پیش‌فرض tip است. این ساختار معادل گردانندهٔ changelog می‌باشد.

برای نشانی‌های وب به شکل /log/{revision}/{file}، تاریخچهٔ یک فایل بخصوص نمایش داده خواهد شد. این ساختار معادل گردانندهٔ filelog است.

/manifest[/{revision}[/{path}]]

نمایش اطلاعات دربارهٔ یک دایرکتوری.

اگر آرگومان‌های مسیر نشانی وب حذف شوند، اطلاعات مربوط به دایرکتوری ریشه برای مجموعه‌تغییر tip نشان داده خواهد شد.

از آنجا که این گرداننده تنها می‌تواند اطلاعات مربوط به دایرکتوری‌ها را نشان دهد، توصیه می‌شود به جای آن از گردانندهٔ file استفاده کنید، زیرا می‌تواند هم دایرکتوری‌ها و هم فایل‌ها را مدیریت کند.

قالب manifest برای این گرداننده رندر خواهد شد.

/changeset[/{revision}]

نمایش اطلاعات دربارهٔ یک changeset منفرد.

آرگومان مسیر نشانی وب، شناسهٔ changeset برای نمایش است. برای مقادیر ممکن، hg help revisions را ببینید. در صورت تعریف نشدن، changeset مربوط به tip نشان داده خواهد شد.

قالب changeset رندر می‌شود. محتویات changesettag، changesetbookmark، filenodelink، filenolink و قالب‌های متعدد مربوط به diffها همگی ممکن است برای تولید خروجی مورد استفاده قرار گیرند.

/shortlog

نمایش اطلاعات اولیه دربارهٔ مجموعه‌ای از changesetها.

این بخش پارامترهایی مشابه گردانندهٔ changelog می‌پذیرد. تنها تفاوت این است که به جای قالب changelog، قالب shortlog رندر خواهد شد.

/summary

نمایش خلاصه‌ای از وضعیت مخزن.

اطلاعات مربوط به جدیدترین changesetها، نشانک‌ها (bookmarks)، تگ‌ها و شاخه‌ها توسط این گرداننده دریافت می‌شود.

قالب summary رندر می‌شود.

/tags

نمایش اطلاعات دربارهٔ تگ‌ها.

هیچ آرگومانی پذیرفته نمی‌شود.

قالب tags رندر می‌شود.

ابزارهای ادغام در دسترس (Available merge tools)

ابزارهای ادغام خارجی و ویژگی‌های آن‌ها در بخش پیکربندی merge-tools تنظیم می‌شوند - hgrc(5) را ببینید - اما اغلب می‌توان آن‌ها را صرفاً با نام فایل اجرایی‌شان مشخص کرد.

یک ابزار ادغام به‌طور کلی زمانی قابل استفاده است که فایل اجرایی آن در سیستم پیدا شود و بتواند ادغام را انجام دهد. فایل اجرایی زمانی پیدا می‌شود که یک مسیر اجرایی مطلق یا نسبی یا نام یک برنامه در مسیر جستجوی فایل‌های اجرایی باشد. ابزار در صورتی قادر به انجام ادغام در نظر گرفته می‌شود که اگر فایل یک symlink باشد بتواند symlinkها را مدیریت کند، اگر فایل باینری باشد بتواند فایل‌های باینری را مدیریت کند، و در صورتی که ابزار به رابط گرافیکی نیاز دارد، GUI در دسترس باشد.

برخی ابزارهای ادغام داخلی وجود دارند که می‌توان از آن‌ها استفاده کرد. ابزارهای ادغام داخلی عبارتند از:

ابزارهای داخلی همیشه در دسترس هستند و به GUI نیازی ندارند، اما به طور پیش‌فرض پیوندهای نمادین یا فایل‌های باینری را مدیریت نمی‌کنند. برای جزئیات در مورد «قابلیت‌های واقعی» که در بالا توضیح داده شد، به بخش بعدی مراجعه کنید..SS "انتخاب ابزار ادغام (Choosing a merge tool)"

Mercurial هنگام تصمیم‌گیری درباره این‌که از کدام ابزار ادغام استفاده کند، از این قواعد پیروی می‌کند:

به دلایل تاریخی، Mercurial هنگام بررسی قواعد بالا، با ابزارهای ادغام طبق جدول زیر رفتار می‌کند.

هر ستون قابلیت، نشان‌دهنده رفتار Mercurial در قبال ابزارهای ادغام داخلی/خارجی هنگام بررسی هر قاعده است.

اگر پیکربندی merge.strict-capability-check برابر true باشد، Mercurial قابلیت‌های ابزارهای ادغام را در موارد (*) بالا به‌طور دقیق بررسی می‌کند (= هر ستون قابلیت به "?/?" تبدیل می‌شود). این مقدار برای سازگاری با گذشته به‌طور پیش‌فرض false است.

نکته

پس از انتخاب یک برنامه ادغام، Mercurial به‌طور پیش‌فرض ابتدا تلاش خواهد کرد فایل‌ها را با استفاده از یک الگوریتم ادغام ساده ادغام کند. تنها در صورتی که این کار به دلیل تغییرات دارای تداخل با شکست مواجه شود، Mercurial برنامه ادغام را در عمل اجرا خواهد کرد. اینکه آیا ابتدا از الگوریتم ادغام ساده استفاده شود یا خیر، از طریق تنظیم premerge ابزار ادغام قابل کنترل است. premerge به‌طور پیش‌فرض فعال است مگر اینکه فایل باینری یا یک symlink باشد.

برای جزئیات بیشتر درباره پیکربندی ابزارهای ادغام، بخش‌های merge-tools و ui در hgrc(5) را ببینید..SH "پشتیبانی از صفحه‌بند (PAGER SUPPORT)"

برخی از دستورهای Mercurial می‌توانند خروجی زیادی تولید کنند، و Mercurial تلاش خواهد کرد تا از یک صفحه‌بند (pager) استفاده کند تا کار با آن دستورها آسان‌تر شود.

برای تعیین صفحه‌بندی که باید استفاده شود، متغیر برنامه را تنظیم کنید:

[pager]
pager = less -FRX

اگر هیچ صفحه‌بندی در پیکربندی کاربر یا مخزن تنظیم نشده باشد، Mercurial از متغیر محیطی $PAGER استفاده می‌کند. اگر $PAGER تنظیم نشده باشد، pager.pager از پیکربندی پیش‌فرض یا سیستمی استفاده می‌شود. اگر هیچ‌یک از این‌ها تنظیم نشده باشند، یک صفحه‌بند پیش‌فرض استفاده خواهد شد که معمولاً در Unix برابر less و در Windows برابر more است.

در Windows، دستور more از رنگ پشتیبانی نمی‌کند، بنابراین استفاده از آن عملاً رنگ را غیرفعال می‌کند. پوسته‌های MSYS و Cygwin دستور less را به‌عنوان صفحه‌بند ارائه می‌دهند که می‌توان آن را برای پشتیبانی از کدهای رنگی ANSI پیکربندی کرد. برای پیکربندی حالت رنگ هنگام فراخوانی صفحه‌بند، hg help config.color.pagermode را ببینید.

می‌توانید با افزودن دستورها به فهرست pager.ignore، صفحه‌بند را برای دستورهای خاصی غیرفعال کنید:

[pager]
ignore = version, help, update

برای نادیده گرفتن دستورهای سراسری مانند hg version یا hg help، باید آن‌ها را در فایل پیکربندی کاربر خود مشخص کنید.

برای کنترل اینکه آیا برای یک دستور خاص اصلاً از صفحه‌بند استفاده شود یا خیر، می‌توانید از --pager=<value> استفاده کنید:

برای غیرفعال کردن سراسری تمام تلاش‌ها جهت استفاده از صفحه‌بند، این مورد را تنظیم کنید:

[ui]
paginate = never

که از اجرای صفحه‌بند جلوگیری خواهد کرد.

فازها چه هستند؟

فازها سامانه‌ای برای ردگیری این موضوع هستند که کدام مجموعه‌تغییرها (changesets) به اشتراک گذاشته شده‌اند یا باید به اشتراک گذاشته شوند. این کار به جلوگیری از اشتباه‌های متداول هنگام اصلاح تاریخچه کمک می‌کند (برای نمونه، با افزونه‌های mq یا rebase).

هر مجموعه‌تغییر در یک مخزن، در یکی از فازهای زیر قرار دارد:

این فازها دارای ترتیب هستند (public < draft < secret) و هیچ مجموعه‌تغییری نمی‌تواند در فازی پایین‌تر از نیاکان خود باشد. برای نمونه، اگر یک مجموعه‌تغییر public باشد، تمام نیاکان آن نیز public هستند. در نهایت، فازهای مجموعه‌تغییر تنها باید به سمت فاز public تغییر یابند.

فازها چگونه مدیریت می‌شوند؟

در بیشتر موارد، فازها باید به‌صورت شفاف و خودکار عمل کنند. به‌طور پیش‌فرض، یک مجموعه‌تغییر در فاز draft ایجاد می‌شود و هنگامی که به مخزن دیگری push شود، به فاز public منتقل می‌گردد.

به محض اینکه مجموعه‌تغییرها public شوند، افزونه‌هایی مانند mq و rebase برای جلوگیری از ایجاد مجموعه‌تغییرهای تکراری، از دستکاری آن‌ها خودداری خواهند کرد. همچنین فازها را می‌توان در صورت نیاز با دستور hg phase به‌صورت دستی تغییر داد. برای مشاهدهٔ مثال‌ها، hg help -v phase را ببینید.

برای اینکه commitهای شما به‌طور پیش‌فرض secret باشند، این تنظیم را در فایل پیکربندی خود قرار دهید:

[phases]
new-commit = secret

فازها و سرورها

به‌طور معمول، همهٔ سرورها به‌طور پیش‌فرض در وضعیت publishing هستند. این بدان معناست که:

- تمامی مجموعه‌تغییرهای draft که pull یا clone شوند، در سمت کلاینت
در فاز public ظاهر می‌شوند
- تمامی مجموعه‌تغییرهای draft که push شوند، هم در کلاینت و هم در سرور
به‌صورت public ظاهر می‌شوند
- مجموعه‌تغییرهای secret نه push می‌شوند، نه pull، و نه clone

نکته

دریافت (pull) یک مجموعه‌تغییر draft از سروری با حالت publishing، به دلیل ماهیت فقط‌خواندنیِ (read-only) عملیات pull، آن را در سمت سرور به public تغییر وضعیت نمی‌دهد.

گاهی اوقات ممکن است ارسال (push) و دریافت (pull) مجموعه‌تغییرها در فاز draft برای به اشتراک‌گذاری کارهای ناتمام مطلوب باشد. این کار با غیرفعال‌سازی حالت publishing در فایل پیکربندی یک مخزن امکان‌پذیر است:

[phases]
publish = False

برای اطلاعات بیشتر در مورد فایل‌های پیکربندی، hg help config را ببینید.

نکته

با سرورهایی که نگارش‌های قدیمی‌تر Mercurial را اجرا می‌کنند، به‌عنوان publishing رفتار می‌شود.

نکته

مجموعه‌تغییرهای موجود در فاز secret با سرور مبادله نمی‌شوند. این موضوع در مورد محتوای آن‌ها صدق می‌کند: نام فایل‌ها، محتوای فایل‌ها و فراداده‌های مجموعه‌تغییر. به دلایل فنی، ممکن است شناسهٔ (برای مثال d825e4025e39) مجموعه‌تغییر secret به سرور منتقل شود.

برای اطلاعات بیشتر دربارهٔ دستکاری دستی فازها، hg help phase را ببینید.

مشخص کردن یک بازبینی (Specifying single revisions)

یک عدد صحیح ساده، به عنوان شمارهٔ بازبینی در نظر گرفته می‌شود. اعداد صحیح منفی به عنوان آفست‌های ترتیبی از tip در نظر گرفته می‌شوند؛ به‌طوری‌که -1 بیانگر tip، و -2 بیانگر بازبینی پیش از tip است، و به همین ترتیب ادامه می‌یابد.

یک رشتهٔ شانزده‌شانزدهی (hexadecimal) ۴۰ رقمی به عنوان شناسهٔ بازبینی یکتا در نظر گرفته می‌شود. یک رشتهٔ شانزده‌شانزدهی با طول کمتر از ۴۰ نویسه نیز به عنوان یک شناسهٔ بازبینی یکتا در نظر گرفته شده و شناسهٔ فرم‌کوتاه (short-form) نامیده می‌شود. یک شناسهٔ فرم‌کوتاه تنها در صورتی معتبر است که پیشوند دقیقاً یک شناسه با طول کامل باشد.

هر رشتهٔ دیگری به عنوان یک bookmark، برچسب (tag)، یا نام شاخه (branch) در نظر گرفته می‌شود. یک bookmark یک اشاره‌گر جابه‌جاشونده به یک بازبینی است. یک tag نامی دائمی است که به یک بازبینی نسبت داده شده است. نام یک شاخه نشان‌دهندهٔ تازه‌ترین سرشاخهٔ باز (tipmost open branch head) از آن شاخه است - یا در صورتی که همهٔ آن‌ها بسته باشند، تازه‌ترین سرشاخهٔ بستهٔ آن شاخه خواهد بود. نام‌های bookmark، برچسب (tag)، و شاخه (branch) نباید شامل نویسهٔ ":" باشند.

نام رزروشدهٔ "tip" همواره جدیدترین بازبینی را مشخص می‌کند.

نام رزروشدهٔ "null" بیانگر بازبینی تهی است. این، بازبینی یک مخزن خالی و والدِ بازبینی 0 است.

نام رزروشدهٔ "." بیانگر والد دایرکتوری کاری است. اگر هیچ دایرکتوری کاری تحویل گرفته نشده باشد (checked out)، معادل با null خواهد بود. اگر یک ادغام ثبت‌نشده (uncommitted merge) در جریان باشد، "." بازبینی والد اول خواهد بود.

در نهایت، دستورهایی که انتظار یک بازبینی واحد را دارند (مانند hg update) مجموعه‌بازبینی‌ها یا revsetها را نیز می‌پذیرند (برای جزئیات به بخش زیر مراجعه کنید). هنگام دریافت یک revset، آن‌ها از آخرین بازبینی موجود در revset استفاده می‌کنند. تعداد کمی از دستورها دو بازبینی واحد را می‌پذیرند (مانند hg diff). هنگام دریافت یک revset، آن‌ها از نخستین و آخرین بازبینی revset استفاده خواهند کرد..SS مشخص کردن چندین بازنگری

مرکوریال (Mercurial) از یک زبان تابعی برای انتخاب مجموعه‌ای از بازنگری‌ها پشتیبانی می‌کند. عبارت‌ها در این زبان revset نامیده می‌شوند.

این زبان از تعدادی گزاره پشتیبانی می‌کند که توسط عملگرهای میانوند به یکدیگر متصل می‌شوند. از پرانتز می‌توان برای گروه‌بندی استفاده کرد.

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

نویسه‌های خاص را می‌توان با گریز دادن (escape کردن) در شناسه‌های داخل نقل‌قول استفاده کرد؛ به عنوان مثال، \n به عنوان خط جدید تفسیر می‌شود. برای جلوگیری از تفسیر آن‌ها، می‌توان رشته‌ها را با پیشوند r مشخص کرد، مانند r'...'.

عملگرها

تنها یک عملگر پیشوندی وجود دارد:

عملگرهای میانوند پشتیبانی‌شده عبارتند از:

تنها یک عملگر پسوندی وجود دارد:

گزاره‌ها (Predicates)

گزاره‌های زیر پشتیبانی می‌شوند: