git status זוחל על SSHFS דרך VPN: העבירו את העבודה

העתיקו קובץ של 200 MB והוא עף. הריצו git status באותה תיקייה וההמתנה ארוכה מספיק כדי לעבור למשהו אחר. שתי התצפיות האלה אינן סותרות, כי העברה בכמות מודדת תפוקה בעוד ש-Git מודד כמה שאלות קטנות על מערכת הקבצים הוא יכול לשאול בשנייה, וכן עץ מרוחק מעוגן הופך כל שאלה להלוך ושוב. כוונון ה-VPN לא יתקן עומס עבודה בצורה שגויה.

למה status הוא אמת המידה הלא נכונה

Git צריך לדעת על קבצים רבים: אילו שונו, אילו אינם במעקב והאם נתוני האינדקס שבמטמון עדיין תואמים למה שנמצא בדיסק. דרך SSHFS כל אחת מהתצפיות האלה יכולה להיות פעולת רשת. יחידת העבודה כאן היא מספר הקבצים, לא המגה-בייטים.

לכן ה-status הראשון אחרי שיבוט איטי, ולכן אלה שאחריו יכולים להיות איטיים עוד יותר בעץ מלא בפלט בנייה. סריקת קבצים שאינם במעקב עוברת בתיקיות שאולי לא מעניינות אתכם, וכל צעד הוא בקשה נוספת דרך הקישור. בנתיב של 40 ms עץ עם כמה אלפי רשומות הופך לכמה אלפי הליכות הלוך ושוב. אין צורך בלכידת מנות כדי לאשר את החשבון הזה.

מבחן הורדה אומר שהקישור תקין; הוא לא אומר דבר על השאלה אם אלף קריאות קטנות יסתיימו היום אחר הצהריים.

העבירו את עץ העבודה, לא את כפתורי הכוונון

שיבוט מקומי שם את עץ העבודה, את האינדקס ואת פעולות Git על אותה מכונה. pull הופך לשלב רשת גלוי במקום שכל בדיקת קובץ תהיה כזו.

זה מתאים בכל פעם שהמפתח יכול להחזיק את המקור הנדרש מקומית, שזה רוב הזמן. זה גם מחדד את הגבול בין commit לפריסה, כי עריכת קובץ מקומי כבר לא משנה בטעות שירות מרוחק שרץ; השינוי חייב להידחף ולהיפרס כמו כל דבר אחר. המחיר הוא שהקוד קיים בשני מקומות, אז החליטו איזה עותק הוא הסמכותי ואיך תיקון חירום בשרת חוזר למאגר. השיחה הזאת זולה יותר מפקודת status שאיש לא רוצה להריץ.

אם סביבת העבודה חייבת להישאר מרוחקת, הריצו Git שם

לפעמים אי אפשר להעביר את סביבת העבודה: הבנייה צריכה את הסביבה הזאת, הנתונים גדולים מדי או שהמדיניות משאירה את המקור במארח. אז הריצו Git ואת כלי הפיתוח הרלוונטיים ליד הקבצים, דרך מעטפת מרוחקת מאושרת או סביבת פיתוח מרוחקת. העורך יכול להישאר במחשב הנייד בזמן שהחלק האחורי שלו עובד ליד עץ העבודה.

פעולות יקרות מתרחשות אז מקומית במארח המרוחק, והרשת נושאת את תעבורת העורך במקום אלפי קריאות stat. זה אותו תיקון כמו שיבוט מקומי, מבוטא כבחירת פריסה ולא כהגירה.

סנכרון הוא זרימת עבודה עם בעלים, לא מטמון

סביבת עבודה מסונכרנת יכולה לקצץ קריאות מרוחקות חוזרות, אבל היא אינה מטמון שקוף. היא צריכה בעלים לכל שינוי, כלל לעימותים והסכמה על קבצים שנוצרים ושני הצדדים חושבים שהם הבעלים שלהם. בלי הכללים האלה הסידור יוצר מחלוקת ולא נוחות.

מסנכרן דו-כיווני בלעדיהם מייצר בעיה אחרת מזו שפתר, בדרך כלל מיזוג שאיש לא יכול לייחס. הימנעו מהרצת שני תהליכי Git על עץ עבודה משותף אחד אלא אם אתם מבינים איך הם מתאמים.

ואז כווננו, ושמרו על SSH שפוי

כשהסידור נכון, שתי הגדרות משנות על כמה קבצים Git צריך לשאול: status.showUntrackedFiles והמטמון של קבצים שאינם במעקב מאחורי core.untrackedCache. אף אחת מהן לא משנה את עלות כל שאלה לאורך 40 ms; הן רק משנות כמה שאלות יש. סובבו כפתור רק כשהליכות הלוך ושוב הן מקומיות.

מדדו את הזמן של הפקודה שמעצבנת אתכם במקום להסיק ממבחן שמעתיק קובץ גדול אחד, והניחו להצפנת SSH הנתמכת. צופן מיושן לא מקצר הלוך ושוב; הוא מוסיף בעיה שנייה ששורדת את הראשונה. ההפניה של git status שווה קריאה אחת, כי הפקודה עושה הרבה יותר עבודה משמה מרמז.