בניית בקרת גרסאות יעילה ללא שכפול קבצים
שמירת עותקים מלאים של קבצים עבור כל גרסה או fork מבזבזת שטח אחסון. אם אתה משנה שורה אחת בפרויקט עם עשרה קבצים, אתה לא אמור לשמור שוב את כל עשרת הקבצים.
נתקלתי בבעיה זו בזמן בניית פרויקט ה-LaTeX Writer שלי. נזקקתי לדרך לנהל בקרת גרסאות ו-forking של פרויקטים ללא עלויות אחסון גבוהות.
בדקתי איך GitHub עובד. GitHub לא שומר מאגר (repository) מלא בכל פעם שאתה מבצע שינוי. הוא שומר את התוכן בנפרד ומשתמש במפנים (references) כדי לקשר בין קבצים ו-commits.
בניתי את המערכת שלי באמצעות שלושה רכיבים עיקריים:
- Metadata: זה שומר מזהים (IDs) עבור פרויקטים, בעלים ותיקיות.
- File Records: אלו שומרים שמות קבצים וקישורים לתוכן.
- Blobs: כאן נמצא התוכן בפועל.
המערכת עובדת באמצעות content hashing. כשאתה שומר קובץ, המערכת מייצרת מזהה ייחודי המבוסס על התוכן. אם התוכן כבר קיים, המערכת משתמשת מחדש ב-Blob הקיים. היא לא יוצרת חדש.
גישה זו הופכת את ה-forking לקל וזול. כשאתה מבצע fork לפרויקט:
- המערכת יוצרת Project ID חדש.
- היא יוצרת metadata חדש עבור קבצים ותיקיות.
- היא מפנה את ה-metadata החדש אל ה-Blobs הקיימים.
שום תוכן קובץ בפועל לא מועתק במהלך fork. אתה רק משכפל את רשומות ה-metadata הקטנות.
כשאתה עורך fork, התהליך נשאר יעיל:
- אתה משנה את התוכן.
- המערכת מבצעת hashing לתוכן החדש.
- היא יוצרת Blob חדש רק אם התוכן המדויק הזה לא קיים.
- ה-metadata של ה-fork שלך מפנה ל-Blob החדש.
- הפרויקט המקורי עדיין מפנה ל-Blob הישן.
לשיטה זו מספר יתרונות:
- deduplication של תוכן חוסך כמויות אדירות של שטח.
- ה-forking קורה באופן מיידי.
- ניהול הגרסאות נשאר מאורגן.
- צמיחת מסד הנתונים נשארת איטית.
אתה מקבל פונקציונליות דמוית GitHub ללא עומס האחסון הכבד.