CI(1) General Commands Manual CI(1)

ci - ثبت ویرایش‌های RCS

ci [options] file ...

دستور ci ویرایش‌های جدید را در فایل‌های RCS ذخیره می‌کند. هر نام فایلی که با یک پسوند RCS مطابقت داشته باشد، یک فایل RCS در نظر گرفته می‌شود. سایر فایل‌ها به‌عنوان فایل‌های کاری حاوی ویرایش‌های جدید در نظر گرفته می‌شوند. دستور ci محتویات هر فایل کاری را در فایل RCS متناظر آن قرار می‌دهد. اگر تنها یک فایل کاری مشخص شده باشد، ci تلاش می‌کند فایل RCS متناظر را ابتدا در یک زیردایرکتوری RCS و سپس در دایرکتوریِ فایل کاری بیابد. برای جزئیات بیشتر، بخش FILE NAMING در زیر را ببینید.

برای کارکرد ci، نام کاربری فراخواننده باید در فهرست دسترسی (access list) باشد، مگر اینکه فهرست دسترسی خالی باشد یا فراخواننده کاربر ریشه (superuser) یا مالک فایل باشد. برای افزودن یک ویرایش جدید به یک شاخهٔ موجود، ویرایش راس (tip revision) در آن شاخه باید توسط فراخواننده قفل شده باشد. در غیر این صورت، تنها یک شاخهٔ جدید را می‌توان ایجاد کرد. اگر از قفل‌گذاری غیرسخت‌گیرانه (non-strict) استفاده شود، این محدودیت برای مالک فایل اعمال نمی‌شود (ببینید: rcs(1)). قفلی را که در اختیار شخص دیگری است می‌توان با دستور rcs شکست.

مگر در صورتی که گزینهٔ -f مشخص شده باشد، ci بررسی می‌کند که آیا ویرایش ارائه‌شده برای ثبت با ویرایش پیشین تفاوت دارد یا خیر. اگر تفاوتی نداشته باشد، ci به‌جای ایجاد ویرایش جدید، به ویرایش پیشین بازمی‌گردد (revert می‌کند). برای بازگشت، حالت عادیِ ci فایل کاری و هرگونه قفل را حذف می‌کند؛ ci -l قفل را نگه می‌دارد و ci -u قفل را برمی‌دارد، و سپس هر دوی آن‌ها یک فایل کاری جدید تولید می‌کنند، درست مانند اینکه co -l یا co -u روی ویرایش پیشین اعمال شده باشد. هنگام بازگشت، گزینه‌های -n و -s روی ویرایش پیشین اعمال می‌شوند.

برای هر ویرایشی که ثبت می‌شود، ci یک پیام گزارش تغییرات (log message) درخواست می‌کند. پیام ثبت تغییرات باید خلاصه‌ای از تغییرات باشد و باید با پایان فایل (EOF) یا با خطی که تنها شامل . است پایان یابد. اگر چند فایل با هم ثبت شوند، ci می‌پرسد که آیا از پیام گزارش قبلی مجدداً استفاده شود یا خیر. اگر ورودی استاندارد یک ترمینال نباشد، ci از نمایش اعلان خودداری کرده و از همان پیام گزارش برای همهٔ فایل‌ها استفاده می‌کند. همچنین ببینید: -m.

اگر فایل RCS وجود نداشته باشد، ci آن را ایجاد کرده و محتویات فایل کاری را به‌عنوان ویرایش اولیه ذخیره می‌کند (شمارهٔ پیش‌فرض: 1.1). فهرست دسترسی با مقدار خالی مقداردهی اولیه می‌شود. به‌جای پیام گزارش، ci یک متن توصیفی درخواست می‌کند (گزینهٔ -t در زیر را ببینید).

