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 ಉಲ್ಲೇಖ ಒಮ್ಮೆ ಓದಲು ಯೋಗ್ಯ, ಏಕೆಂದರೆ ಆಜ್ಞೆ ತನ್ನ ಹೆಸರು ಸೂಚಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕೆಲಸ ಮಾಡುತ್ತದೆ.