CO(1) General Commands Manual CO(1)

co - استخراج ویرایش‌های RCS

co [گزینه‌ها] فایل ...

co یک ویرایش را از هر فایل RCS بازیابی کرده و آن را در فایل کاری متناظر ذخیره می‌کند.

نام‌های فایلی که با یک پسوند RCS مطابقت دارند، نشان‌دهندهٔ فایل‌های RCS هستند؛ سایر نام‌ها نشان‌دهندهٔ فایل‌های کاری می‌باشند. نام‌ها همان‌طور که در ci(1) توضیح داده شده است، با یکدیگر جفت می‌شوند.

ویرایش‌های یک فایل RCS می‌توانند به‌صورت قفل‌شده یا قفل‌نشده استخراج شوند. قفل‌کردن یک ویرایش از به‌روزرسانی‌های هم‌پوشان جلوگیری می‌کند. ویرایشی که برای خواندن یا پردازش (مانند کامپایل کردن) استخراج می‌شود، نیازی به قفل‌شدن ندارد. ویرایشی که برای ویرایش و ثبت بعدی (checkin) استخراج می‌شود، معمولاً باید قفل شود. استخراج همراه با قفل در صورتی که ویرایش مورد نظر برای استخراج در حال حاضر توسط کاربر دیگری قفل شده باشد، با شکست مواجه می‌شود. (یک قفل را می‌توان با rcs(1) شکست.)  استخراج همراه با قفل همچنین مستلزم آن است که فراخواننده در فهرست دسترسی فایل RCS باشد، مگر آنکه مالک فایل یا مدیر سیستم (superuser) باشد، یا فهرست دسترسی خالی باشد. استخراج بدون قفل مشمول محدودیت‌های فهرست دسترسی نبوده و تحت تأثیر وجود قفل‌ها قرار نمی‌گیرد.

یک ویرایش توسط گزینه‌های مربوط به شمارهٔ ویرایش یا شاخه، تاریخ/زمان ثبت، نویسنده، یا وضعیت انتخاب می‌شود. هنگامی که گزینه‌های انتخاب به‌صورت ترکیبی اعمال شوند، co جدیدترین ویرایشی را که تمامی آن‌ها را برآورده کند بازیابی می‌کند. اگر هیچ‌یک از گزینه‌های انتخاب مشخص نشده باشد، co جدیدترین ویرایش را از شاخهٔ پیش‌فرض بازیابی می‌کند (معمولاً شاخهٔ اصلی یا trunk؛ گزینهٔ -b از rcs(1) را ببینید). یک شمارهٔ ویرایش یا شاخه می‌تواند به هر یک از گزینه‌های -f، -I، -l، -M، -p، -q، -r یا -u ضمیمه شود. گزینه‌های -d (تاریخ)، -s (وضعیت)، و -w (نویسنده) از یک شاخهٔ منفرد، یعنی شاخهٔ انتخابی (selected)، استخراج را انجام می‌دهند که این شاخه یا توسط یکی از گزینه‌های -f، ...، -u یا توسط شاخهٔ پیش‌فرض مشخص می‌شود.

دستور co که روی یک فایل RCS بدون هیچ ویرایشی اعمال شود، یک فایل کاری با طول صفر ایجاد می‌کند. co همواره جایگزینی کلمات کلیدی را انجام می‌دهد (زیر را ببینید).