شمارهٔ rev برای ویرایش ثبت‌شده را می‌توان با هر یک از گزینه‌های -f، -i، -I، -j، -k، -l، -M، -q، -r یا -u مشخص کرد. rev می‌تواند نمادین (symbolic)، عددی یا ترکیبی از هر دو باشد. نام‌های نمادین در rev باید از پیش تعریف شده باشند؛ گزینه‌های -n و -N را برای تخصیص نام‌ها در هنگام ثبت ببینید. اگر rev برابر با $ باشد، ci شمارهٔ ویرایش را از مقادیر کلیدواژه‌ها در فایل کاری تعیین می‌کند.

اگر rev با یک نقطه آغاز شود، شاخهٔ پیش‌فرض (معمولاً تنه یا trunk) به ابتدای آن اضافه می‌شود. اگر rev شمارهٔ یک شاخه باشد که نقطه‌ای به دنبال آن آمده است، آخرین ویرایش موجود روی آن شاخه استفاده خواهد شد.

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

اگر rev به‌جای شمارهٔ ویرایش، یک شاخه باشد، ویرایش جدید به انتهای آن شاخه افزوده می‌شود. شمارهٔ سطح (level number) با افزایش دادن شمارهٔ ویرایش راسِ آن شاخه به دست می‌آید. اگر rev به شاخه‌ای اشاره کند که وجود ندارد، آن شاخه با ویرایش اولیه‌ای با شمارهٔ rev.1. ایجاد می‌شود.

اگر rev مشخص نشود، ci تلاش می‌کند شمارهٔ ویرایش جدید را از آخرین قفل فراخواننده استخراج کند. اگر فراخواننده ویرایش راسِ یک شاخه را قفل کرده باشد، ویرایش جدید به انتهای آن شاخه اضافه می‌شود. شمارهٔ ویرایش جدید از طریق افزایش دادن شمارهٔ ویرایش راس حاصل می‌شود. اگر فراخواننده ویرایشی غیر از راس را قفل کرده باشد، یک شاخهٔ جدید از آن ویرایش با افزایش بالاترین شمارهٔ شاخه در آن ویرایش آغاز می‌شود. شماره‌های اولیهٔ پیش‌فرض برای شاخه و سطح برابرند با 1.

اگر rev مشخص نشده باشد و فراخواننده هیچ قفلی نداشته باشد، اما مالک فایل باشد و قفل‌گذاری روی حالت strict تنظیم نشده باشد، ویرایش به شاخهٔ پیش‌فرض اضافه می‌شود (معمولاً تنه؛ گزینهٔ -b دستور rcs(1) را ببینید)..PP استثنا: در شاخهٔ اصلی (trunk)، بازبینی‌ها می‌توانند به انتها افزوده شوند، اما نمی‌توانند درج شوند.

بازبینی rev را ثبت می‌کند.
گزینهٔ -r به‌تنهایی (بدون هیچ بازبینی) معنای غیرمعمولی در ci دارد. در سایر دستورهای RCS، گزینهٔ -r به‌تنهایی، جدیدترین بازبینی را روی شاخهٔ پیش‌فرض مشخص می‌کند، اما در ci، گزینهٔ -r به‌تنهایی، رفتار پیش‌فرض مبنی بر آزادسازی قفل و حذف فایل کاری را دوباره برقرار می‌کند، و برای بازنویسی و لغو گزینه‌های پیش‌فرض -l یا -u که توسط نام‌های مستعار پوسته یا اسکریپت‌ها تنظیم شده‌اند، به کار می‌رود.
مانند -r عمل می‌کند، به جز اینکه یک co -l اضافی برای بازبینی سپرده‌شده انجام می‌دهد. بدین ترتیب، بازبینی سپرده‌شده بلافاصله مجدداً تحویل گرفته شده و قفل می‌شود. این گزینه برای ذخیره کردن یک بازبینی زمانی که شخص می‌خواهد پس از ثبت، به ویرایش آن ادامه دهد، مفید است.
مانند -l عمل می‌کند، با این تفاوت که بازبینی سپرده‌شده قفل نمی‌شود. این به شخص امکان می‌دهد فایل کاری را بلافاصله پس از ثبت بخواند.

