GIT-CVSSERVER(1) Git Manual GIT-CVSSERVER(1)

git-cvsserver - یک شبیه‌ساز سرور CVS برای گیت

SSH:

export CVS_SERVER="git cvsserver"
cvs -d :ext:user@server/path/repo.git co <HEAD_name>

pserver (/etc/inetd.conf):

cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver

کاربرد (Usage):

git-cvsserver [<options>] [pserver|server] [<directory> ...]

این برنامه یک لایهٔ شبیه‌ساز CVS برای گیت (Git) است.

این ابزار قابلیت‌های فراوانی دارد؛ با این حال، همهٔ متدها پیاده‌سازی نشده‌اند و برای متدهای پیاده‌سازی‌شده نیز تمام سوییچ‌ها در دسترس نیستند.

آزمایش‌ها با استفاده از کلاینت خط فرمانی CVS و افزونهٔ CVS اکلیپس (Eclipse) انجام شده است. بیشتر قابلیت‌ها با هر دوی این کلاینت‌ها به خوبی کار می‌کنند.

تمام این گزینه‌ها مسلماً تنها در صورتی منطقی هستند که از سمت سرور اعمال شوند. آن‌ها طوری پیاده‌سازی شده‌اند که تا جای ممکن به گزینه‌های git-daemon(1) شباهت داشته باشند.

--base-path <path>

افزودن path به ابتدای CVSROOT درخواستی.

--strict-paths

عدم اجازه برای پیمایش بازگشتی به زیردایرکتوری‌ها.

--export-all

عدم بررسی gitcvs.enabled در فایل پیکربندی. در صورت تمایل به استفاده از این گزینه، باید فهرستی از دایرکتوری‌های مجاز را نیز مشخص کنید (پایین را ببینید).

-V, --version

چاپ اطلاعات نسخه و خروج.

-h, -H, --help

چاپ راهنمای استفاده و خروج.

<directory>

آرگومان‌های باقیمانده، فهرستی از دایرکتوری‌ها را ارائه می‌دهند. اگر هیچ دایرکتوری مشخص نشود، همه مجاز خواهند بود. مخازن موجود در این دایرکتوری‌ها همچنان نیازمند گزینهٔ پیکربندی gitcvs.enabled هستند، مگر اینکه --export-all مشخص شده باشد.

کلاینت‌های CVS قادر به برچسب‌گذاری (tag)، ایجاد شاخه (branch) یا انجام ادغام‌های گیت (Git merge) نیستند.

دستور git-cvsserver شاخه‌های گیت را به ماژول‌های CVS نگاشت می‌کند. این رفتار با انتظاری که اکثر کاربران CVS دارند بسیار متفاوت است، زیرا در CVS ماژول‌ها معمولاً نشان‌دهندهٔ یک یا چند دایرکتوری هستند.

1.اگر می‌خواهید دسترسی CVS را از طریق pserver ارائه دهید، خطی مانند زیر را به /etc/inetd.conf اضافه کنید: 
cvspserver stream tcp nowait nobody git-cvsserver pserver

نکته: برخی از سرورهای inetd به شما اجازه می‌دهند نام فایل اجرایی را مستقل از مقدار argv[0] (یعنی نامی که برنامه فرض می‌کند با آن اجرا شده است) مشخص کنید. در این حالت خط صحیح در /etc/inetd.conf به این صورت خواهد بود:

cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver

به‌طور پیش‌فرض تنها دسترسی ناشناس (anonymous) توسط pserver ارائه می‌شود. برای کامیت کردن باید حساب‌های کاربری pserver بسازید؛ کافی است تنظیم gitcvs.authdb را به فایل پیکربندی مخازنی که می‌خواهید cvsserver اجازهٔ نوشتن در آن‌ها را بدهد اضافه کنید، برای مثال:

[gitcvs]
     authdb = /etc/cvsserver/passwd

قالب این فایل‌ها به صورت نام کاربری و به دنبال آن گذرواژهٔ رمزگذاری‌شده است، برای مثال:

myuser:sqkNi8zPf01HI
myuser:$1$9K7FzU28$VfF6EoPYCJEYcVQwATgOP/
myuser:$5$.NqmNH1vwfzGpV8B$znZIcumu1tNLATgV2l6e1/mY8RzhUDHMOaVOeL1cxV3

می‌توانید از ابزار htpasswd که همراه آپاچی ارائه می‌شود برای ایجاد این فایل‌ها استفاده کنید، اما فقط با گزینهٔ -d (یا -B در صورتی که سیستم شما از آن پشتیبانی می‌کند).

ترجیحاً از ابزار اختصاصی پلتفرم خود برای مدیریت و ایجاد هش گذرواژه استفاده کنید (مانند mkpasswd در لینوکس، encrypt در OpenBSD یا pwhash در NetBSD) و آن را در محل مناسب قرار دهید.

سپس گذرواژهٔ خود را از طریق روش pserver ارائه دهید، برای مثال:

cvs -d:pserver:someuser:somepassword@server:/path/repo.git co <HEAD_name>

برای دسترسی از طریق SSH، نیازی به پیکربندی خاصی به‌جز وجود ابزارهای گیت در PATH نیست. اگر کلاینت‌هایی دارید که متغیر محیطی CVS_SERVER را نمی‌پذیرند، می‌توانید نام git-cvsserver را به cvs تغییر دهید.

نکته: نسخه‌های جدیدتر CVS (نسخهٔ 1.12.11 یا بالاتر) از تعیین مستقیم CVS_SERVER در CVSROOT نیز پشتیبانی می‌کنند، مانند:

cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name>

این مزیت را دارد که در فایل‌های CVS/Root شما ذخیره می‌شود و نیازی نیست نگران تنظیم همیشگی متغیر محیطی مناسب باشید. کاربران SSH که به git-shell محدود شده‌اند نیازی به بازنویسی پیش‌فرض با CVS_SERVER ندارند (و نباید این کار را بکنند)، زیرا git-shell متوجه می‌شود که cvs به معنای git-cvsserver است و بهتر تظاهر می‌کند که طرف دیگر کلاینت، یک cvs واقعی را اجرا می‌کند.

2.برای هر مخزنی که می‌خواهید از طریق CVS قابل دسترسی باشد، باید فایل config را در آن مخزن ویرایش کرده و بخش زیر را اضافه کنید: 
[gitcvs]
     enabled=1
     # اختیاری برای اشکال‌زدایی
     logFile=/path/to/logfile

نکته: باید اطمینان حاصل کنید هر کاربری که قرار است git-cvsserver را فراخوانی کند، دسترسی نوشتن به فایل لاگ و پایگاه‌داده را داشته باشد (بخش «پایگاه‌داده پشتیبان» را ببینید). اگر می‌خواهید دسترسی نوشتن از طریق SSH ارائه دهید، کاربران مسلماً به دسترسی نوشتن در خود مخزن گیت نیز نیاز دارند.

همچنین برای کارکرد صحیح cvs commit باید اطمینان یابید که هر مخزن «خام» (bare - بدون فایل ایندکس گیت) باشد. به gitcvs-migration(7) مراجعه کنید.

تمام متغیرهای پیکربندی می‌توانند برای یک روش دسترسی خاص نیز بازنویسی شوند. نام‌های معتبر روش‌ها عبارتند از "ext" (برای دسترسی SSH) و "pserver". نمونهٔ پیکربندی زیر دسترسی pserver را غیرفعال کرده در حالی که دسترسی از طریق SSH را همچنان مجاز نگه می‌دارد:

[gitcvs]
     enabled=0
[gitcvs "ext"]
     enabled=1