جدیدترین ویرایشی را که شمارهٔ آن کوچک‌تر یا مساوی rev است بازیابی می‌کند. اگر rev به‌جای ویرایش، نشان‌دهندهٔ یک شاخه باشد، جدیدترین ویرایش روی آن شاخه بازیابی می‌شود. اگر rev مشخص نشود، جدیدترین ویرایش روی شاخهٔ پیش‌فرض (گزینهٔ -b از rcs(1) را ببینید) بازیابی می‌شود. اگر rev برابر $ باشد، co شمارهٔ ویرایش را از مقادیر کلمات کلیدی موجود در فایل کاری تعیین می‌کند. در غیر این صورت، یک ویرایش از یک یا چند فیلد عددی یا نمادین تشکیل می‌شود که با نقطه از هم جدا شده‌اند. اگر rev با یک نقطه آغاز شود، شاخهٔ پیش‌فرض (معمولاً شاخهٔ اصلی یا trunk) به ابتدای آن افزوده می‌شود. اگر rev یک شمارهٔ شاخه باشد که به دنبال آن یک نقطه آمده است، جدیدترین ویرایش آن شاخه استفاده می‌شود. معادل عددی یک فیلد نمادین با گزینهٔ -n از دستورهای ci(1) و rcs(1) مشخص می‌شود.
مشابه -r، با این تفاوت که ویرایش بازیابی‌شده را برای فراخواننده قفل نیز می‌کند.
مشابه -r، با این تفاوت که اگر ویرایش بازیابی‌شده توسط فراخواننده قفل شده باشد، قفل آن را باز می‌کند. اگر rev مشخص نشود، -u ویرایش قفل‌شده توسط فراخواننده را در صورت وجود بازیابی می‌کند؛ در غیر این صورت، جدیدترین ویرایش را از شاخهٔ پیش‌فرض بازیابی می‌نماید.
بازنویسی فایل کاری را اجبار می‌کند؛ در ترکیب با -q مفید است. همچنین بخش FILE MODES در زیر را ببینید.
رشته‌های کلمات کلیدی را با استفاده از قالب پیش‌فرض تولید می‌کند، مثلاً $Revision: 5.10.1 $ برای کلمهٔ کلیدی Revision. نام قفل‌کننده در مقدار رشته‌های کلمات کلیدی Header، Id و Locker تنها زمانی درج می‌شود که فایل در حال قفل‌شدن باشد، یعنی توسط ci -l و co -l. این حالت پیش‌فرض است.
مشابه -kkv، با این تفاوت که اگر ویرایش داده‌شده در حال حاضر قفل باشد، نام قفل‌کننده همیشه درج می‌شود.
تنها نام کلمات کلیدی را در رشته‌های کلمات کلیدی تولید می‌کند؛ مقادیر آن‌ها حذف می‌شود. بخش KEYWORD SUBSTITUTION در زیر را ببینید. برای مثال، برای کلمهٔ کلیدی Revision، رشتهٔ $Revision$ را به‌جای $Revision: 5.10.1 $ تولید می‌کند. این گزینه برای نادیده گرفتن تفاوت‌های ناشی از جایگزینی کلمات کلیدی هنگام مقایسهٔ ویرایش‌های مختلف یک فایل مفید است. پیام‌های گزارش حتی در صورت مشخص شدن -kk پس از کلمات کلیدی $Log$ درج می‌شوند، زیرا این عمل هنگام ادغام تغییرات معمولاً مفیدتر است.
رشتهٔ کلمهٔ کلیدی قدیمی را که درست پیش از ثبت (checkin) در فایل کاری وجود داشت تولید می‌کند. برای مثال، برای کلمهٔ کلیدی Revision، در صورتی که رشته هنگام ثبت فایل به آن صورت بوده باشد، رشتهٔ $Revision: 1.1 $ را به‌جای $Revision: 5.10.1 $ تولید می‌کند. این گزینه می‌تواند برای قالب‌های فایلی مفید باشد که نمی‌توانند هیچ تغییری را در زیررشته‌هایی که تصادفاً به شکل رشته‌های کلمات کلیدی هستند تحمل کنند..TP -kb یک تصویر باینری از رشته کلیدواژه قدیمی ایجاد می‌کند. این گزینه مانند -ko عمل می‌کند، با این تفاوت که تمام ورودی و خروجی‌های فایل کاری را در حالت باینری انجام می‌دهد. این امر در میزبان‌های Posix و Unix تفاوت چندانی ایجاد نمی‌کند، اما در میزبان‌های شبه-DOS برای مقداردهی اولیه یک RCS file که قرار است برای فایل‌های باینری استفاده شود، باید از rcs -i -kb استفاده کرد. همچنین، در تمام میزبان‌ها، rcsmerge(1) معمولاً در زمانی که -kb فعال است از ادغام فایل‌ها خودداری می‌کند.
تنها مقادیر کلیدواژه را برای رشته‌های کلیدواژه تولید می‌کند. به عنوان مثال، برای کلیدواژه Revision، به جای $Revision: 5.10.1 $، رشته 5.10.1 را تولید می‌کند. این گزینه می‌تواند در تولید فایل‌ها در زبان‌های برنامه‌نویسی که در آن‌ها حذف جداکننده‌های کلیدواژه مانند $Revision: $ از یک رشته دشوار است، کمک کند. با این حال، پس از حذف نام کلیدواژه‌ها، جایگزینی بعدی کلیدواژه‌ها امکان‌پذیر نخواهد بود، بنابراین این گزینه باید با احتیاط استفاده شود. به دلیل این خطرِ از دست رفتن کلیدواژه‌ها، این گزینه را نمی‌توان با -l ترکیب کرد، و مجوز نوشتن مالک فایل کاری غیرفعال می‌شود؛ برای ویرایش فایل در دفعات بعد، آن را دوباره بدون -kv استخراج (check out) کنید.
نسخهٔ بازیابی‌شده را به جای ذخیره در فایل کاری، در خروجی استاندارد چاپ می‌کند. این گزینه زمانی مفید است که co بخشی از یک لوله (pipe) باشد.
حالت بی‌صدا؛ پیام‌های عیب‌یابی چاپ نمی‌شوند.
حالت تعاملی؛ از کاربر اعلان و پرسش می‌شود، حتی اگر ورودی استاندارد یک پایانه نباشد.
جدیدترین نسخه در شاخهٔ انتخاب‌شده را که تاریخ/زمان تحویل (checkin) آن کوچک‌تر یا مساوی با date باشد بازیابی می‌کند. تاریخ و زمان را می‌توان در قالبی آزاد مشخص کرد. منطقه زمانی LT نمایانگر زمان محلی (local time) است؛ نام‌های دیگر مناطق زمانی رایج نیز شناخته می‌شوند. برای مثال، اگر زمان محلی ۱۱ ژانویه ۱۹۹۰ ساعت ۲۰:۰۰ به وقت Pacific Standard Time (هشت ساعت غربی‌تر از Coordinated Universal Time، (UTC)) باشد، date های زیر با یکدیگر معادل هستند:
8:00 pm lt
4:00 AM, Jan. 12, 1990	default is UTC
1990-01-12 04:00:00+00	ISO 8601 (UTC)
1990-01-11 20:00:00-08	ISO 8601 (local time)
1990/01/12 04:00:00	traditional RCS format
Thu Jan 11 20:00:00 1990 LT	output of ctime(3) + LT
Thu Jan 11 20:00:00 PST 1990	output of date(1)
Fri Jan 12 04:00:00 GMT 1990
Thu, 11 Jan 1990 20:00:00 -0800	Internet RFC 822
12-January-1990, 04:00 WET