گزینه‌های -l، گزینهٔ تنهای -r، و -u مانعة‌الجمع هستند و بدون هیچ پیامی یکدیگر را لغو می‌کنند. برای نمونه، ci -u -r معادل ci -r است، زیرا -r تنها، بر -u اولویت داشته و آن را لغو می‌کند.

سپرده‌گذاری را اجباری می‌کند؛ بازبینی جدید ثبت و سپرده می‌شود، حتی اگر تفاوتی با بازبینی قبلی نداشته باشد.
فایل کاری را برای مقادیر کلیدواژه‌ها به منظور تعیین شمارهٔ بازبینی، تاریخ ایجاد، وضعیت، و نویسندهٔ آن جستجو می‌کند (نگاه کنید به co(1))، و این مقادیر را به جای محاسبهٔ محلی، به بازبینی سپرده‌شده اختصاص می‌دهد. همچنین یک پیام ورود (login) پیش‌فرض تولید می‌کند که به حساب کاربری فراخواننده و تاریخ واقعی ثبت اشاره دارد. این گزینه برای توزیع نرم‌افزار کاربردی است. بازبینی‌ای که به چندین سایت مختلف ارسال می‌شود باید با گزینهٔ -k در آن سایت‌ها ثبت شود تا شماره، تاریخ، نویسنده، و وضعیت اصلی حفظ شوند. مقادیر کلیدواژهٔ استخراج‌شده و پیام رخدادنگاری پیش‌فرض را می‌توان با گزینه‌های -d، -m، -s، -w و هر گزینه‌ای که حامل شمارهٔ بازبینی باشد، لغو و بازنویسی کرد.
حالت بی‌صدا؛ خروجی تشخیصی چاپ نمی‌شود. بازبینی‌ای که تفاوتی با بازبینی پیشین نداشته باشد، سپرده نمی‌شود، مگر آنکه -f داده شده باشد.
ثبت اولیه؛ در صورتی که فایل RCS از قبل وجود داشته باشد، خطا گزارش می‌کند. این گزینه از شرایط رقابتی (race conditions) در برخی برنامه‌ها جلوگیری می‌کند.
صرفاً ثبت می‌کند و مقداردهی اولیه انجام نمی‌دهد؛ در صورتی که فایل RCS از قبل وجود نداشته باشد، خطا گزارش می‌کند.
حالت تعاملی؛ از کاربر اعلان دریافت شده و سؤال پرسیده می‌شود، حتی اگر ورودی استاندارد یک ترمینال نباشد.
از date برای تاریخ و زمان ثبت استفاده می‌کند. مقدار date در قالب آزاد به‌گونه‌ای که در co(1) توضیح داده شده، مشخص می‌شود. این کار برای تنظیم ساختگی تاریخ ثبت، و برای -k در صورت در دسترس نبودن تاریخ، مفید است. اگر date خالی باشد، از زمان آخرین تغییر فایل کاری استفاده می‌شود.
زمان تغییر را روی هر فایل کاری جدید، برابر با تاریخ بازبینیِ دریافت‌شده قرار می‌دهد. برای نمونه، ci -d -M -u f زمان تغییر f را دستکاری نمی‌کند، حتی اگر محتویات f به دلیل جایگزینی کلیدواژه‌ها تغییر کند. از این گزینه با احتیاط استفاده کنید؛ چرا که می‌تواند make(1) را سردرگم کند.
از رشتهٔ msg به‌عنوان پیام رخدادنگاری (log message) برای تمام بازبینی‌های ثبت‌شده استفاده می‌کند. اگر msg حذف شود، مقدار پیش‌فرض آن "*** empty log message ***" خواهد بود. طبق قرارداد، پیام‌های رخدادنگاری که با # آغاز می‌شوند توضیح (comment) هستند و توسط برنامه‌هایی مانند بستهٔ vc در GNU Emacs نادیده گرفته می‌شوند. همچنین، پیام‌های رخدادنگاری که با {clumpname} (به همراه نویسهٔ فاصله در ادامه) شروع می‌شوند، در صورت امکان برای گروه‌بندی با یکدیگر در نظر گرفته شده‌اند، حتی اگر به فایل‌های متفاوتی مرتبط باشند؛ برچسب {clumpname} صرفاً برای دسته‌بندی استفاده می‌شود و بخشی از خودِ پیام رخدادنگاری به حساب نمی‌آید.
نام نمادین name را به شمارهٔ بازبینی ثبت‌شده اختصاص می‌دهد. اگر name از قبل به شمارهٔ دیگری اختصاص یافته باشد، ci یک پیام خطا چاپ می‌کند.
مشابه -n، با این تفاوت که انتساب قبلی name را لغو و بازنویسی می‌کند.
وضعیت (state) بازبینی ثبت‌شده را روی شناسهٔ state تنظیم می‌کند. وضعیت پیش‌فرض Exp است.
متن توصیفی را از محتویات فایلِ نام‌بردهٔ file درون فایل RCS می‌نویسد و متن موجود را حذف می‌کند. نام file نمی‌تواند با - شروع شود..TP -t-string متن توصیفی را از string در فایل RCS می‌نویسد و متن موجود را حذف می‌کند.

