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 సూచన ఒకసారి చదవదగినది, ఎందుకంటే కమాండ్ దాని పేరు సూచించే దాని కంటే చాలా ఎక్కువ పని చేస్తుంది.