اکثر فیلدها در تاریخ و زمان می‌توانند پیش‌فرض داشته باشند. منطقه زمانی پیش‌فرض معمولاً UTC است، اما می‌توان آن را با گزینهٔ -z تغییر داد. سایر مقادیر پیش‌فرض به ترتیب سال، ماه، روز، ساعت، دقیقه و ثانیه (از بیشترین به کمترین اهمیت) تعیین می‌شوند. حداقل یکی از این فیلدها باید ارائه شود. برای فیلدهای حذف‌شده‌ای که اهمیت بالاتری نسبت به بالاترین فیلد ارائه‌شده دارند، مقادیر فعلی منطقه زمانی در نظر گرفته می‌شوند. برای تمام فیلدهای حذف‌شدهٔ دیگر، کمترین مقادیر ممکن در نظر گرفته می‌شود. به عنوان مثال، بدون -z، تاریخ 20, 10:30 به طور پیش‌فرض به 10:30:00 UTC از بیستمین روزِ ماه و سال جاری منطقه زمانی UTC تبدیل می‌شود. اگر تاریخ/زمان حاوی فاصله باشد، باید داخل علامت نقل‌قول قرار گیرد.

زمان ویرایش (modification time) فایل کاری جدید را برابر با تاریخ نسخهٔ بازیابی‌شده قرار می‌دهد. از این گزینه با احتیاط استفاده کنید؛ چرا که ممکن است عملکرد make(1) را دچار اختلال کند.
جدیدترین نسخه را در شاخهٔ انتخاب‌شده که وضعیت آن بر روی state تنظیم شده است، بازیابی می‌کند.
حالت self-same را فعال می‌کند. در این حالت، مالک قفل اهمیتی ندارد، بلکه تنها وجود داشتنِ آن مهم است. در عمل، این بدین معناست که کاربر نمی‌تواند یک نسخه را دو بار استخراج (check out) کند.
زمان ویرایش (modification time) فایل RCS file را حفظ می‌کند، حتی اگر RCS file به دلیل افزودن یا حذف یک قفل تغییر کند. این گزینه می‌تواند از کامپایل مجدد گسترده‌ای که توسط وابستگی make(1) یک نسخه دیگر از فایل کاری به RCS file ایجاد می‌شود، جلوگیری کند. از این گزینه با احتیاط استفاده کنید؛ این گزینه می‌تواند کامپایل مجدد را حتی در مواقعی که نیاز است متوقف کند، به عنوان مثال، زمانی که تغییر قفل به معنای تغییر در رشته‌های کلیدواژه در فایل کاری دیگر باشد.
جدیدترین نسخه در شاخهٔ انتخاب‌شده را که توسط کاربری با نام کاربری login ثبت (check in) شده است، بازیابی می‌کند. اگر آرگومان login حذف شود، نام کاربری فراخواننده فرض می‌شود.
یک نسخهٔ جدید تولید می‌کند که حاصل پیوند (join) نسخه‌های موجود در joinlist است. این گزینه تا حد زیادی با rcsmerge(1) منسوخ شده است، اما برای سازگاری با گذشته حفظ شده است.