گزینهٔ -t در هر دو شکل خود، تنها در اولین ثبت (initial checkin) اثر دارد؛ در غیر این صورت بدون هیچ هشداری نادیده گرفته می‌شود.

در اولین ثبت، اگر -t داده نشود، ci متن را از ورودی استاندارد دریافت می‌کند، که با پایان فایل (end-of-file) یا خطی که به تنهایی شامل . باشد پایان می‌یابد. اگر تعامل با کاربر ممکن باشد، متن درخواست می‌شود؛ -I را ببینید.

برای سازگاری رو به عقب با نسخه‌های قدیمی‌تر RCS، گزینهٔ خالی -t نادیده گرفته می‌شود.

زمان تغییر (modification time) مربوط به فایل RCS را روی زمان ویرایش جدید تنظیم می‌کند، اگر زمان اولی پیش از دومی باشد و ویرایش جدیدی وجود داشته باشد؛ در غیر این صورت، زمان تغییر فایل RCS حفظ می‌شود. اگر ویرایشی را قفل کرده باشید، ci معمولاً زمان تغییر فایل RCS را به زمان جاری به‌روزرسانی می‌کند، زیرا قفل در فایل RCS ذخیره می‌شود و حذف قفل مستلزم تغییر دادن فایل RCS است. این امر می‌تواند به یکی از دو روش باعث شود که یک فایل RCS جدیدتر از فایل کاری ایجاد شود: نخست، ci -M می‌تواند یک فایل کاری با تاریخی پیش از زمان جاری ایجاد کند؛ دوم، هنگام بازگردانی به ویرایش پیشین، فایل RCS می‌تواند تغییر کند در حالی که فایل کاری دست‌نخورده باقی می‌ماند. این دو حالت می‌توانند باعث بازکامپایل شدن‌های غیرضروری ناشی از وابستگی make(1) فایل کاری به فایل RCS شوند. گزینهٔ -T با تنظیم ساختگی تاریخ فایل RCS، از این بازکامپایل شدن جلوگیری می‌کند. از این گزینه با احتیاط استفاده کنید؛ زیرا می‌تواند مانع بازکامپایل شود حتی زمانی که ثبت یک فایل کاری باید بر فایل کاری دیگری که با همان فایل RCS مرتبط است اثر بگذارد. برای نمونه، فرض کنید زمان فایل RCS برابر 01:00 است، زمان فایل کاری (تغییر یافته) 02:00 است، نسخهٔ دیگری از فایل کاری زمانی برابر 03:00 دارد، و زمان فعلی 04:00 است. در این صورت، ci -d -T زمان فایل RCS را به جای 04:00 معمول روی 02:00 تنظیم می‌کند؛ این کار باعث می‌شود make(1) (به نادرستی) تصور کند که نسخهٔ دیگر از فایل RCS جدیدتر است.
از login برای فیلد نویسندهٔ (author) ویرایش ثبت‌شده استفاده می‌کند. برای تنظیم ساختگی نام نویسنده، و برای -k در صورتی که هیچ نویسنده‌ای در دسترس نباشد، مفید است.
شماره نسخهٔ RCS را چاپ می‌کند.
نسخهٔ n از RCS را شبیه‌سازی می‌کند. برای جزئیات به co(1) مراجعه کنید.
پسوندهای فایل RCS را مشخص می‌کند. یک پسوند غیرخالی با هر نام فایلی که به آن پسوند ختم شود مطابقت می‌کند. یک پسوند خالی با هر نام فایلی به شکل RCS/frag یا frag1/RCS/frag2 مطابقت دارد. گزینهٔ -x می‌تواند فهرستی از پسوندها را که با / از یکدیگر جدا شده‌اند مشخص کند. برای نمونه، -x,v/ دو پسوند را تعیین می‌کند: ,v و پسوند خالی. اگر دو یا چند پسوند مشخص شده باشند، هنگام جستجو برای یک فایل RCS به ترتیب بررسی می‌شوند؛ نخستین پسوندی که کار کند برای آن فایل استفاده می‌شود. اگر هیچ فایل RCS یافت نشود اما امکان ایجاد یک فایل RCS وجود داشته باشد، پسوندها به ترتیب بررسی می‌شوند تا نام فایل RCS جدید تعیین شود. مقدار پیش‌فرض برای suffixes به نحوهٔ نصب بستگی دارد؛ به طور معمول برای میزبان‌هایی مانند Unix که ویرگول را در نام فایل مجاز می‌دانند ,v/ است، و برای سایر میزبان‌ها خالی است (یعنی فقط پسوند خالی).
قالب خروجی تاریخ را در جایگزینی کلیدواژه‌ها مشخص می‌کند، و منطقهٔ زمانی پیش‌فرض را برای date در گزینهٔ -ddate تعیین می‌کند. zone می‌تواند خالی، یک آفست عددی از UTC، یا رشتهٔ ویژهٔ LT برای زمان محلی باشد. پیش‌فرض یک zone خالی است، که از قالب سنتی RCS برای UTC، بدون ذکر منطقهٔ زمانی و با اسلش‌های جداکنندهٔ بخش‌های تاریخ استفاده می‌کند؛ در غیر این صورت، زمان‌ها در قالب ISO 8601 همراه با ذکر منطقهٔ زمانی در خروجی نمایش داده می‌شوند. برای نمونه، اگر زمان محلی ۱۱ ژانویه ۱۹۹۰، ساعت ۲۰:۰۰ به وقت استاندارد اقیانوس آرام (Pacific Standard Time)، هشت ساعت در غرب 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 اثری ندارد؛ این تاریخ‌ها همواره به صورت UTC هستند..SH "نام‌گذاری فایل (FILE NAMING)" جفت‌های فایل RCS و فایل‌های کاری را می‌توان به سه روش مشخص کرد (همچنین بخش مثال‌ها را ببینید).

