ساخت کنترل نسخه کارآمد بدون کپی کردن فایلها
ذخیره کپیهای کامل از فایلها برای هر نسخه یا فورک (fork)، باعث هدر رفتن فضا میشود. اگر در پروژهای با ده فایل، تنها یک خط را تغییر دهید، نباید تمام آن ده فایل را دوباره ذخیره کنید.
من هنگام ساخت پروژه LaTeX Writer خود با این مشکل مواجه شدم. به روشی نیاز داشتم تا کنترل نسخه و فورک کردن پروژه را بدون هزینههای بالای ذخیرهسازی مدیریت کنم.
من بررسی کردم که GitHub چگونه کار میکند. GitHub با هر بار تغییر، یک مخزن (repository) کامل ذخیره نمیکند. بلکه محتوا را بهصورت جداگانه ذخیره کرده و از ارجاعها (references) برای پیوند دادن فایلها و کامیتها (commits) استفاده میکند.
من سیستم خود را با استفاده از سه جزء اصلی ساختم:
- Metadata: این بخش شناسههای (IDs) پروژهها، مالکان و پوشهها را ذخیره میکند.
- File Records: این بخش نام فایلها و لینکهای مربوط به محتوا را ذخیره میکند.
- Blobs: اینجاست که محتوای واقعی قرار دارد.
این سیستم از طریق هش کردن محتوا (content hashing) کار میکند. وقتی فایلی را ذخیره میکنید، سیستم یک شناسه منحصربهفرد بر اساس محتوا تولید میکند. اگر آن محتوا از قبل وجود داشته باشد، سیستم از Blob موجود دوباره استفاده میکند و یک Blob جدید نمیسازد.
این رویکرد، فورک کردن را آسان و ارزان میکند. وقتی پروژهای را فورک میکنید:
- سیستم یک Project ID جدید ایجاد میکند.
- متادیتای جدیدی برای فایلها و پوشهها ایجاد میکند.
- متادیتای جدید را به Blobهای موجود ارجاع میدهد.
در طول یک فورک، هیچ محتوای واقعی از فایل کپی نمیشود. شما فقط رکوردهای کوچک متادیتا را تکثیر میکنید.
وقتی یک فورک را ویرایش میکنید، فرآیند همچنان کارآمد باقی میماند:
- شما محتوا را تغییر میدهید.
- سیستم محتوای جدید را هش میکند.
- تنها در صورتی یک Blob جدید ایجاد میکند که آن محتوای دقیق از قبل وجود نداشته باشد.
- متادیتای فورک شما به Blob جدید اشاره میکند.
- پروژه اصلی همچنان به Blob قدیمی اشاره میکند.
این روش چندین مزیت دارد:
- حذف دادههای تکراری محتوا (Content deduplication) حجم عظیمی از فضا را ذخیره میکند.
- فورک کردن بهصورت آنی انجام میشود.
- مدیریت نسخهها سازمانیافته باقی میماند.
- رشد پایگاه داده کند باقی میماند.
شما بدون هزینههای سنگین ذخیرهسازی، به قابلیتهایی مشابه GitHub دست مییابید.