فهرست joinlist یک لیست جداشده با کاما از جفت‌هایی با قالب rev2:rev3, است که در آن rev2 و rev3 شماره‌های نسخه (نمادین یا عددی) هستند. برای اولین جفت، rev1 نشان‌دهنده نسخهٔ انتخاب‌شده توسط گزینه‌های بالا از -f، ...، -w است. برای سایر جفت‌ها، rev1 نشان‌دهنده نسخهٔ تولیدشده توسط جفت قبلی است. (بنابراین، خروجی یک پیوند به ورودی پیوند بعدی تبدیل می‌شود.)

برای هر جفت، co نسخه‌های rev1 و rev3 را با توجه به rev2 پیوند می‌دهد. این بدان معناست که تمام تغییراتی که rev2 را به rev1 تبدیل می‌کنند، روی رونوشتی از rev3 اعمال می‌شوند. این ویژگی به‌ویژه زمانی مفید است که rev1 و rev3 انتهای دو شاخه با نیاکان مشترک rev2 باشند. اگر rev1<rev2<rev3 روی همان شاخه باشد، پیوند دادنْ نسخهٔ جدیدی مشابه با rev3 ایجاد می‌کند، اما با واگردانی تمام تغییراتی که از rev1 به rev2 منجر شده‌اند. اگر تغییرات از rev2 به rev1 با تغییرات از rev2 به rev3 هم‌پوشانی داشته باشند، co تداخل‌ها را همان‌طور که در merge(1) شرح داده شده است، گزارش می‌دهد..PP برای جفت اولیه، rev2 می‌تواند حذف شود. مقدار پیش‌فرض، جد مشترک است. اگر هر یک از آرگومان‌ها نشان‌دهنده شاخه باشند، جدیدترین ویرایش‌ها روی آن شاخه‌ها در نظر گرفته می‌شوند. گزینه‌های -l و -u ویرایش rev1 را قفل یا باز می‌کنند.