3.اگر CVSROOT/CVS_SERVER را مستقیماً در دستور checkout مشخص نکرده‌اید تا به‌طور خودکار در فایل‌های CVS/Root شما ذخیره شود، باید آن‌ها را به‌صراحت در محیط خود تنظیم کنید. CVSROOT باید طبق روال معمول تنظیم شود، اما دایرکتوری باید به مخزن گیت مناسب اشاره کند. همانند بالا، برای کلاینت‌های SSH که به git-shell محدود نشده‌اند، متغیر CVS_SERVER باید روی git-cvsserver تنظیم شود. 
export CVSROOT=:ext:user@server:/var/git/project.git
export CVS_SERVER="git cvsserver"
4.برای کلاینت‌های SSH که اقدام به کامیت می‌کنند، اطمینان حاصل کنید که فایل‌های .ssh/environment در سمت سرور (یا .bashrc و غیره، بسته به شل خاص آن‌ها) مقادیر مناسبی را برای GIT_AUTHOR_NAME، GIT_AUTHOR_EMAIL، GIT_COMMITTER_NAME و GIT_COMMITTER_EMAIL صادر (export) کنند. برای کلاینت‌های SSH که شل ورود آن‌ها bash است، فایل .bashrc می‌تواند جایگزین معقولی باشد.
5.اکنون کلاینت‌ها باید بتوانند پروژه را checkout کنند. از نام module در CVS برای مشخص کردن اینکه کدام head گیت را می‌خواهید دریافت کنید استفاده نمایید. این کار همچنین نام دایرکتوری جدید دریافت‌شده را تعیین می‌کند، مگر اینکه با -d <dir-name> نام دیگری مشخص کنید. برای مثال، دستور زیر شاخهٔ master را در دایرکتوری project-master دریافت می‌کند: 
cvs co -d project-master master

دستور git-cvsserver برای هر شاخه/head گیت (یعنی ماژول CVS) از یک پایگاه‌داده برای ذخیرهٔ اطلاعات مخزن استفاده می‌کند تا شماره‌های بازنگری CVS پایدار بمانند. این پایگاه‌داده باید پس از هر کامیت به‌روزرسانی شود (یعنی در آن نوشته شود).

اگر کامیت مستقیماً با استفاده از git انجام شود (برخلاف استفاده از git-cvsserver)، به‌روزرسانی باید در دسترسی بعدی به مخزن توسط git-cvsserver، مستقل از روش دسترسی و عملیات درخواستی، صورت پذیرد.

این بدان معناست که حتی اگر فقط دسترسی خواندن ارائه دهید (مثلاً با استفاده از روش pserver)، git-cvsserver باید دسترسی نوشتن به پایگاه‌داده را داشته باشد تا عملکرد قابل اعتمادی ارائه دهد (در غیر این صورت باید اطمینان حاصل کنید که پایگاه‌داده در هر بار اجرای git-cvsserver کاملاً به‌روز باشد).

به‌طور پیش‌فرض از پایگاه‌داده‌های SQLite در دایرکتوری گیت با نام gitcvs.<module-name>.sqlite استفاده می‌شود. توجه داشته باشید که بک‌اند SQLite هنگام نوشتن، فایل‌های موقتی در همان دایرکتوری فایل پایگاه‌داده ایجاد می‌کند؛ بنابراین ممکن است تنها اعطای دسترسی نوشتن به فایل پایگاه‌داده برای کاربرانی که از git-cvsserver استفاده می‌کنند کافی نباشد و نیاز به اعطای دسترسی نوشتن به دایرکتوری نیز داشته باشند.

پایگاه‌داده پس از تغییر شاخه‌ای که ردیابی می‌کند، نمی‌تواند به‌طور قابل اعتماد در یک فرم سازگار بازسازی شود. مثال: برای شاخه‌های ادغام‌شده، git-cvsserver تنها یک شاخه از توسعه را ردیابی می‌کند، و پس از یک git merge ممکن است پایگاه‌داده‌ای که به‌صورت تدریجی به‌روزرسانی شده، شاخهٔ متفاوتی را نسبت به پایگاه‌داده‌ای که از ابتدا بازسازی شده ردیابی کند و این امر باعث ناسازگاری شماره‌های بازنگری CVS شود. دستور git-cvsserver هیچ راهی برای آگاهی از این موضوع ندارد که اگر پیش از ادغام به‌طور تدریجی اجرا شده بود کدام شاخه را انتخاب می‌کرد. بنابراین اگر مجبور به بازسازی کامل یا جزئی (از یک پشتیبان قدیمی) پایگاه‌داده شدید، باید نسبت به سندباکس‌های موجود CVS محتاط باشید.

