VPN मार्फत SSHFS मा git status ढिलो हुन्छ: काम सार्नुहोस्

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 सन्दर्भ एक पटक पढ्न लायक छ, किनकि कमाण्डले नामले संकेत गरेभन्दा धेरै काम गर्छ।