شماره نسخه RCS را چاپ می‌کند.
شبیه‌سازی نسخه n از RCS، که در آن n می‌تواند 3، 4، یا 5 باشد. این گزینه هنگام تبادل RCS fileها با دیگرانی که نسخه‌های قدیمی‌تر RCS را اجرا می‌کنند می‌تواند مفید باشد. برای این‌که ببینید همکارانتان از کدام نسخه RCS استفاده می‌کنند، از آن‌ها بخواهید دستور rcs -V را اجرا کنند؛ این دستور در نسخه‌های جدیدتر RCS کار می‌کند. اگر کار نکرد، از آن‌ها بخواهید rlog را روی یک RCS file اجرا کنند؛ اگر در چند سطر اول خروجی، رشته branch: وجود نداشت، نسخه ۳ است؛ اگر سال‌های تاریخ تنها دو رقم دارند، نسخه ۴ است؛ در غیر این صورت، نسخه ۵ است. یک RCS file که در هنگام شبیه‌سازی نسخه ۳ تولید شده باشد، شاخه پیش‌فرض خود را از دست می‌دهد. یک ویرایش RCS که هنگام شبیه‌سازی نسخه ۴ یا پیش‌تر تولید شده باشد، دارای برچسب زمانی با حداکثر ۱۳ ساعت اختلاف است. ویرایش استخراج‌شده در حین شبیه‌سازی نسخه ۴ یا پیش‌تر، حاوی تاریخ‌های خلاصه‌شده به فرم yy/mm/dd است و همچنین می‌تواند شامل فاصله‌های خالی و پیشوندهای خطوط متفاوتی در جایگزینی برای $Log$ باشد.
از suffixes برای تعیین پسوند RCS fileها استفاده می‌کند. برای جزئیات بیشتر به ci(1) مراجعه کنید.
قالب خروجی تاریخ را در جایگزینی کلیدواژه مشخص کرده، و منطقه زمانی پیش‌فرض را برای date در گزینه -ddate تعیین می‌کند. مقدار zone باید خالی، یک آفست عددی UTC، یا رشته ویژه LT برای زمان محلی باشد. پیش‌فرض، یک zone خالی است که از قالب سنتی RCS برای UTC بدون نمایش هیچ منطقه زمانی و با اسلش به عنوان جداکننده بخش‌های تاریخ استفاده می‌کند؛ در غیر این صورت، زمان‌ها در قالب ISO 8601 همراه با مشخصه منطقه زمانی در خروجی درج می‌شوند. برای نمونه، اگر زمان محلی ۱۱ ژانویه ۱۹۹۰، ساعت ۲۰:۰۰ به وقت استاندارد اقیانوس آرام، هشت ساعت در غرب UTC باشد، آنگاه زمان به صورت زیر در خروجی نمایش داده می‌شود:
گزینه	خروجی زمان
-z	1990/01/12 04:00:00	(پیش‌فرض)
-zLT	1990-01-11 20:00:00-08
-z+05:30	1990-01-12 09:30:00+05:30

گزینه -z بر تاریخ‌های ذخیره‌شده در RCS fileها تأثیری ندارد؛ این تاریخ‌ها همواره به صورت UTC هستند.

رشته‌هایی به فرم $keyword$ و $keyword:...$ که در متن گنجانده شده‌اند، با رشته‌هایی به فرم $keyword:value$ جایگزین می‌شوند، که در آن keyword و value جفت‌های فهرست‌شده در زیر هستند. کلیدواژه‌ها را می‌توان در رشته‌های لیترال یا کامنت‌ها قرار داد تا یک ویرایش را شناسایی کنند.

در ابتدا، کاربر رشته‌هایی به فرم $keyword$ را وارد می‌کند. در هنگام تحویل‌گیری (checkout)، co این رشته‌ها را با رشته‌هایی به فرم $keyword:value$ جایگزین می‌کند. اگر ویرایشی حاوی رشته‌هایی با فرم اخیر دوباره تحویل داده شود (check in)، فیلدهای مقدار در تحویل‌گیری بعدی جایگزین خواهند شد. بدین ترتیب، مقادیر کلیدواژه‌ها هنگام تحویل‌گیری به‌طور خودکار به‌روزرسانی می‌شوند. این جایگزینی خودکار می‌تواند توسط گزینه‌های -k تغییر یابد.