۱) هم فایل RCS و هم فایل کاری مشخص شده باشند. نام فایل RCS به صورت frag1/workfileX و نام فایل کاری به شکل frag2/workfile است که در آن frag1/ و frag2/ نام‌های فایل (احتمالاً متفاوت یا خالی) هستند، workfile یک نام فایل است، و X یک پسوند RCS است. اگر X خالی باشد، frag1/ باید با RCS/ شروع شود یا شامل /RCS/. باشد.

۲) تنها فایل RCS مشخص شده باشد. در این صورت فایل کاری در دایرکتوری جاری ایجاد می‌شود و نام آن با حذف frag1/ و پسوند X. از نام فایل RCS به دست می‌آید.

۳) تنها فایل کاری مشخص شده باشد. در این حالت، ci هر پسوند RCS مانند X را به نوبت بررسی می‌کند و به دنبال یک فایل RCS به شکل frag2/RCS/workfileX یا (در صورتی که مورد اول یافت نشود و X غیرخالی باشد) به صورت frag2/workfileX. می‌گردد.

اگر در ۱) و ۲) فایل فایل RCS بدون نام فایل مشخص شده باشد، ci ابتدا در دایرکتوری ./RCS و سپس در دایرکتوری جاری به دنبال فایل RCS می‌گردد.

