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 ਸੰਦਰਭ ਇੱਕ ਵਾਰ ਪੜ੍ਹਨ ਯੋਗ ਹੈ, ਕਿਉਂਕਿ ਕਮਾਂਡ ਆਪਣੇ ਨਾਮ ਤੋਂ ਕਿਤੇ ਵੱਧ ਕੰਮ ਕਰਦੀ ਹੈ।