کلیدواژه‌ها و مقادیر متناظر آن‌ها:

$Author$
نام کاربری (login name) کاربری که ویرایش را تحویل داده است.
$Date$
تاریخ و زمان تحویل ویرایش. با -zzone یک آفست عددی منطقه زمانی اضافه می‌شود؛ در غیر این صورت، تاریخ به صورت UTC است.
$Header$
یک سرایند استاندارد شامل نام کامل RCS file، شماره ویرایش، تاریخ و زمان، نویسنده، وضعیت (state)، و قفل‌کننده (در صورت قفل بودن). با -zzone یک آفست عددی منطقه زمانی به تاریخ اضافه می‌شود؛ در غیر این صورت، تاریخ به صورت UTC است.
$Id$
همانند $Header$، با این تفاوت که نام RCS file بدون بخش‌های دایرکتوری است.
$Locker$
نام کاربری کاربری که ویرایش را قفل کرده است (در صورت قفل نبودن، خالی است).
$Log$
پیام لاگی که در هنگام تحویل ارائه شده است، با یک سرایند پیش از آن شامل نام RCS file، شماره ویرایش، نویسنده، و تاریخ و زمان. با -zzone یک آفست عددی منطقه زمانی اضافه می‌شود؛ در غیر این صورت، تاریخ به صورت UTC است. پیام‌های لاگ موجود جایگزین نمی‌شوند. در عوض، پیام لاگ جدید پس از $Log:...$ درج می‌شود. این ویژگی برای انباشتن یک گزارش تغییرات کامل در یک فایل منبع مفید است.

در ابتدای هر خط درج‌شده، همان رشته‌ای قرار می‌گیرد که در پیشوند خط $Log$ آمده است. برای نمونه، اگر خط $Log$ به صورت “// $Log: tan.cc $” باشد، RCS ابتدای هر خط از لاگ را با “// ” پیشوندگذاری می‌کند. این ویژگی برای زبان‌هایی با کامنت‌هایی که تا انتهای خط امتداد دارند مفید است. عرف برای زبان‌های دیگر، استفاده از پیشوند “ ∗ ” درون یک کامنت چندخطی است. برای نمونه، کامنت لاگ اولیه یک برنامه C معمولاً به فرم زیر است:

/∗
∗ $Log$
∗/