در صورتی که تلاش برای باز کردن یک فایل RCS به دلیلی غیرمعمول با شکست مواجه شود، حتی اگر نام آن فایل RCS فقط یکی از چندین حالت ممکن باشد، ci خطا گزارش می‌دهد. برای نمونه، به منظور جلوگیری از استفاده از دستورهای RCS در یک دایرکتوری مانند d, یک فایل معمولی به نام d/RCS ایجاد کنید تا تلاش‌های ناخواسته برای استفاده از دستورهای RCS در d با شکست مواجه شود، چرا که d/RCS یک دایرکتوری نیست.

فرض کنید ,v یک پسوند RCS است و دایرکتوری جاری شامل زیردایرکتوری RCS به همراه یک فایل RCS به نام io.c,v. باشد. در این صورت، هر یک از دستورهای زیر یک نسخه از io.c را به عنوان آخرین نگارش در RCS/io.c,v ثبت (check in) کرده و io.c. را حذف می‌کند.

ci  io.c;    ci  RCS/io.c,v;   ci  io.c,v;
ci  io.c  RCS/io.c,v;    ci  io.c  io.c,v;
ci  RCS/io.c,v  io.c;    ci  io.c,v  io.c;

در مقابل، فرض کنید پسوند خالی یک پسوند RCS باشد و دایرکتوری جاری شامل زیردایرکتوری RCS با یک فایل RCS به نام io.c. باشد. در این حالت، هر یک از دستورهای زیر یک نگارش جدید را ثبت (check in) می‌کند.

ci  io.c;    ci  RCS/io.c;
ci  io.c  RCS/io.c;
ci  RCS/io.c  io.c;
یک فایل RCS ایجاد شده توسط ci مجوزهای خواندن و اجرا را از فایل کاری به ارث می‌برد. اگر فایل RCS از قبل وجود داشته باشد، ci مجوزهای خواندن و اجرای آن را حفظ می‌کند. ci همواره تمام مجوزهای نوشتن را در فایل RCSها خاموش می‌کند.

فایل‌های موقت در دایرکتوری حاوی فایل کاری، و همچنین در دایرکتوری موقت ایجاد می‌شوند (ببینید TMPDIR در بخش ENVIRONMENT). یک یا چند فایل سمافور (semaphore) در دایرکتوری حاوی فایل RCS ایجاد می‌شوند. با یک پسوند غیرخالی، نام‌های سمافور با نخستین نویسهٔ پسوند آغاز می‌شوند؛ بنابراین، پسوندی را مشخص نکنید که نویسهٔ نخست آن بتواند همانند نویسهٔ اول نام یک فایل کاری باشد. با یک پسوند خالی، نام‌های سمافور به _ ختم می‌شوند، بنابراین نام‌های فایل کاری نباید به _ ختم شوند.

دستور ci هرگز یک فایل RCS یا فایل کاری را مستقیماً تغییر نمی‌دهد. به‌طور معمول، ci پیوند فایل را حذف کرده (unlink) و یک فایل جدید می‌سازد؛ اما به‌جای شکستن زنجیره‌ای از یک یا چند پیوند نمادین به یک فایل RCS، در عوض پیوند فایل مقصد را حذف می‌کند. بنابراین، ci هرگونه پیوند سخت یا نمادین را به هر فایل کاری که تغییر می‌دهد می‌شکند؛ و پیوندهای سخت به فایل RCSها بی‌اثر می‌شوند، اما پیوندهای نمادین به فایل RCSها حفظ می‌گردند.