می‌توانید بک‌اند پایگاه‌داده را با متغیرهای پیکربندی زیر تنظیم کنید:

دستور git-cvsserver از ماژول DBI در پرل استفاده می‌کند. لطفاً در صورت تغییر این متغیرها مستندات آن را نیز بخوانید، به‌ویژه در مورد DBI->connect().

gitcvs.dbName

نام پایگاه‌داده. معنای دقیق آن به درایور پایگاه‌دادهٔ انتخابی بستگی دارد؛ برای SQLite این یک نام فایل است. از جایگزینی متغیر پشتیبانی می‌کند (پایین را ببینید). نباید حاوی نقطه ویرگول (;) باشد. پیش‌فرض: %Ggitcvs.%m.sqlite

gitcvs.dbDriver

درایور DBI مورد استفاده. می‌توانید هر درایور موجودی را برای این منظور در اینجا مشخص کنید، اما ممکن است کار نکند. دستور cvsserver با DBD::SQLite آزمایش شده، گزارش شده که با DBD::Pg کار می‌کند، و گزارش شده که با DBD::mysql کار نمی‌کند. لطفاً این مورد را یک قابلیت آزمایشی در نظر بگیرید. نباید حاوی دونقطه (:) باشد. پیش‌فرض: SQLite

gitcvs.dbuser

کاربر پایگاه‌داده. تنها در صورت تنظیم dbDriver مفید است، زیرا SQLite مفهومی از کاربر پایگاه‌داده ندارد. از جایگزینی متغیر پشتیبانی می‌کند (پایین را ببینید).

gitcvs.dbPass

گذرواژهٔ پایگاه‌داده. تنها در صورت تنظیم dbDriver مفید است، زیرا SQLite مفهومی از گذرواژهٔ پایگاه‌داده ندارد.

gitcvs.dbTableNamePrefix

پیشوند نام جداول پایگاه‌داده. از جایگزینی متغیر پشتیبانی می‌کند (پایین را ببینید). هر نویسهٔ غیرالفبایی با زیرخط (_) جایگزین خواهد شد.

تمام متغیرها می‌توانند بر اساس هر روش دسترسی نیز تنظیم شوند، بالا را ببینید.

جایگزینی متغیرها

در dbDriver و dbUser می‌توانید از متغیرهای زیر استفاده کنید:

%G

نام دایرکتوری گیت

%g

نام دایرکتوری گیت، که در آن تمام نویسه‌ها به جز حروف و ارقام، . و - با _ جایگزین شده‌اند (این کار در صورت تمایل، استفاده از نام دایرکتوری را در یک نام فایل آسان‌تر می‌کند)

%m

نام ماژول CVS / شاخهٔ (head) گیت

%a

روش دسترسی (یکی از مقادیر "ext" یا "pserver")

%u

نام کاربری که git-cvsserver را اجرا می‌کند. اگر نامی قابل تشخیص نباشد، شناسهٔ عددی کاربر (uid) استفاده می‌شود.

این متغیرها در برخی شرایط نیاز به گزینه‌های خط فرمان را برطرف می‌کنند و استفادهٔ محدودشدهٔ آسان‌تر را از طریق git-shell ممکن می‌سازند.

GIT_CVSSERVER_BASE_PATH

این متغیر جایگزین آرگومان --base-path می‌شود.

GIT_CVSSERVER_ROOT

این متغیر یک دایرکتوری واحد را مشخص می‌کند و جایگزین فهرست آرگومان‌های <directory>... می‌شود. مخزن همچنان به گزینهٔ پیکربندی gitcvs.enabled نیاز دارد، مگر اینکه --export-all مشخص شده باشد.

هنگامی که این متغیرهای محیطی تنظیم شده باشند، آرگومان‌های خط فرمان متناظر آن‌ها نباید استفاده شوند.

برای انجام یک دریافت (checkout) با کلاینت CVS اکلیپس:

1.گزینهٔ "Create a new project → From CVS checkout" را انتخاب کنید.
2.یک مکان جدید ایجاد کنید. برای جزئیات نحوهٔ انتخاب پروتکل مناسب، نکات زیر را ببینید.
3.ماژول‌های موجود (modules) را مرور کنید. این کار فهرستی از شاخه‌ها/headهای موجود در مخزن را به شما می‌دهد. از آنجا قادر به مرور درخت دایرکتوری نخواهید بود، بلکه فقط headها نمایش داده می‌شوند.
4.هنگامی که پرسیده شد کدام شاخه/برچسب checkout شود، HEAD را انتخاب کنید. تیک گزینهٔ "launch commit wizard" را بردارید تا از کامیت شدن فایل .project جلوگیری شود.

نکات پروتکل: اگر از دسترسی ناشناس از طریق pserver استفاده می‌کنید، همان را انتخاب نمایید. کسانی که از دسترسی SSH استفاده می‌کنند باید پروتکل ext را انتخاب کرده و دسترسی ext را در بخش Preferences→Team→CVS→ExtConnection پیکربندی کنند. مقدار CVS_SERVER را روی "git cvsserver" تنظیم کنید. توجه داشته باشید که هنگام استفاده از ext، پشتیبانی از گذرواژه مناسب نیست؛ قطعاً می‌خواهید کلیدهای SSH را راه‌اندازی کرده باشید.

همچنین می‌توانید از پروتکل غیر استاندارد extssh که اکلیپس ارائه می‌دهد استفاده کنید. در این حالت CVS_SERVER نادیده گرفته می‌شود و باید ابزار cvs را روی سرور با git-cvsserver جایگزین کنید یا .bashrc خود را طوری تغییر دهید که اجرای cvs عملاً git-cvsserver را فراخوانی کند.

•برنامهٔ CVS نسخهٔ 1.12.9 در دبیان (Debian)
•برنامهٔ CVS نسخهٔ 1.11.17 در مک‌او‌اس (MacOSX - از بستهٔ Fink)
•اکلیپس نسخه‌های 3.0 و 3.1.2 در مک‌او‌اس (نکات کلاینت CVS در اکلیپس را ببینید)
•برنامهٔ TortoiseCVS

تمام عملیات‌های مورد نیاز برای استفادهٔ عادی پشتیبانی می‌شوند، از جمله checkout، diff، status، update، log، add، remove و commit.

بیشتر آرگومان‌های دستور CVS که برچسب‌ها یا شماره‌های بازنگری CVS را می‌خوانند (معمولاً -r) کار می‌کنند، و همچنین از هر refspec گیت (برچسب، شاخه، شناسهٔ کامیت و غیره) پشتیبانی می‌نمایند. با این حال، شماره‌های بازنگری CVS برای شاخه‌های غیرپیش‌فرض به خوبی شبیه‌سازی نمی‌شوند و دستور cvs log برچسب‌ها یا شاخه‌ها را اصلاً نمایش نمی‌دهد. (شماره‌های بازنگری CVS برای شاخه‌های غیر اصلی ظاهراً شبیه شماره‌های بازنگری CVS هستند، اما در واقع مستقیماً یک شناسهٔ کامیت گیت را کدگذاری می‌کنند، نه اینکه نشان‌دهندهٔ تعداد بازنگری‌ها از زمان انشعاب شاخه باشند.)

توجه داشته باشید که دو راه برای checkout کردن یک شاخهٔ خاص وجود دارد. همان‌طور که در بخش‌های دیگر این صفحه شرح داده شده است، پارامتر "module" در دستور cvs checkout به عنوان نام شاخه تفسیر می‌شود و به شاخهٔ اصلی تبدیل می‌گردد. این شاخه حتی اگر موقتاً با دستور cvs update -r شاخهٔ دیگری را پایدار (sticky) کنید، همچنان شاخهٔ اصلی برای یک سندباکس مشخص باقی می‌ماند. به‌علاوه، آرگومان -r می‌تواند شاخهٔ دیگری را برای دریافت واقعی مشخص کند، حتی اگر ماژول همچنان شاخهٔ "اصلی" باشد. مقایسه و توازن (طبق پیاده‌سازی فعلی): هر "ماژول" جدید یک پایگاه‌دادهٔ جدید روی دیسک با تاریخچهٔ ماژول مشخص‌شده ایجاد می‌کند، و پس از ایجاد پایگاه‌داده، عملیات‌ها بر روی آن شاخهٔ اصلی سریع خواهند بود. در مقابل، گزینهٔ -r هیچ فضای دیسک اضافه‌ای اشغال نمی‌کند، اما ممکن است برای بسیاری از عملیات‌ها مانند cvs update به میزان قابل توجهی کندتر باشد.