برای سازگاری عقبرو با نسخه‌های قدیمی‌تر RCS، اگر پیشوند لاگ /∗ یا (∗ باشد که با فاصله‌های خالی اختیاری احاطه شده است، خطوط لاگ درج‌شده به جای / یا ( شامل یک فاصله خالی خواهند بود؛ با این حال، این کاربرد منسوخ شده است و نباید به آن اتکا کرد. $Name$ نام نمادین استفاده‌شده برای واکشی بازبینی، در صورت وجود. برای نمونه، co -rJoe عبارت $Name: Joe $ را تولید می‌کند. دستور سادهٔ co تنها $Name:  $ را تولید می‌کند.

$RCSfile$
نام RCS file بدون بخش‌های دایرکتوری.
$Revision$
شماره بازبینی اختصاص‌یافته به بازبینی.
$Source$
نام کامل RCS file.
$State$
وضعیت اختصاص‌یافته به بازبینی با گزینهٔ -s از rcs(1) یا ci(1).

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

char	escape sequence
tab	\t
newline	\n
space	\040
$	\044
\	\\

فایل کاری، مجوزهای خواندن و اجرا را از فایل RCS به ارث می‌برد. افزون بر این، مجوز نوشتن مالک فعال می‌شود، مگر آنکه -kv تنظیم شده باشد یا فایل به صورت قفل‌نشده واکشی شود و قفل‌گذاری روی سخت‌گیرانه تنظیم شده باشد (ببینید: rcs(1)).

اگر فایلی با نام فایل کاری از پیش وجود داشته باشد و دارای مجوز نوشتن باشد، co عملیات واکشی را متوقف می‌کند، و در صورت امکان پیش از آن پرسش می‌کند. اگر فایل کاری موجود قابل نوشتن نباشد یا -f داده شده باشد، فایل کاری بدون پرسش حذف می‌شود.

co تقریباً همانند ci(1) به فایل‌ها دسترسی پیدا می‌کند، با این تفاوت که نیازی به خواندن فایل کاری ندارد مگر آنکه شماره بازبینیِ $ مشخص شده باشد.

گزینه‌هایی که به ابتدای فهرست آرگومان‌ها افزوده می‌شوند و با فاصله از هم جدا می‌گردند. یک بک‌اسلش، فاصله‌های درون یک گزینه را گریز می‌دهد. گزینه‌های RCSINIT به ابتدای فهرست آرگومان‌های بیشتر دستورهای RCS افزوده می‌شوند. گزینه‌های سودمند RCSINIT شامل -q، -V، -x و -z هستند.
به‌طور معمول برای سرعت بیشتر، اگر اندازهٔ RCS file کمتر از memory-limit باشد (که در حال حاضر مقدار پیش‌فرض آن «نامحدود» است)، دستورها آن را در حافظه نگاشت کرده یا درون حافظه کپی می‌کنند. در غیر این صورت (یا اگر روش‌های پرسرعتِ اولیّه با شکست مواجه شوند)، دستورها به استفاده از روال‌های استاندارد ورودی/خروجی برمی‌گردند. می‌توانید با تنظیم RCS_MEM_LIMIT روی یک مقدار عددی lim (اندازه‌گیری‌شده بر حسب کیلوبایت) محدودیت حافظه را تغییر دهید. مقدار خالی بدون هیچ پیامی نادیده گرفته می‌شود. به عنوان یک اثر جانبی، تعیین کردن RCS_MEM_LIMIT مانع از بازگشت به روال‌های کندتر می‌شود.
نام دایرکتوری موقت. اگر تنظیم نشده باشد، متغیرهای محیطی TMP و TEMP به جای آن بررسی می‌شوند و نخستین مقدار یافت‌شده در نظر گرفته می‌شود؛ اگر هیچ‌یک از آن‌ها تنظیم نشده باشند، یک مقدار پیش‌فرض وابسته به میزبان استفاده می‌شود که معمولاً /tmp است.

نام RCS file، نام فایل کاری، و شماره بازبینیِ بازیابی‌شده در خروجی عیب‌یابی نوشته می‌شوند. وضعیت خروج صفر است اگر و تنها اگر تمام عملیات‌ها موفقیت‌آمیز بوده باشند. نویسنده: Walter F. Tichy.
بازبینی صفحه راهنما: 5.10.1؛ تاریخ انتشار: 2022-02-03.
کپی‌رایت © 2010-2022 Thien-Thi Nguyen.
کپی‌رایت © 1990, 1991, 1992, 1993, 1994, 1995.SH "شناسایی (IDENTIFICATION)" Paul Eggert.
کپی‌رایت © 1982, 1988, 1989 Walter F. Tichy.

ci(1), ctime(3), date(1), ident(1), make(1), rcs(1), rcsclean(1), rcsdiff(1), rcsmerge(1), rlog(1), rcsfile(5).

Walter F. Tichy, RCS--A System for Version Control, Software--Practice & Experience 15, 7 (July 1985), 637-654.

مستندات کامل برای RCS در قالب یک راهنمای Texinfo نگهداری می‌شود. اگر برنامه‌های info(1) و RCS به درستی روی سیستم شما نصب شده باشند، دستور

info rcs

باید دسترسی شما را به راهنمای کامل فراهم کند. علاوه بر این، صفحه خانگی RCS:

http://www.gnu.org/software/rcs

شامل اخبار و پیوندهایی به آخرین انتشار، سایت توسعه و غیره است.

پیوندها به RCS و فایل‌های کاری حفظ نمی‌شوند.

هیچ راهی برای جلوگیری انتخابی از بسط کلمات کلیدی وجود ندارد، مگر با نوشتن متفاوت آن‌ها. در nroff و troff، این کار با قرار دادن نویسه پوچ (null-character) \& درون کلمه کلیدی انجام می‌شود.

2022-02-03 GNU RCS 5.10.1