ראיתי שיש אינסוף בלבול סביב התרגיל הזה, אז החלטתי לרכז את ההסבר באופן ש(אני מקווה) יפשט לכולם את התרגיל.
הנחה 1: נקודת השורש של הגיבוי
ברגע שאנחנו עושים wit init בתיקייה מסוימת, זו התיקייה של הפרויקט שלנו. אותה נרצה לגבות.
נניח שעשינו wit init בתוך התיקייה C:\Projects\Yam\Etztrubal.
מעתה, Etztrubal היא “תיקיית השורש”, ה־repository או “התיקייה המקורית”. בתוכה תיווצר התיקייה .wit.
כל פעם בעתיד שנבקש לשחזר את הגיבוי (לחזור לתמונה מסוימת), אנחנו נחליף את כל התוכן של תיקיית Etztrubal בגיבוי שביקשנו לבצע.
הנחה 2: המטרה היא שיהיה אפשר לשחזר את הקבצים בקלות
הרעיון של wit הוא שבתוך תיקיית .wit/images יישמרו העתקים של התיקייה המקורית.
בעתיד, נרצה להיות מסוגלים לבקש מ־wit לשחזר את קבצים לתוך תיקיית Etztrubal (התיקייה המקורית) בצורה הכי פשוטה שאפשר.
לכן, כל העתק צריך לשמר את היררכיית התיקיות שנמצאת בתוך Etztrubal.
הנחה 3: התיקייה staging_area היא תמונת ראי של התיקייה המקורית
התיקייה staging_area שנמצאת בתוך תיקיית .wit אמורה לשקף את המצב המדויק של התיקייה המקורית.
זאת אומרת, אם:
- כתובתה של התיקייה המקורית היא
C:\Projects\Yam\Etztrubal. - החלטנו להוסיף לגיבוי באמצעות הפקודה add את
C:\Projects\Yam\Etztrubal\a\b\cלגיבוי.
אז תיקיית staging_area תכיל את התיקייה a (ללא קבצים בתוכה), תחתיה את התיקייה b (ללא קבצים בתוכה), ותחתיה את התיקייה c (עם כל הקבצים). כלומר: C:\Projects\Yam\Etztrubal\.wit\staging_area\a\b\c.
זה קורה כיוון ש:
- התיקייה c היא התיקייה שביקשנו להוסיף לגיבוי (באמצעות add). אנחנו נשמור אותה ואת כל הקבצים שבתוכה.
- התיקיות a, b מתווספות כדי שנוכל “לזכור” איפה תיקייה c הייתה שמורה בהיררכיית התיקיות.
למה לשמור בצורה הזו?
- כשנרצה לחזור לאחד הגיבויים, נוכל פשוט להעתיק את תוכן תיקיית הגיבוי בחזרה לתיקייה המקורית. היררכיית הקבצים תישמר, ולא נצטרך להתעסק עם איזו תיקייה הייתה איפה.
- זה עוזר לנו למנוע מצב שבו עשינו
addלתיקייהdולתיקייהeשנמצאים במקומות שונים בהיררכייה, ובשניהם יש קבצים עם שם דומה (נניח:main.py). אם לא נשמור תחת staging_area את הנתיב לתיקייה, עלולים להיווצר התנגשויות.
דוגמאות נוספות
ראו כאן.