کاربر مؤثر (effective user) باید بتواند دایرکتوری حاوی فایل RCS را جستجو کرده (پیمایش کند) و در آن بنویسد. به‌طور معمول، کاربر واقعی (real user) باید بتواند فایل‌های کاری و RCS را بخواند و دایرکتوری حاوی فایل کاری را جستجو کرده و در آن بنویسد؛ با این حال، برخی از میزبان‌های قدیمی‌تر نمی‌توانند به‌آسانی میان کاربران واقعی و مؤثر جابه‌جا شوند، بنابراین در این میزبان‌ها از کاربر مؤثر برای تمام دسترسی‌ها استفاده می‌شود. کاربر مؤثر با کاربر واقعی یکسان است مگر اینکه نسخه‌های شما از ci و co دارای امتیازات setuid باشند. همان‌طور که در بخش بعدی شرح داده شده است، این امتیازات امنیت بیشتری به همراه دارند اگر کاربر مؤثر مالک تمام فایل RCSها و دایرکتوری‌ها باشد، و تنها در صورتی که فقط کاربر مؤثر بتواند در دایرکتوری‌های RCS بنویسد.

کاربران می‌توانند دسترسی به فایل RCSها را با تنظیم مجوزهای دایرکتوری حاوی فایل‌ها کنترل کنند؛ فقط کاربرانی با دسترسی نوشتن در دایرکتوری می‌توانند از دستورات RCS برای تغییر فایل RCSهای آن استفاده نمایند. به‌عنوان مثال، در میزبان‌هایی که به کاربر اجازه می‌دهند متعلق به چندین گروه باشد، می‌توان دایرکتوری‌های RCS متعلق به یک گروه را فقط برای همان گروه قابل نوشتن کرد. این رویکرد برای پروژه‌های غیررسمی کافی است، اما به این معنی است که هر عضو گروه می‌تواند به‌طور دلخواه فایل RCSهای گروه را تغییر دهد و حتی می‌تواند آن‌ها را به‌طور کامل حذف کند. از این رو پروژه‌های رسمی‌تر گاهی میان مدیر سامانهٔ RCS، که می‌تواند بنا به صلاحدید فایل RCSها را تغییر دهد، و سایر اعضای پروژه که می‌توانند بازبینی‌های (revisions) جدید را ثبت کنند (check in) اما مجاز به تغییر دیگری در فایل RCSها نیستند، تمایز قائل می‌شوند.

برای جلوگیری از حذف بازبینی‌ها توسط هر شخصی به جز مدیر سامانهٔ RCS، یک گروه از کاربران می‌توانند به شیوهٔ زیر از امتیازات setuid بهره ببرند:

  • بررسی کنید که میزبان از کاربرد setuid برای RCS پشتیبانی می‌کند یا خیر. در صورت وجود هرگونه تردید با یک کارشناس معتمد مشورت کنید. بهترین وضعیت این است که فراخوان سیستمی seteuid همان‌گونه که در استاندارد Posix 1003.1a Draft 5 شرح داده شده کار کند، زیرا RCS می‌تواند به‌راحتی میان کاربران واقعی و مؤثر جابه‌جا شود، حتی اگر کاربر واقعی root باشد. در غیر این صورت، انتخاب مناسب بعدی این است که فراخوان سیستمی setuid از setuid ذخیره‌شده پشتیبانی کند (رفتار {_POSIX_SAVED_IDS} در Posix 1003.1-1990)؛ این حالت تنها در صورتی با شکست مواجه می‌شود که کاربر واقعی یا مؤثر root باشد. چنانچه RCS هرگونه خطایی در setuid شناسایی کند، بی‌درنگ متوقف می‌شود.
  • یک کاربر A را انتخاب کنید تا به‌عنوان مدیر سامانهٔ RCS برای این گروه از کاربران عمل کند. تنها A می‌تواند دستور rcs را بر روی فایل RCSهای کاربران فراخوانی کند. A نباید root یا هر کاربر دیگری با اختیارات ویژه باشد. گروه‌هایی از کاربران که نسبت به یکدیگر بدگمان هستند باید از مدیران متفاوتی استفاده کنند.
  • یک نام فایل مانند B را به‌عنوان دایرکتوریِ فایل‌هایی که باید توسط کاربران اجرا شوند انتخاب کنید.
  • از کاربر A بخواهید دایرکتوری B را به‌گونه‌ای برپا کند که شامل نسخه‌هایی از ci و co باشد که روی A تنظیم setuid شده‌اند؛ این کار با کپی کردن دستورات از دایرکتوری استاندارد نصب آن‌ها D به صورت زیر انجام می‌شود:
mkdir  B
cp  D/c[io]  B
chmod  go-w,u+s  B/c[io]
•
از هر کاربر بخواهید B را به ابتدای مسیر جستجوی دستورات (search path) خود به صورت زیر اضافه کند:
PATH=B:$PATH;  export  PATH  # ordinary shell
set  path=(B  $path)  # C shell
•
از کاربر A بخواهید هر دایرکتوری RCS با نام R را با دسترسی نوشتنِ محدود به A به صورت زیر ایجاد کند:
mkdir  R
chmod  go-w  R
•
اگر می‌خواهید فقط به کاربران مشخصی اجازهٔ خواندن فایل RCSها را بدهید، آن کاربران را در یک گروه G قرار دهید و از A بخواهید دایرکتوری RCS را به شکل زیر بیشتر محافظت کند:
chgrp  G  R
chmod  g-w,o-rwx  R
  • از A بخواهید فایل RCSهای قدیمی (در صورت وجود) را درون R کپی کند تا اطمینان حاصل شود که مالک آن‌ها A است..IP • 2 فهرست دسترسیِ یک فایل RCS تعیین می‌کند چه کسی می‌تواند بازبینی‌ها را ثبت (check in) و قفل کند. فهرست دسترسی پیش‌فرض خالی است، که دسترسی ثبت را به هر کسی که بتواند فایل RCS را بخواند اعطا می‌کند. اگر می‌خواهید دسترسی ثبت را محدود کنید، از A بخواهید rcs -a را روی فایل اجرا کند؛ رجوع کنید به rcs(1). به‌ویژه، rcs -e -aA دسترسی را تنها به A محدود می‌کند.
  • از A بخواهید پیش از نخستین ثبت، هر فایل RCS جدید را با rcs -i مقداردهی اولیه کند و اگر می‌خواهید دسترسی ثبت را محدود کنید، گزینهٔ -a را نیز اضافه کند.
  • مجوزهای setuid را تنها به ci، co و rcsclean اختصاص دهید؛ آن‌ها را به rcs یا به هیچ دستور دیگری ندهید.
  • از دستورهای setuid دیگر برای فراخوانی دستورهای RCS استفاده نکنید؛ کار با setuid فریبنده‌تر و پیچیده‌تر از آن است که فکر می‌کنید!

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

نویسنده: Walter F. Tichy.
بازبینی صفحهٔ راهنما: 5.10.1؛ تاریخ انتشار: 2022-02-03.
کپی‌رایت © 2010-2022 Thien-Thi Nguyen.
کپی‌رایت © 1990, 1991, 1992, 1993, 1994, 1995 Paul Eggert.
کپی‌رایت © 1982, 1988, 1989 Walter F. Tichy.

co(1), emacs(1), ident(1), make(1), rcs(1), rcsclean(1), rcsdiff(1), rcsmerge(1), rlog(1), setuid(2), 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

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

2022-02-03 GNU RCS 5.10.1