.ds Rv 5.10.1
.ds Dt 2022-02-03
.ds i \&\s-1ISO\s0
.ds r \&\s-1RCS\s0
.ds u \&\s-1UTC\s0
.ds o فایل \*r
.if n .ds - \%--
.if t .ds - \(em
.TH CI 1 "\*(Dt" "GNU RCS \*(Rv"
.SH "نام (NAME)"
ci \- ثبت ویرایش‌های RCS
.SH "خلاصه دستور (SYNOPSIS)"
.B ci
.RI [ options ] " file " .\|.\|.
.SH "توضیحات (DESCRIPTION)"
دستور
.B ci
ویرایش‌های جدید را در فایل‌های \*r ذخیره می‌کند.
هر نام فایلی که با یک پسوند \*r مطابقت داشته باشد،
یک \*o در نظر گرفته می‌شود.
سایر فایل‌ها
به‌عنوان فایل‌های کاری حاوی ویرایش‌های جدید در نظر گرفته می‌شوند.
دستور
.B ci
محتویات هر فایل کاری را
در \*o متناظر آن قرار می‌دهد.
اگر تنها یک فایل کاری مشخص شده باشد،
.B ci
تلاش می‌کند \*o متناظر را ابتدا در یک زیردایرکتوری \*r
و سپس در دایرکتوریِ فایل کاری بیابد.
برای جزئیات بیشتر، بخش
.SM "FILE NAMING"
در زیر را ببینید.
.PP
برای کارکرد
.BR ci ،
نام کاربری فراخواننده باید در فهرست دسترسی (access list) باشد،
مگر اینکه فهرست دسترسی خالی باشد یا فراخواننده کاربر ریشه (superuser) یا مالک
فایل باشد.
برای افزودن یک ویرایش جدید به یک شاخهٔ موجود، ویرایش راس (tip revision) در
آن شاخه باید توسط فراخواننده قفل شده باشد. در غیر این صورت، تنها یک
شاخهٔ جدید را می‌توان ایجاد کرد. اگر از قفل‌گذاری غیرسخت‌گیرانه (non-strict) استفاده شود،
این محدودیت برای مالک فایل اعمال نمی‌شود
(ببینید:
.BR rcs (1)).
قفلی را که در اختیار شخص دیگری است می‌توان با دستور
.B rcs
شکست.
.PP
مگر در صورتی که گزینهٔ
.B \-f
مشخص شده باشد،
.B ci
بررسی می‌کند که آیا ویرایش ارائه‌شده برای ثبت با ویرایش پیشین تفاوت دارد یا خیر.
اگر تفاوتی نداشته باشد،
.B ci
به‌جای ایجاد ویرایش جدید، به ویرایش پیشین بازمی‌گردد (revert می‌کند).
برای بازگشت، حالت عادیِ
.B ci
فایل کاری و هرگونه قفل را حذف می‌کند؛
.B "ci\ \-l"
قفل را نگه می‌دارد و
.B "ci\ \-u"
قفل را برمی‌دارد، و سپس هر دوی آن‌ها یک فایل کاری جدید تولید می‌کنند، درست مانند اینکه
.B "co\ \-l"
یا
.B "co\ \-u"
روی ویرایش پیشین اعمال شده باشد.
هنگام بازگشت، گزینه‌های
.B \-n
و
.B \-s
روی ویرایش پیشین اعمال می‌شوند.
.PP
برای هر ویرایشی که ثبت می‌شود،
.B ci
یک پیام گزارش تغییرات (log message) درخواست می‌کند.
پیام ثبت تغییرات باید خلاصه‌ای از تغییرات باشد و باید با
پایان فایل (EOF) یا با خطی که تنها شامل
.B \&.
است پایان یابد.
اگر چند فایل با هم ثبت شوند،
.B ci
می‌پرسد که آیا از پیام گزارش قبلی مجدداً استفاده شود یا خیر.
اگر ورودی استاندارد یک ترمینال نباشد،
.B ci
از نمایش اعلان خودداری کرده
و از همان پیام گزارش برای همهٔ فایل‌ها استفاده می‌کند.
همچنین ببینید:
.BR \-m .
.PP
اگر \*o وجود نداشته باشد،
.B ci
آن را ایجاد کرده و
محتویات فایل کاری را به‌عنوان ویرایش اولیه ذخیره می‌کند
(شمارهٔ پیش‌فرض:
.BR 1.1 ).
فهرست دسترسی با مقدار خالی مقداردهی اولیه می‌شود.
به‌جای پیام گزارش،
.B ci
یک متن توصیفی درخواست می‌کند (گزینهٔ
.B \-t
در زیر را ببینید).
.PP
شمارهٔ
.I rev
برای ویرایش ثبت‌شده را می‌توان با هر یک از گزینه‌های
.BR \-f ،
.BR \-i ،
.BR \-I ،
.BR \-j ،
.BR \-k ،
.BR \-l ،
.BR \-M ،
.BR \-q ،
.BR \-r
یا
.B \-u
مشخص کرد.
.I rev
می‌تواند نمادین (symbolic)، عددی یا ترکیبی از هر دو باشد.
نام‌های نمادین در
.I rev
باید از پیش تعریف شده باشند؛
گزینه‌های
.B \-n
و
.B \-N
را برای تخصیص نام‌ها در هنگام ثبت ببینید.
اگر
.I rev
برابر با
.B $
باشد،
.B ci
شمارهٔ ویرایش را از مقادیر کلیدواژه‌ها در فایل کاری تعیین می‌کند.
.PP
اگر
.I rev
با یک نقطه آغاز شود،
شاخهٔ پیش‌فرض (معمولاً تنه یا trunk) به ابتدای آن اضافه می‌شود.
اگر
.I rev
شمارهٔ یک شاخه باشد که نقطه‌ای به دنبال آن آمده است،
آخرین ویرایش موجود روی آن شاخه استفاده خواهد شد.
.PP
اگر
.I rev
یک شمارهٔ ویرایش باشد، باید از آخرین ویرایش موجود روی شاخه‌ای که
.I rev
به آن تعلق دارد بزرگ‌تر باشد، یا اینکه باید یک شاخهٔ جدید را آغاز کند.
.PP
اگر
.I rev
به‌جای شمارهٔ ویرایش، یک شاخه باشد،
ویرایش جدید به انتهای آن شاخه افزوده می‌شود. شمارهٔ سطح (level number) با
افزایش دادن شمارهٔ ویرایش راسِ آن شاخه به دست می‌آید.
اگر
.I rev
به شاخه‌ای اشاره کند که وجود ندارد،
آن شاخه با ویرایش اولیه‌ای با شمارهٔ
.IB rev .1\f1.\fP
ایجاد می‌شود.
.br
.ne 8
.PP
اگر
.I rev
مشخص نشود،
.B ci
تلاش می‌کند شمارهٔ ویرایش جدید را از
آخرین قفل فراخواننده استخراج کند. اگر فراخواننده ویرایش راسِ یک شاخه را قفل کرده باشد،
ویرایش جدید به انتهای آن شاخه اضافه می‌شود.
شمارهٔ ویرایش جدید از طریق
افزایش دادن شمارهٔ ویرایش راس حاصل می‌شود.
اگر فراخواننده ویرایشی غیر از راس را قفل کرده باشد، یک شاخهٔ جدید از
آن ویرایش با افزایش بالاترین شمارهٔ شاخه در آن ویرایش آغاز می‌شود.
شماره‌های اولیهٔ پیش‌فرض برای شاخه و سطح برابرند با
.BR 1 .
.PP
اگر
.I rev
مشخص نشده باشد و فراخواننده هیچ قفلی نداشته باشد، اما مالک
فایل باشد و قفل‌گذاری روی حالت
.I strict
تنظیم نشده باشد،
ویرایش به شاخهٔ پیش‌فرض اضافه می‌شود
(معمولاً تنه؛ گزینهٔ
.B \-b
دستور
.BR rcs (1)
را ببینید)..PP
استثنا: در شاخهٔ اصلی (trunk)، بازبینی‌ها می‌توانند به انتها افزوده شوند، اما نمی‌توانند درج شوند.
.SH "گزینه‌ها (OPTIONS)"
.TP
.BI \-r rev
بازبینی
.IR rev
را ثبت می‌کند.
.TP
.BR \-r
گزینهٔ
.B \-r
به‌تنهایی (بدون هیچ بازبینی) معنای غیرمعمولی در
.BR ci
دارد.
در سایر دستورهای \*r، گزینهٔ
.B \-r
به‌تنهایی، جدیدترین بازبینی را روی شاخهٔ پیش‌فرض مشخص می‌کند،
اما در
.BR ci ،
گزینهٔ
.B \-r
به‌تنهایی، رفتار پیش‌فرض مبنی بر آزادسازی قفل و حذف فایل کاری را دوباره برقرار می‌کند، و برای بازنویسی و لغو گزینه‌های پیش‌فرض
.B \-l
یا
.B \-u
که توسط نام‌های مستعار پوسته یا اسکریپت‌ها تنظیم شده‌اند، به کار می‌رود.
.TP
.BR \-l [\f2rev\fP]
مانند
.BR \-r
عمل می‌کند، به جز اینکه یک
.B "co\ \-l"
اضافی برای بازبینی سپرده‌شده انجام می‌دهد. بدین ترتیب، بازبینی سپرده‌شده بلافاصله مجدداً تحویل گرفته شده و قفل می‌شود.
این گزینه برای ذخیره کردن یک بازبینی زمانی که شخص می‌خواهد پس از ثبت، به ویرایش آن ادامه دهد، مفید است.
.TP
.BR \-u [\f2rev\fP]
مانند
.BR \-l
عمل می‌کند، با این تفاوت که بازبینی سپرده‌شده قفل نمی‌شود.
این به شخص امکان می‌دهد فایل کاری را بلافاصله پس از ثبت بخواند.
.RS
.PP
گزینه‌های
.BR \-l ،
گزینهٔ تنهای
.BR \-r ،
و
.B \-u
مانعة‌الجمع هستند و بدون هیچ پیامی یکدیگر را لغو می‌کنند.
برای نمونه،
.B "ci\ \-u\ \-r"
معادل
.B "ci\ \-r"
است، زیرا
.B \-r
تنها، بر
.B \-u
اولویت داشته و آن را لغو می‌کند.
.RE
.TP
.BR \-f [\f2rev\fP]
سپرده‌گذاری را اجباری می‌کند؛ بازبینی جدید ثبت و سپرده می‌شود، حتی اگر تفاوتی با بازبینی قبلی نداشته باشد.
.TP
.BR \-k [\f2rev\fP]
فایل کاری را برای مقادیر کلیدواژه‌ها به منظور تعیین شمارهٔ بازبینی، تاریخ ایجاد، وضعیت، و نویسندهٔ آن جستجو می‌کند (نگاه کنید به
.BR co (1))،
و این مقادیر را به جای محاسبهٔ محلی، به بازبینی سپرده‌شده اختصاص می‌دهد.
همچنین یک پیام ورود (login) پیش‌فرض تولید می‌کند که به حساب کاربری فراخواننده و تاریخ واقعی ثبت اشاره دارد.
این گزینه برای توزیع نرم‌افزار کاربردی است. بازبینی‌ای که به چندین سایت مختلف ارسال می‌شود باید با گزینهٔ
.B \-k
در آن سایت‌ها ثبت شود تا شماره، تاریخ، نویسنده، و وضعیت اصلی حفظ شوند.
مقادیر کلیدواژهٔ استخراج‌شده و پیام رخدادنگاری پیش‌فرض را می‌توان با گزینه‌های
.BR \-d ،
.BR \-m ،
.BR \-s ،
.BR \-w
و هر گزینه‌ای که حامل شمارهٔ بازبینی باشد، لغو و بازنویسی کرد.
.TP
.BR \-q [\f2rev\fP]
حالت بی‌صدا؛ خروجی تشخیصی چاپ نمی‌شود.
بازبینی‌ای که تفاوتی با بازبینی پیشین نداشته باشد، سپرده نمی‌شود، مگر آنکه
.B \-f
داده شده باشد.
.TP
.BR \-i [\f2rev\fP]
ثبت اولیه؛ در صورتی که \*o از قبل وجود داشته باشد، خطا گزارش می‌کند.
این گزینه از شرایط رقابتی (race conditions) در برخی برنامه‌ها جلوگیری می‌کند.
.TP
.BR \-j [\f2rev\fP]
صرفاً ثبت می‌کند و مقداردهی اولیه انجام نمی‌دهد؛
در صورتی که \*o از قبل وجود نداشته باشد، خطا گزارش می‌کند.
.TP
.BR \-I [\f2rev\fP]
حالت تعاملی؛
از کاربر اعلان دریافت شده و سؤال پرسیده می‌شود،
حتی اگر ورودی استاندارد یک ترمینال نباشد.
.TP
.BR \-d "[\f2date\fP]"
از
.I date
برای تاریخ و زمان ثبت استفاده می‌کند.
مقدار
.I date
در قالب آزاد به‌گونه‌ای که در
.BR co (1)
توضیح داده شده، مشخص می‌شود.
این کار برای تنظیم ساختگی تاریخ ثبت، و برای
.B \-k
در صورت در دسترس نبودن تاریخ، مفید است.
اگر
.I date
خالی باشد، از زمان آخرین تغییر فایل کاری استفاده می‌شود.
.TP
.BR \-M [\f2rev\fP]
زمان تغییر را روی هر فایل کاری جدید،
برابر با تاریخ بازبینیِ دریافت‌شده قرار می‌دهد.
برای نمونه،
.BI "ci\ \-d\ \-M\ \-u" "\ f"
زمان تغییر
.IR f
را دستکاری نمی‌کند، حتی اگر محتویات
.IR f
به دلیل جایگزینی کلیدواژه‌ها تغییر کند.
از این گزینه با احتیاط استفاده کنید؛ چرا که می‌تواند
.BR make (1)
را سردرگم کند.
.TP
.BR \-m [\fP\f2msg\fP]
از رشتهٔ
.I msg
به‌عنوان پیام رخدادنگاری (log message) برای تمام بازبینی‌های ثبت‌شده استفاده می‌کند.
اگر
.I msg
حذف شود، مقدار پیش‌فرض آن "*** empty log message ***" خواهد بود.
طبق قرارداد، پیام‌های رخدادنگاری که با
.B #
آغاز می‌شوند توضیح (comment) هستند و توسط برنامه‌هایی مانند بستهٔ
.B vc
در GNU Emacs نادیده گرفته می‌شوند.
همچنین، پیام‌های رخدادنگاری که با
.BI { clumpname }
(به همراه نویسهٔ فاصله در ادامه) شروع می‌شوند، در صورت امکان برای گروه‌بندی با یکدیگر در نظر گرفته شده‌اند، حتی اگر به فایل‌های متفاوتی مرتبط باشند؛ برچسب
.BI { clumpname }
صرفاً برای دسته‌بندی استفاده می‌شود و بخشی از خودِ پیام رخدادنگاری به حساب نمی‌آید.
.TP
.BI \-n "name"
نام نمادین
.I name
را به شمارهٔ بازبینی ثبت‌شده اختصاص می‌دهد.
اگر
.I name
از قبل به شمارهٔ دیگری اختصاص یافته باشد،
.B ci
یک پیام خطا چاپ می‌کند.
.TP
.BI \-N "name"
مشابه
.BR \-n ،
با این تفاوت که انتساب قبلی
.IR name
را لغو و بازنویسی می‌کند.
.TP
.BI \-s "state"
وضعیت (state) بازبینی ثبت‌شده را روی شناسهٔ
.IR state
تنظیم می‌کند.
وضعیت پیش‌فرض
.BR Exp
است.
.TP
.BI \-t file
متن توصیفی را از محتویات فایلِ نام‌بردهٔ
.I file
درون \*o می‌نویسد و متن موجود را حذف می‌کند.
نام
.I file
نمی‌تواند با
.BR \-
شروع شود..TP
.BI \-t\- string
متن توصیفی را از
.I string
در \*o می‌نویسد و متن موجود را حذف می‌کند.
.RS
.PP
گزینهٔ
.B \-t
در هر دو شکل خود، تنها در اولین ثبت (initial checkin) اثر دارد؛
در غیر این صورت بدون هیچ هشداری نادیده گرفته می‌شود.
.PP
در اولین ثبت، اگر
.B \-t
داده نشود،
.B ci
متن را از ورودی استاندارد دریافت می‌کند،
که با پایان فایل (end-of-file) یا خطی که به تنهایی شامل
.B \&.
باشد پایان می‌یابد.
اگر تعامل با کاربر ممکن باشد، متن درخواست می‌شود؛
.BR \-I
را ببینید.
.PP
برای سازگاری رو به عقب با نسخه‌های قدیمی‌تر \*r، گزینهٔ خالی
.B \-t
نادیده گرفته می‌شود.
.RE
.TP
.B \-T
زمان تغییر (modification time) مربوط به \*o را روی زمان ویرایش جدید تنظیم می‌کند،
اگر زمان اولی پیش از دومی باشد و ویرایش جدیدی وجود داشته باشد؛
در غیر این صورت، زمان تغییر \*o حفظ می‌شود.
اگر ویرایشی را قفل کرده باشید،
.B ci
معمولاً زمان تغییر \*o را به زمان جاری به‌روزرسانی می‌کند،
زیرا قفل در \*o ذخیره می‌شود
و حذف قفل مستلزم تغییر دادن \*o است.
این امر می‌تواند به یکی از دو روش باعث شود که یک \*o جدیدتر از فایل کاری ایجاد شود:
نخست،
.B "ci\ \-M"
می‌تواند یک فایل کاری با تاریخی پیش از زمان جاری ایجاد کند؛
دوم، هنگام بازگردانی به ویرایش پیشین،
\*o می‌تواند تغییر کند در حالی که فایل کاری دست‌نخورده باقی می‌ماند.
این دو حالت می‌توانند باعث بازکامپایل شدن‌های غیرضروری ناشی از وابستگی
.BR make (1)
فایل کاری به \*o شوند.
گزینهٔ
.B \-T
با تنظیم ساختگی تاریخ \*o، از این بازکامپایل شدن جلوگیری می‌کند.
از این گزینه با احتیاط استفاده کنید؛ زیرا می‌تواند مانع بازکامپایل شود حتی زمانی که
ثبت یک فایل کاری باید بر فایل کاری دیگری که با همان \*o مرتبط است اثر بگذارد.
برای نمونه، فرض کنید زمان \*o برابر 01:00 است،
زمان فایل کاری (تغییر یافته) 02:00 است،
نسخهٔ دیگری از فایل کاری زمانی برابر 03:00 دارد،
و زمان فعلی 04:00 است.
در این صورت،
.B "ci\ \-d\ \-T"
زمان \*o را به جای 04:00 معمول روی 02:00 تنظیم می‌کند؛
این کار باعث می‌شود
.BR make (1)
(به نادرستی) تصور کند که نسخهٔ دیگر از \*o جدیدتر است.
.TP
.BI \-w "login"
از
.I login
برای فیلد نویسندهٔ (author) ویرایش ثبت‌شده استفاده می‌کند.
برای تنظیم ساختگی نام نویسنده، و برای
.B \-k
در صورتی که هیچ نویسنده‌ای در دسترس نباشد، مفید است.
.TP
.BI \-V
شماره نسخهٔ \*r را چاپ می‌کند.
.TP
.BI \-V n
نسخهٔ
.I n
از \*r را شبیه‌سازی می‌کند.
برای جزئیات به
.BR co (1)
مراجعه کنید.
.TP
.BI \-x "suffixes"
پسوندهای \*o را مشخص می‌کند.
یک پسوند غیرخالی با هر نام فایلی که به آن پسوند ختم شود مطابقت می‌کند.
یک پسوند خالی با هر نام فایلی به شکل
.BI RCS/ frag
یا
.IB frag1 /RCS/ frag2
مطابقت دارد.
گزینهٔ
.B \-x
می‌تواند فهرستی از پسوندها را که با
.B /
از یکدیگر جدا شده‌اند مشخص کند.
برای نمونه،
.B \-x,v/
دو پسوند را تعیین می‌کند:
.B ,v
و پسوند خالی.
اگر دو یا چند پسوند مشخص شده باشند،
هنگام جستجو برای یک \*o به ترتیب بررسی می‌شوند؛
نخستین پسوندی که کار کند برای آن فایل استفاده می‌شود.
اگر هیچ \*o یافت نشود اما امکان ایجاد یک \*o وجود داشته باشد،
پسوندها به ترتیب بررسی می‌شوند
تا نام \*o جدید تعیین شود.
مقدار پیش‌فرض برای
.I suffixes
به نحوهٔ نصب بستگی دارد؛ به طور معمول برای میزبان‌هایی مانند Unix که ویرگول را در نام فایل مجاز می‌دانند
.B ,v/
است،
و برای سایر میزبان‌ها خالی است (یعنی فقط پسوند خالی).
.TP
.BI \-z zone
قالب خروجی تاریخ را در جایگزینی کلیدواژه‌ها مشخص می‌کند،
و منطقهٔ زمانی پیش‌فرض را برای
.I date
در گزینهٔ
.BI \-d date
تعیین می‌کند.
.I zone
می‌تواند خالی، یک آفست عددی از \*u، یا رشتهٔ ویژهٔ
.B LT
برای زمان محلی باشد.
پیش‌فرض یک
.I zone
خالی است،
که از قالب سنتی \*r برای \*u، بدون ذکر منطقهٔ زمانی
و با اسلش‌های جداکنندهٔ بخش‌های تاریخ استفاده می‌کند؛
در غیر این صورت، زمان‌ها در قالب \*i 8601 همراه با ذکر منطقهٔ زمانی در خروجی نمایش داده می‌شوند.
برای نمونه، اگر زمان محلی ۱۱ ژانویه ۱۹۹۰، ساعت ۲۰:۰۰ به وقت استاندارد اقیانوس آرام (Pacific Standard Time)،
هشت ساعت در غرب \*u باشد،
زمان به صورت زیر در خروجی نمایش داده می‌شود:
.RS
.LP
.RS
.nf
.ta \w'\f3\-z+05:30\fP  'u +\w'\f31990-01-11 09:30:00+05:30\fP  'u
.ne 4
\f2گزینه\fP	\f2خروجی زمان\fP
\f3\-z\fP	\f31990/01/12 04:00:00\fP	\f2(پیش‌فرض)\fP
\f3\-zLT\fP	\f31990-01-11 20:00:00\-08\fP
\f3\-z+05:30\fP	\f31990-01-12 09:30:00+05:30\fP
.ta 4n +4n +4n +4n
.fi
.RE
.LP
گزینهٔ
.B \-z
بر تاریخ‌های ذخیره‌شده در \*o اثری ندارد؛
این تاریخ‌ها همواره به صورت \*u هستند..SH "نام‌گذاری فایل (FILE NAMING)"
جفت‌های \*o و فایل‌های کاری را می‌توان به سه روش مشخص کرد
(همچنین بخش مثال‌ها را ببینید).
.PP
۱) هم \*o و هم فایل کاری مشخص شده باشند.
نام \*o به صورت
.IB frag1 / workfileX
و نام فایل کاری به شکل
.IB frag2 / workfile
است که در آن
.IB frag1 /
و
.IB frag2 /
نام‌های فایل (احتمالاً متفاوت یا خالی) هستند،
.I workfile
یک نام فایل است، و
.I X
یک پسوند \*r است.
اگر
.I X
خالی باشد،
.IB frag1 /
باید با
.B RCS/
شروع شود یا شامل
.BR /RCS/ .
باشد.
.PP
۲) تنها \*o مشخص شده باشد.
در این صورت فایل کاری در دایرکتوری جاری ایجاد می‌شود و نام آن با حذف
.IB frag1 /
و پسوند
.IR X .
از نام \*o به دست می‌آید.
.PP
۳) تنها فایل کاری مشخص شده باشد.
در این حالت،
.B ci
هر پسوند \*r مانند
.I X
را به نوبت بررسی می‌کند و به دنبال یک \*o به شکل
.IB frag2 /RCS/ workfileX
یا (در صورتی که مورد اول یافت نشود و
.I X
غیرخالی باشد) به صورت
.IB frag2 / workfileX.
می‌گردد.
.PP
اگر در ۱) و ۲) فایل \*o بدون نام فایل مشخص شده باشد،
.B ci
ابتدا در دایرکتوری
.B ./RCS
و سپس در دایرکتوری جاری به دنبال \*o می‌گردد.
.PP
در صورتی که تلاش برای باز کردن یک \*o به دلیلی غیرمعمول با شکست مواجه شود، حتی اگر نام آن \*o فقط یکی از چندین حالت ممکن باشد،
.B ci
خطا گزارش می‌دهد.
برای نمونه، به منظور جلوگیری از استفاده از دستورهای \*r در یک دایرکتوری مانند
.IR d ,
یک فایل معمولی به نام
.IB d /RCS
ایجاد کنید تا تلاش‌های ناخواسته برای استفاده از دستورهای \*r در
.I d
با شکست مواجه شود، چرا که
.IB d /RCS
یک دایرکتوری نیست.
.SH "مثال‌ها (EXAMPLES)"
فرض کنید
.B ,v
یک پسوند \*r است و دایرکتوری جاری شامل زیردایرکتوری
.B RCS
به همراه یک \*o به نام
.BR io.c,v .
باشد.
در این صورت، هر یک از دستورهای زیر یک نسخه از
.B io.c
را به عنوان آخرین نگارش در
.B RCS/io.c,v
ثبت (check in) کرده و
.BR io.c .
را حذف می‌کند.
.LP
.RS
.nf
.ft 3
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;
.ft
.fi
.RE
.PP
در مقابل، فرض کنید پسوند خالی یک پسوند \*r باشد و دایرکتوری جاری شامل زیردایرکتوری
.B RCS
با یک \*o به نام
.BR io.c .
باشد.
در این حالت، هر یک از دستورهای زیر یک نگارش جدید را ثبت (check in) می‌کند.
.LP
.RS
.nf
.ft 3
ci  io.c;    ci  RCS/io.c;
ci  io.c  RCS/io.c;
ci  RCS/io.c  io.c;
.ft
.fi
.RE.SH "حالت‌های فایل (FILE MODES)"
یک \*o ایجاد شده توسط
.B ci
مجوزهای خواندن و اجرا را از فایل کاری به ارث می‌برد. اگر \*o از قبل وجود داشته باشد،
.B ci
مجوزهای خواندن و اجرای آن را حفظ می‌کند.
.B ci
همواره تمام مجوزهای نوشتن را در \*oها خاموش می‌کند.
.SH "فایل‌ها (FILES)"
فایل‌های موقت در دایرکتوری حاوی فایل کاری، و همچنین در دایرکتوری موقت ایجاد می‌شوند (ببینید
.B \s-1TMPDIR\s0
در بخش
.BR \s-1ENVIRONMENT\s0 ).
یک یا چند فایل سمافور (semaphore) در دایرکتوری حاوی \*o ایجاد می‌شوند.
با یک پسوند غیرخالی، نام‌های سمافور با نخستین نویسهٔ پسوند آغاز می‌شوند؛ بنابراین، پسوندی را مشخص نکنید که نویسهٔ نخست آن بتواند همانند نویسهٔ اول نام یک فایل کاری باشد.
با یک پسوند خالی، نام‌های سمافور به
.B _
ختم می‌شوند، بنابراین نام‌های فایل کاری نباید به
.BR _
ختم شوند.
.PP
دستور
.B ci
هرگز یک \*o یا فایل کاری را مستقیماً تغییر نمی‌دهد.
به‌طور معمول،
.B ci
پیوند فایل را حذف کرده (unlink) و یک فایل جدید می‌سازد؛
اما به‌جای شکستن زنجیره‌ای از یک یا چند پیوند نمادین به یک \*o،
در عوض پیوند فایل مقصد را حذف می‌کند.
بنابراین،
.B ci
هرگونه پیوند سخت یا نمادین را به هر فایل کاری که تغییر می‌دهد می‌شکند؛
و پیوندهای سخت به \*oها بی‌اثر می‌شوند،
اما پیوندهای نمادین به \*oها حفظ می‌گردند.
.PP
کاربر مؤثر (effective user) باید بتواند دایرکتوری حاوی \*o را جستجو کرده (پیمایش کند) و در آن بنویسد.
به‌طور معمول، کاربر واقعی (real user) باید بتواند فایل‌های کاری و \*r را بخواند
و دایرکتوری حاوی فایل کاری را جستجو کرده و در آن بنویسد؛
با این حال، برخی از میزبان‌های قدیمی‌تر نمی‌توانند به‌آسانی میان کاربران واقعی و مؤثر جابه‌جا شوند،
بنابراین در این میزبان‌ها از کاربر مؤثر برای تمام دسترسی‌ها استفاده می‌شود.
کاربر مؤثر با کاربر واقعی یکسان است
مگر اینکه نسخه‌های شما از
.B ci
و
.B co
دارای امتیازات setuid باشند.
همان‌طور که در بخش بعدی شرح داده شده است،
این امتیازات امنیت بیشتری به همراه دارند اگر
کاربر مؤثر مالک تمام \*oها و دایرکتوری‌ها باشد،
و تنها در صورتی که فقط کاربر مؤثر بتواند در دایرکتوری‌های \*r بنویسد.
.PP
کاربران می‌توانند دسترسی به \*oها را با تنظیم مجوزهای دایرکتوری حاوی فایل‌ها کنترل کنند؛ فقط کاربرانی با دسترسی نوشتن در دایرکتوری می‌توانند از دستورات \*r برای تغییر \*oهای آن استفاده نمایند.
به‌عنوان مثال، در میزبان‌هایی که به کاربر اجازه می‌دهند متعلق به چندین گروه باشد،
می‌توان دایرکتوری‌های \*r متعلق به یک گروه را فقط برای همان گروه قابل نوشتن کرد.
این رویکرد برای پروژه‌های غیررسمی کافی است،
اما به این معنی است که هر عضو گروه می‌تواند به‌طور دلخواه \*oهای گروه را تغییر دهد
و حتی می‌تواند آن‌ها را به‌طور کامل حذف کند.
از این رو پروژه‌های رسمی‌تر گاهی میان مدیر سامانهٔ \*r،
که می‌تواند بنا به صلاحدید \*oها را تغییر دهد، و سایر اعضای پروژه
که می‌توانند بازبینی‌های (revisions) جدید را ثبت کنند (check in) اما مجاز به تغییر دیگری در \*oها نیستند، تمایز قائل می‌شوند.
.SH "استفاده از SETUID (SETUID USE)"
برای جلوگیری از حذف بازبینی‌ها توسط هر شخصی به جز مدیر سامانهٔ \*r،
یک گروه از کاربران می‌توانند به شیوهٔ زیر از امتیازات setuid بهره ببرند:
.nr n \w'\(bu'+2n-1/1n
.ds n \nn
.if \n(.g .if r an-tag-sep .ds n \w'\(bu'u+\n[an-tag-sep]u
.IP \(bu \*n
بررسی کنید که میزبان از کاربرد setuid برای \*r پشتیبانی می‌کند یا خیر.
در صورت وجود هرگونه تردید با یک کارشناس معتمد مشورت کنید.
بهترین وضعیت این است که فراخوان سیستمی
.B seteuid
همان‌گونه که در استاندارد Posix 1003.1a Draft 5 شرح داده شده کار کند،
زیرا \*r می‌تواند به‌راحتی میان کاربران واقعی و مؤثر جابه‌جا شود، حتی اگر کاربر واقعی
.BR root
باشد. در غیر این صورت، انتخاب مناسب بعدی این است که فراخوان سیستمی
.B setuid
از setuid ذخیره‌شده پشتیبانی کند
(رفتار {\s-1_POSIX_SAVED_IDS\s0} در Posix 1003.1-1990)؛
این حالت تنها در صورتی با شکست مواجه می‌شود که کاربر واقعی یا مؤثر
.BR root
باشد. چنانچه \*r هرگونه خطایی در setuid شناسایی کند، بی‌درنگ متوقف می‌شود.
.IP \(bu \nn
یک کاربر
.I A
را انتخاب کنید تا به‌عنوان مدیر سامانهٔ \*r برای این گروه از کاربران عمل کند.
تنها
.I A
می‌تواند دستور
.B rcs
را بر روی \*oهای کاربران فراخوانی کند.
.I A
نباید
.B root
یا هر کاربر دیگری با اختیارات ویژه باشد.
گروه‌هایی از کاربران که نسبت به یکدیگر بدگمان هستند باید از مدیران متفاوتی استفاده کنند.
.IP \(bu \nn
یک نام فایل مانند
.I B
را به‌عنوان دایرکتوریِ فایل‌هایی که باید توسط کاربران اجرا شوند انتخاب کنید.
.IP \(bu \nn
از کاربر
.I A
بخواهید دایرکتوری
.I B
را به‌گونه‌ای برپا کند که شامل نسخه‌هایی از
.B ci
و
.B co
باشد که روی
.I A
تنظیم setuid شده‌اند؛ این کار با کپی کردن دستورات از دایرکتوری استاندارد نصب آن‌ها
.I D
به صورت زیر انجام می‌شود:
.LP
.RS
.nf
.ne 3
\f3mkdir\fP  \f2B\fP
\f3cp\fP  \f2D\fP\^\f3/c[io]\fP  \f2B\fP
\f3chmod  go\-w,u+s\fP  \f2B\fP\f3/c[io]\fP
.fi
.RE
.IP \(bu \nn
از هر کاربر بخواهید
.I B
را به ابتدای مسیر جستجوی دستورات (search path) خود به صورت زیر اضافه کند:
.LP
.RS
.nf
.ne 2
\f3PATH=\fP\f2B\fP\f3:$PATH;  export  PATH\fP  # ordinary shell
\f3set  path=(\fP\f2B\fP  \f3$path)\fP  # C shell
.fi
.RE
.IP \(bu \nn
از کاربر
.I A
بخواهید هر دایرکتوری \*r با نام
.I R
را با دسترسی نوشتنِ محدود به
.I A
به صورت زیر ایجاد کند:
.LP
.RS
.nf
.ne 2
\f3mkdir\fP  \f2R\fP
\f3chmod  go\-w\fP  \f2R\fP
.fi
.RE
.IP \(bu \nn
اگر می‌خواهید فقط به کاربران مشخصی اجازهٔ خواندن \*oها را بدهید،
آن کاربران را در یک گروه
.IR G
قرار دهید و از
.I A
بخواهید دایرکتوری \*r را به شکل زیر بیشتر محافظت کند:
.LP
.RS
.nf
.ne 2
\f3chgrp\fP  \f2G  R\fP
\f3chmod  g\-w,o\-rwx\fP  \f2R\fP
.fi
.RE
.IP \(bu \nn
از
.I A
بخواهید \*oهای قدیمی (در صورت وجود) را درون
.IR R
کپی کند تا اطمینان حاصل شود که مالک آن‌ها
.I A
است..IP \(bu \nn
فهرست دسترسیِ یک \*o تعیین می‌کند چه کسی می‌تواند بازبینی‌ها را ثبت (check in) و قفل کند.
فهرست دسترسی پیش‌فرض خالی است،
که دسترسی ثبت را به هر کسی که بتواند \*o را بخواند اعطا می‌کند.
اگر می‌خواهید دسترسی ثبت را محدود کنید،
از
.I A
بخواهید
.B "rcs\ \-a"
را روی فایل اجرا کند؛ رجوع کنید به
.BR rcs (1).
به‌ویژه،
.BI "rcs\ \-e\ \-a" A
دسترسی را تنها به
.I A
محدود می‌کند.
.IP \(bu \nn
از
.I A
بخواهید پیش از نخستین ثبت، هر \*o جدید را با
.B "rcs\ \-i"
مقداردهی اولیه کند و اگر می‌خواهید دسترسی ثبت را محدود کنید، گزینهٔ
.B \-a
را نیز اضافه کند.
.IP \(bu \nn
مجوزهای setuid را تنها به
.BR ci ،
.BR co
و
.BR rcsclean
اختصاص دهید؛
آن‌ها را به
.B rcs
یا به هیچ دستور دیگری ندهید.
.IP \(bu \nn
از دستورهای setuid دیگر برای فراخوانی دستورهای \*r استفاده نکنید؛
کار با setuid فریبنده‌تر و پیچیده‌تر از آن است که فکر می‌کنید!
.SH "محیط (ENVIRONMENT)"
.TP
.B \s-1RCSINIT\s0
گزینه‌هایی که با فاصله از یکدیگر جدا شده و به ابتدای فهرست آرگومان‌ها افزوده می‌شوند.
یک بک‌اسلش فاصله‌های درون یک گزینه را گریزدهی (escape) می‌کند.
گزینه‌های
.B \s-1RCSINIT\s0
به ابتدای فهرست آرگومان‌های بیشتر دستورهای \*r اضافه می‌شوند.
گزینه‌های مفید
.B \s-1RCSINIT\s0
شامل
.BR \-q ،
.BR \-V ،
.BR \-x
و
.BR \-z
هستند.
.TP
.B \s-1RCS_MEM_LIMIT\s0
به‌طور معمول برای افزایش سرعت، اگر اندازهٔ \*o کمتر از
.IR memory-limit
باشد (که در حال حاضر پیش‌فرض آن «unlimited» است)، دستورها آن را در حافظه نگاشت (memory map) کرده یا درون حافظه کپی می‌کنند.
در غیر این صورت (یا اگر روش‌های سریعِ اولیه با شکست مواجه شوند)،
دستورها به استفاده از روال‌های ورودی/خروجی استاندارد بازمی‌گردند.
می‌توانید با تنظیم
.B \s-1RCS_MEM_LIMIT\s0
روی یک مقدار عددی
.IR lim
(برحسب کیلوبایت) این محدودیت حافظه را تنظیم کنید.
مقدار خالی بدون اعلان نادیده گرفته می‌شود.
به‌عنوان یک اثر جانبی، تعیین
.B \s-1RCS_MEM_LIMIT\s0
مانع از بازگشت به روال‌های کندتر می‌شود.
.TP
.B \s-1TMPDIR\s0
نام دایرکتوری موقت.
اگر تنظیم نشده باشد، در عوض متغیرهای محیطی
.B \s-1TMP\s0
و
.B \s-1TEMP\s0
بررسی می‌شوند و نخستین مقدار یافت‌شده لحاظ می‌شود؛
اگر هیچ‌کدام از آن‌ها تنظیم نشده باشند،
یک پیش‌فرض وابسته به میزبان استفاده خواهد شد که معمولاً
.BR /tmp
است..SH "خطاها (DIAGNOSTICS)"
برای هر بازبینی،
.B ci
\*o، فایل کاری، و شمارهٔ هر دو بازبینیِ ثبت‌شده و بازبینی پیشین را چاپ می‌کند.
وضعیت خروج صفر است اگر و تنها اگر همهٔ عملیات‌ها موفقیت‌آمیز بوده باشند.
.ds EY 1990, 1991, 1992, 1993, 1994, 1995
.SH "شناسایی (IDENTIFICATION)"
نویسنده: Walter F. Tichy.
.br
بازبینی صفحهٔ راهنما: \*(Rv؛ تاریخ انتشار: \*(Dt.
.br
کپی‌رایت \(co 2010-2022 Thien-Thi Nguyen.
.br
کپی‌رایت \(co \*(EY Paul Eggert.
.br
کپی‌رایت \(co 1982, 1988, 1989 Walter F. Tichy.
.br
.SH "همچنین ببینید (SEE ALSO)"
.BR co (1),
.BR emacs (1),
.BR ident (1),
.BR make (1),
.BR rcs (1),
.BR rcsclean (1),
.BR rcsdiff (1),
.BR rcsmerge (1),
.BR rlog (1),
.BR setuid (2),
.BR rcsfile (5).
.PP
.PP
Walter F. Tichy,
\*r\*-A System for Version Control,
.I "Software\*-Practice & Experience"
.BR 15 ,
7 (July 1985), 637-654.
.PP
مستندات کامل برای \*r در قالب یک کتابچهٔ راهنمای Texinfo نگهداری می‌شود.
اگر برنامه‌های
.BR info (1)
و \*r به‌درستی در سیستم شما نصب شده باشند، دستور
.IP
.B info rcs
.PP
باید دسترسی به راهنمای کامل را برای شما فراهم کند.
علاوه بر این، وب‌سایت \*r در:
.IP
.B http://www.gnu.org/software/rcs
.PP
شامل اخبار و پیوندهایی به آخرین انتشار، پایگاه توسعه و غیره است.