اگر می‌خواهید به یک refspec گیت ارجاع دهید که شامل نویسه‌های غیرمجاز در CVS است، دو گزینه پیش رو دارید. نخست اینکه شاید ارائهٔ مستقیم refspec گیت به آرگومان مناسب -r در CVS مستقیماً کار کند؛ زیرا به نظر می‌رسد برخی کلاینت‌های CVS بررسی دقیقی روی آرگومان انجام نمی‌دهند. دوم، در صورت عدم موفقیت، می‌توانید از یک سازوکار فرار (escape) نویسه‌های خاص استفاده کنید که تنها از نویسه‌های معتبر در برچسب‌های CVS بهره می‌برد. توالی‌ای متشکل از ۴ یا ۵ نویسه به قالب (زیرخط ("_")، خط تیره ("-")، یک یا دو نویسه، و خط تیره ("-")) می‌تواند بر اساس آن یک یا دو حرف، نویسه‌های مختلفی را کدگذاری کند: "s" برای اسلش ("/")، "p" برای نقطه (".")، "u" برای زیرخط ("_")، یا دو رقم هگزادسیمال برای هر مقدار بایت دیگر (معمولاً یک عدد اسکی، یا بخشی از یک نویسه با کدگذاری UTF-8).

عملیات‌های پایش قدیمی (مانند edit، watch و موارد مرتبط) پشتیبانی نمی‌شوند. استخراج (Export) و برچسب‌گذاری (برچسب‌ها و شاخه‌ها) در این مرحله پشتیبانی نمی‌شوند.

به‌طور پیش‌فرض سرور حالت -k را برای همهٔ فایل‌ها خالی می‌گذارد، که باعث می‌شود کلاینت CVS با آن‌ها مانند فایل‌های متنی رفتار کند که در برخی پلتفرم‌ها مشمول تبدیل انتهای خط می‌شوند.

می‌توانید با تنظیم متغیر پیکربندی gitcvs.usecrlfattr کاری کنید که سرور از مشخصه‌های تبدیل انتهای خط برای تنظیم حالت‌های -k فایل‌ها استفاده کند. برای اطلاعات بیشتر در مورد تبدیل انتهای خط، gitattributes(5) را ببینید.

همچنین اگر پیکربندی gitcvs.usecrlfattr فعال نباشد یا مشخصه‌ها اجازهٔ تشخیص خودکار برای یک نام فایل را ندهند، سرور از پیکربندی gitcvs.allBinary برای تنظیمات پیش‌فرض استفاده می‌کند. اگر gitcvs.allBinary تنظیم شده باشد، فایل‌هایی که وضعیت دیگری برای آن‌ها مشخص نشده به حالت -kb پیش‌فرض خواهند شد. در غیر این صورت حالت -k خالی گذاشته می‌شود. اما اگر gitcvs.allBinary روی "guess" تنظیم شده باشد، حالت صحیح -k بر اساس محتوای فایل حدس زده می‌شود.

برای بیشترین سازگاری با cvs، احتمالاً بهترین کار این است که پیش‌فرض‌ها را با تنظیم gitcvs.usecrlfattr روی true و gitcvs.allBinary روی "guess" بازنویسی کنید.

دستور git-cvsserver به DBD::SQLite وابسته است.

git(1), git-daemon(1), gitattributes(5), gitcvs-migration(7)

بخشی از مجموعهٔ git(1)

2026-06-29 Git 2.55.0