OpenAI ਵਿੱਚ Git ਦੀ ਸਮਰੱਥਾ ਵਧਾਉਣਾ
Git ਦੇ ਪਰਿਸਥਿਤੀ-ਤੰਤਰ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਦਿਆਂ ਏਜੰਟਾਂ ਦੇ ਪੈਮਾਨੇ ਲਈ ਸੋਰਸ ਕੰਟਰੋਲ ਬਣਾਉਣਾ.
ਪਿਛਲੇ ਸਾਲ ਦੌਰਾਨ ਸਾਡੀ ਮੋਨੋਰਿਪੋ ਦਾ ਆਕਾਰ ਅਤੇ ਉਸ ਤੋਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਮੰਗਾਂ ਹੈਰਾਨੀਜਨਕ ਰਫ਼ਤਾਰ ਨਾਲ ਵਧੀਆਂ ਹਨ. ਇਹ ਸਪਸ਼ਟ ਸੀ ਕਿ Codex ਜਿੰਨੇ ਕੰਮ ਇੱਕੋ ਵੇਲੇ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਸਾਨੂੰ ਆਪਣੇ ਸੋਰਸ ਕੰਟਰੋਲ ਸਿਸਟਮ ਨੂੰ ਨਵੇਂ ਸਿਰੇ ਤੋਂ ਢਾਲਣਾ ਪਵੇਗਾ.
ਅਸੀਂ ਕਿਸੇ ਇੰਜੀਨੀਅਰਿੰਗ ਕੰਮ ਵਿੱਚ ਰੁਕਾਵਟ ਪਾਏ ਜਾਂ ਆਪਣੀ ਟੀਮ ਦਾ Git ਵਰਤਣ ਦਾ ਤਰੀਕਾ ਬਦਲੇ ਬਿਨਾਂ, Git ਰਿਪੋਜ਼ਟਰੀਆਂ ਲਈ ਨਵਾਂ ਬੈਕਐਂਡ Pando ਬਣਾਇਆ. ਹੁਣ OpenAI ਦੀ ਮੋਨੋਰਿਪੋ ਵਿੱਚ ਸਾਰਾ ਵਿਕਾਸ Pando ਰਾਹੀਂ ਹੁੰਦਾ ਹੈ. Pando ਦੋ ਵੱਡੇ ਟੀਚਿਆਂ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ. ਪਹਿਲਾ: ਹੋਰ ਇਕਾਈਆਂ ਜੋੜ ਕੇ ਲਿਖਣ ਦੀ ਸਮਰੱਥਾ ਵਧਾਉਣਾ, ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਕਈ ਬ੍ਰਾਂਚਾਂ 'ਤੇ ਇੱਕੋ ਵੇਲੇ ਪੁਸ਼ ਕਰਨ ਲਈ. ਦੂਜਾ: ਪੜ੍ਹਨ ਦਾ ਥਰੂਪੁੱਟ ਵੱਧ ਤੋਂ ਵੱਧ ਕਰਨਾ, ਤਾਂ ਜੋ ਕਲਾਇੰਟ ਇੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਡੇਟਾ ਡਾਊਨਲੋਡ ਕਰ ਸਕਣ ਕਿ ਉਹਨਾਂ ਦੀ ਉਪਲਬਧ ਨੈੱਟਵਰਕ ਬੈਂਡਵਿਡਥ ਪੂਰੀ ਵਰਤੀ ਜਾਵੇ.
ਅਸੀਂ Git ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਕਲਾਇੰਟ ਨਾਲ ਅਨੁਕੂਲਤਾ ਬਰਕਰਾਰ ਰੱਖਦਿਆਂ ਇਹ ਟੀਚੇ ਪੂਰੇ ਕੀਤੇ, ਤਾਂ ਜੋ ਸਾਡੇ ਇੰਜੀਨੀਅਰ ਅਤੇ ਏਜੰਟ ਦੋਵੇਂ Pando ਨੂੰ ਆਪਣੇ ਮੌਜੂਦਾ ਕੰਮਕਾਜ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਅਪਣਾ ਸਕਣ. ਉਤਪਾਦਨ ਵਿੱਚ Pando ਨੇ ਪੁਸ਼ ਦੀ ਮੱਧਿਕਾ ਦੇਰੀ ਨੂੰ ਘਟਾ ਕੇ ਲਗਭਗ ਪੰਜਵਾਂ ਹਿੱਸਾ ਕਰ ਦਿੱਤਾ. ਇਹ ਹੁਣ ਰੋਜ਼ਾਨਾ ਲਗਭਗ ਇੱਕ ਪੈਟਾਬਾਈਟ Git ਡੇਟਾ ਪਹੁੰਚਾਉਂਦਾ ਹੈ.
ਇੱਥੇ ਅਸੀਂ ਨਵਾਂ ਸੋਰਸ ਕੰਟਰੋਲ ਸਿਸਟਮ ਬਣਾਉਣ ਦੇ ਕਾਰਨ ਅਤੇ Git ਨਾਲ ਅਨੁਕੂਲਤਾ ਬਰਕਰਾਰ ਰੱਖਣ ਦੀ ਚੋਣ ਬਾਰੇ ਦੱਸਾਂਗੇ. ਅਸੀਂ ਆਪਣੇ ਸਿਸਟਮ ਦੀ ਤੁਲਨਾ Git ਦੀ ਸਮਰੱਥਾ ਵਧਾਉਣ ਦੇ ਆਮ ਤਰੀਕਿਆਂ ਨਾਲ ਕਰਾਂਗੇ ਅਤੇ ਦੱਸਾਂਗੇ ਕਿ OpenAI ਦੀਆਂ ਵਧਦੀਆਂ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕਰਨ ਲਈ Pando ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਸਮਰੱਥ ਕਿਉਂ ਹੈ. ਅਸੀਂ ਅੱਗੇ ਦੀਆਂ ਯੋਜਨਾਵਾਂ ਅਤੇ ਏਜੰਟਾਂ ਦੇ ਪੈਮਾਨੇ 'ਤੇ ਕੰਮ ਨੂੰ ਸਹਾਰਾ ਦੇਣ ਲਈ Git ਵਿੱਚ ਆਪਣਾ ਯੋਗਦਾਨ ਜਾਰੀ ਰੱਖਣ ਬਾਰੇ ਵੀ ਚਰਚਾ ਕਰਾਂਗੇ.
Codex ਨੇ OpenAI ਵਿੱਚ ਵਿਕਾਸ ਦਾ ਪੈਮਾਨਾ ਅਤੇ ਰਫ਼ਤਾਰ ਬਦਲ ਦਿੱਤੇ ਹਨ, ਜਿਸ ਨਾਲ ਇੰਜੀਨੀਅਰ ਇੱਕੋ ਵੇਲੇ ਕਿਤੇ ਵੱਧ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ. ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਹੋਰ ਬ੍ਰਾਂਚਾਂ ਅਤੇ ਪੁਸ਼, ਹੋਰ ਮਰਜ, ਅਤੇ ਵਿਕਾਸ ਵਾਤਾਵਰਨਾਂ, ਖੋਜ ਕਾਰਜਾਂ ਤੇ ਨਿਰੰਤਰ ਏਕੀਕਰਨ ਤੋਂ ਹੋਰ ਫੈਚ ਅਤੇ ਕਲੋਨ.
ਇਹ ਮੰਗਾਂ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਹੋਰ ਵਧਾਉਂਦੀਆਂ ਹਨ. ਹੁਣ ਇੱਕ ਇੰਜੀਨੀਅਰ ਕੋਲ ਇੱਕੋ ਵੇਲੇ ਨਿਰੰਤਰ ਏਕੀਕਰਨ ਲਈ ਕਈ ਬਦਲਾਅ ਤਿਆਰ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਹਰ ਪੁਸ਼ ਕਈ ਕਾਰਜਾਂ ਨੂੰ ਇੱਕੋ ਕਮਿਟ ਫੈਚ ਕਰਨ ਲਈ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ.
ਪਿਛਲੇ ਸਾਲ ਦੇ ਅਖੀਰ ਤੋਂ ਸਾਡੀ ਮੋਨੋਰਿਪੋ ਨੂੰ ਚਲਾਉਣ ਵਾਲੇ ਸਿਸਟਮ ਇਸ ਰਫ਼ਤਾਰ ਨਾਲ ਕਦਮ ਮਿਲਾਉਣ ਲਈ ਜੂਝ ਰਹੇ ਸਨ. ਸਾਨੂੰ ਧੀਮੇ ਫੈਚ ਅਤੇ ਪੁਸ਼ ਦੇ ਨਾਲ ਅਸਫਲ ਮਰਜਾਂ ਦਾ ਵੀ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ. ਕਈ ਵਾਰ ਭਰੋਸੇਯੋਗਤਾ 90% ਤੋਂ ਹੇਠਾਂ ਆ ਗਈ. ਕੀ ਅਸੀਂ ਖ਼ੁਦ Git ਦੀ ਹੱਦ ਤੱਕ ਪਹੁੰਚ ਗਏ ਸੀ, ਜਾਂ ਮੋਨੋਰਿਪੋ ਦੀ ਸੇਵਾ ਦੇਣ ਦੇ ਆਪਣੇ ਤਰੀਕੇ ਦੀ ਹੱਦ ਤੱਕ? Git ਉਸ ਭਾਈਚਾਰੇ ਵਿੱਚੋਂ ਉਭਰਿਆ ਸੀ ਜੋ ਈਮੇਲ ਰਾਹੀਂ ਕਰਨਲ ਦੇ ਪੈਚ ਸਾਂਝੇ ਕਰਦਾ ਸੀ. ਦੋ ਦਹਾਕਿਆਂ ਤੋਂ ਵੱਧ ਸਮੇਂ ਤੋਂ, ਸੌਫਟਵੇਅਰ ਬਣਾਉਣ ਦੇ ਤਰੀਕੇ ਬਦਲਣ ਨਾਲ ਵਿਕਾਸਕਾਰਾਂ ਨੇ ਆਪਣੇ ਟੂਲਾਂ ਨੂੰ Git ਦੇ ਅਨੁਸਾਰ ਢਾਲਿਆ ਹੈ. ਜਦੋਂ ਸਾਡੀ ਆਪਣੀ ਮੋਨੋਰਿਪੋ ਵਿੱਚ ਅੜਚਣਾਂ ਆਉਣ ਲੱਗੀਆਂ, ਤਾਂ ਸਾਡੇ ਲਈ ਇਹ ਅਹਿਮ ਸੀ ਕਿ ਅਸੀਂ ਉਸ ਕੰਮ ਦੀ ਨੀਂਹ 'ਤੇ ਅੱਗੇ ਵਧ ਸਕੀਏ.
ਸਾਨੂੰ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਕੰਮਕਾਜ ਬਰਕਰਾਰ ਰੱਖਦਿਆਂ ਬੈਕਐਂਡ ਮੁੜ ਬਣਾਉਣ ਦਾ ਰਾਹ ਦਿਸਿਆ: ਵੱਖਰੀਆਂ ਬ੍ਰਾਂਚਾਂ ਦੇ ਪੁਸ਼ ਸਮਾਂਤਰ ਸੰਭਾਲਣੇ ਅਤੇ ਕਈ ਪੜ੍ਹਨ ਵਾਲੇ ਕਲਾਇੰਟਾਂ ਨੂੰ ਇੱਕੋ ਇਤਿਹਾਸ ਇੱਕੋ ਵੇਲੇ ਦੇਣਾ. Git ਨੂੰ ਸਾਡੇ ਸੋਰਸ ਕੰਟਰੋਲ ਕੰਮਕਾਜ ਦੀ ਨੀਂਹ ਬਣਾਉਣ ਦਾ ਮਤਲਬ ਸੀ ਕਿ ਕਲਾਇੰਟ ਵਿੱਚ ਕੀਤੇ ਸੁਧਾਰ OpenAI ਤੋਂ ਬਾਹਰ ਵੀ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦੇ ਸਨ. ਅਸੀਂ ਆਪਣੀ Git ਦੀ ਕਾਪੀ(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਤੋਂ ਉਹ ਸੁਧਾਰ ਮੂਲ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਦੇਣਾ ਚਾਹੁੰਦੇ ਸੀ, ਤਾਂ ਜੋ ਉਹ ਵੱਡੇ ਭਾਈਚਾਰੇ ਨਾਲ ਸਾਂਝੇ ਹੋਣ.
ਸੋਰਸ ਕੰਟਰੋਲ ਸਿਸਟਮ ਦੀ ਸਮਰੱਥਾ ਵਧਾਉਣ ਦੇ ਦੋ ਮੁੱਖ ਪੱਖ ਹਨ: ਕਈ ਲਿਖਣ ਵਾਲੇ ਕਲਾਇੰਟਾਂ ਦਾ ਵੱਖਰੀਆਂ ਬ੍ਰਾਂਚਾਂ 'ਤੇ ਪੁਸ਼ ਕਰਨਾ, ਅਤੇ ਕਈ ਪੜ੍ਹਨ ਵਾਲੇ ਕਲਾਇੰਟਾਂ ਦਾ ਇੱਕੋ ਇਤਿਹਾਸ ਫੈਚ ਕਰਨਾ. Pando ਦੋਵਾਂ ਲਈ ਅਨੁਕੂਲ ਬਣਾਇਆ ਗਿਆ ਹੈ.
ਪਹਿਲਾਂ, Pando ਹਰ ਬ੍ਰਾਂਚ ਦੇ ਅੱਪਡੇਟਾਂ ਦਾ ਤਾਲਮੇਲ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਕਰਦਾ ਹੈ. ਅਸੰਬੰਧਤ ਬ੍ਰਾਂਚਾਂ ਦੇ ਅੱਪਡੇਟ ਸਮਾਂਤਰ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਬ੍ਰਾਂਚ ਫੈਚ ਕਰਨ ਵਾਲੇ ਕਲਾਇੰਟ ਨੂੰ ਉਸ ਸੰਸਕਰਣ ਲਈ ਲੋੜੀਂਦਾ ਇਤਿਹਾਸ ਮਿਲਦਾ ਹੈ. ਇਸ ਦੇ ਬਦਲੇ ਇਹ ਸਮਝੌਤਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਕਈ ਬ੍ਰਾਂਚਾਂ ਵੇਖਣ ਵਾਲੇ ਕਲਾਇੰਟ ਨੂੰ ਉਹ ਵੱਖ-ਵੱਖ ਸਮਿਆਂ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਦਿਸ ਸਕਦੀਆਂ ਹਨ.
ਦੂਜਾ, Pando ਹਰ ਕਲਾਇੰਟ ਲਈ ਵੱਖਰੀ ਪੈਕਫ਼ਾਈਲ ਬਣਾਉਣ ਦੀ ਬਜਾਏ ਵੱਖ-ਵੱਖ ਫੈਚਾਂ ਵਿੱਚ ਪੈਕਫ਼ਾਈਲਾਂ ਮੁੜ ਵਰਤਦਾ ਹੈ. ਪੈਕਫ਼ਾਈਲ Git ਦਾ ਕਈ ਆਬਜੈਕਟ ਇਕੱਠੇ ਸੰਕੁਚਿਤ ਕਰਨ ਦਾ ਫ਼ਾਰਮੈਟ ਹੈ. ਕਲਾਇੰਟ ਕੁਝ ਅਜਿਹੇ ਆਬਜੈਕਟ ਵੀ ਡਾਊਨਲੋਡ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਉਸ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹਨ, ਪਰ ਸਰਵਰ ਥੋੜ੍ਹੀ ਗਣਨਾ ਨਾਲ ਉਹੀ ਬਾਈਟ ਕਈ ਕਲਾਇੰਟਾਂ ਨੂੰ ਦੇ ਸਕਦਾ ਹੈ.
ਇਹ ਚੋਣਾਂ ਸਾਨੂੰ ਬ੍ਰਾਂਚਾਂ ਵਿੱਚ ਲਿਖਣ ਦੀ ਸਮਰੱਥਾ ਵਧਾਉਣ ਅਤੇ ਕੈਸ਼ਾਂ ਤੋਂ ਪੜ੍ਹਨ ਦੀਆਂ ਬੇਨਤੀਆਂ ਪੂਰੀਆਂ ਕਰਨ ਦਿੰਦੀਆਂ ਹਨ. ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਇਹ ਤਰੀਕੇ ਇਕੱਠੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਆਓ ਪਹਿਲਾਂ ਵੇਖੀਏ ਕਿ Git ਇਤਿਹਾਸ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦਾ ਅਤੇ ਭੇਜਦਾ ਹੈ.
Git ਲਈ ਰਿਪੋਜ਼ਟਰੀ ਦੇ ਦੋ ਹਿੱਸਿਆਂ ਨੂੰ ਤਾਲਮੇਲ ਵਿੱਚ ਰੱਖਣਾ ਜ਼ਰੂਰੀ ਹੈ: ਆਬਜੈਕਟ ਅਤੇ ਰੈਫ਼ਰੈਂਸ.
Git ਰਿਪੋਜ਼ਟਰੀ ਫ਼ਾਈਲਾਂ ਦੀਆਂ ਝਲਕਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਜੋੜਨ ਵਾਲਾ ਇਤਿਹਾਸ ਆਬਜੈਕਟਾਂ ਦੇ ਗ੍ਰਾਫ਼ ਵਜੋਂ ਦਰਜ ਕਰਦੀ ਹੈ. ਆਬਜੈਕਟ ਬਲੌਬ, ਟ੍ਰੀ, ਕਮਿਟ ਜਾਂ ਟੈਗ ਹੋ ਸਕਦਾ ਹੈ. ਬਲੌਬ ਇੱਕ ਫ਼ਾਈਲ ਦੀ ਸਮੱਗਰੀ ਰੱਖਦੇ ਹਨ. ਟ੍ਰੀ ਨਾਵਾਂ ਨੂੰ ਬਲੌਬਾਂ ਜਾਂ ਹੋਰ ਟ੍ਰੀਆਂ ਨਾਲ ਜੋੜ ਕੇ ਡਾਇਰੈਕਟਰੀ ਦਾ ਢਾਂਚਾ ਬਣਾਉਂਦੇ ਹਨ. ਕਮਿਟ ਇੱਕ ਰੂਟ ਟ੍ਰੀ ਅਤੇ ਸਿਫ਼ਰ ਜਾਂ ਵੱਧ ਪੇਰੈਂਟ ਕਮਿਟਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਤੁਹਾਡੀ ਰਿਪੋਜ਼ਟਰੀ ਦਾ ਇਤਿਹਾਸ ਬਣਦਾ ਹੈ.
ਆਬਜੈਕਟਾਂ ਦੀ ਪਛਾਣ ਉਹਨਾਂ ਦੀ ਕਿਸਮ ਅਤੇ ਸਮੱਗਰੀ ਦੇ ਹੈਸ਼ ਨਾਲ ਹੁੰਦੀ ਹੈ. ਆਬਜੈਕਟ ਅਬਦਲ ਵੀ ਹੁੰਦੇ ਹਨ: ਬਦਲੀ ਹੋਈ ਫ਼ਾਈਲ ਦਰਜ ਕਰਨ ਨਾਲ ਨਵਾਂ ਬਲੌਬ ਬਣਦਾ ਹੈ, ਜਦਕਿ ਨਾ ਬਦਲੀਆਂ ਫ਼ਾਈਲਾਂ ਅਤੇ ਡਾਇਰੈਕਟਰੀਆਂ ਮੌਜੂਦਾ ਆਬਜੈਕਟ ਮੁੜ ਵਰਤ ਸਕਦੀਆਂ ਹਨ.
ਬ੍ਰਾਂਚਾਂ ਅਤੇ ਟੈਗ ਰੈਫ਼ਰੈਂਸ, ਜਾਂ “ਰੈਫ਼”, ਹੁੰਦੇ ਹਨ ਜੋ ਕਮਿਟਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ. ਬ੍ਰਾਂਚ 'ਤੇ ਕਮਿਟ ਕਰਨ ਨਾਲ ਨਵਾਂ ਕਮਿਟ ਬਣਦਾ ਹੈ ਅਤੇ ਬ੍ਰਾਂਚ ਦਾ ਰੈਫ਼ ਉਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਲਈ ਅੱਪਡੇਟ ਹੁੰਦਾ ਹੈ.
Git ਆਬਜੈਕਟਸ ਇੱਕ ਦੂਜੇ ਨੂੰ ਉਹਨਾਂ ਦੀ ID ਰਾਹੀਂ ਰੈਫ਼ਰ ਕਰਦੇ ਹਨ, ਕਮਿੱਟ ਟ੍ਰੀਜ਼ ਵੱਲ, ਅਤੇ ਟ੍ਰੀਜ਼ ਹੋਰਨਾਂ ਟ੍ਰੀਜ਼ ਅਤੇ ਬਲੌਬਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ। ਬ੍ਰਾਂਚ refs/heads/main ਕਮਿੱਟ C2 ਵੱਲ ਪੁਆਇੰਟ ਕਰਦੀ ਹੈ, ਜਿਸਦਾ ਪੇਰੈਂਟ C1 ਹੈ। C1 ਰੂਟ ਟ੍ਰੀ T1 ਵੱਲ ਪੁਆਇੰਟ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ parser.py ਬਲੌਬ B1 ਨੂੰ ਰੈਫ਼ਰ ਕਰਦਾ ਹੈ। C2 ਰੂਟ ਟ੍ਰੀ T2 ਵੱਲ ਪੁਆਇੰਟ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ parser.py ਬਲੌਬ B2 ਨੂੰ ਰੈਫ਼ਰ ਕਰਦਾ ਹੈ। ਦੋਵਾਂ ਰੂਟ ਟ੍ਰੀਜ਼ ਵਿੱਚ, docs/ ਇੱਕੋ ਟ੍ਰੀ, T3, ਨੂੰ ਰੈਫ਼ਰ ਕਰਦਾ ਹੈ। ਇਸਦੀ README.md ਐਂਟਰੀ ਬਲੌਬ B3 ਵੱਲ ਪੁਆਇੰਟ ਕਰਦੀ ਹੈ, ਅਤੇ usage.md ਬਲੌਬ B4 ਵੱਲ ਪੁਆਇੰਟ ਕਰਦੀ ਹੈ।
Git ਆਬਜੈਕਟਾਂ ਨੂੰ “ਵੱਖਰੇ” ਜਾਂ “ਪੈਕ ਕੀਤੇ” ਰੂਪ ਵਿੱਚ ਸੰਭਾਲਦਾ ਹੈ. ਵੱਖਰੇ ਆਬਜੈਕਟ ਅਲੱਗ-ਅਲੱਗ ਫ਼ਾਈਲਾਂ ਵਿੱਚ ਸੰਭਾਲੇ ਜਾਂਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਦੀ ਪਛਾਣ ਉਹਨਾਂ ਦੇ ਆਬਜੈਕਟ ਆਈਡੀ ਨਾਲ ਹੁੰਦੀ ਹੈ. ਪੈਕ ਕੀਤੇ ਆਬਜੈਕਟ ਇੱਕ ਪੈਕਫ਼ਾਈਲ ਵਿੱਚ ਇਕੱਠੇ ਸੰਭਾਲੇ ਜਾਂਦੇ ਹਨ. ਇਸ ਨਾਲ ਮਿਲਦੇ-ਜੁਲਦੇ ਆਬਜੈਕਟਾਂ ਨੂੰ ਇੱਕ-ਦੂਜੇ ਤੋਂ ਅੰਤਰ ਵਜੋਂ ਸੰਭਾਲਿਆ ਜਾ ਸਕਦਾ ਹੈ.
Git ਬਲੌਬਾਂ ਨੂੰ ਵੱਖਰੀਆਂ ਫ਼ਾਈਲਾਂ ਵਜੋਂ ਸਟੋਰ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਇਕੱਠਾ ਪੈਕ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਇੱਕ ਬਲੌਬ ਨੂੰ ਦੂਜੇ ਦੇ ਮੁਕਾਬਲੇ ਡੈਲਟਾ ਵਜੋਂ ਐਨਕੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
Git ਵਿੱਚ, ਕੋਈ ਆਬਜੈਕਟ ਕਿਸੇ ਕਮਿੱਟ ਤੋਂ ਉਦੋਂ ਰੀਚੇਬਲ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਜੇਕਰ Git ਉਸ ਕਮਿੱਟ ਤੋਂ ਉਸਦੇ ਪੇਰੈਂਟਸ, ਟ੍ਰੀਜ਼, ਅਤੇ ਬਲੌਬਸ ਰਾਹੀਂ ਲਿੰਕਾਂ ਨੂੰ ਫ਼ਾਲੋ ਕਰਕੇ ਉਸਨੂੰ ਲੱਭ ਸਕਦਾ ਹੈ। ਫ਼ੈੱਚ ਦੌਰਾਨ, ਕਲਾਇੰਟ ਸਰਵਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਉਸਨੂੰ ਕਿਹੜੇ ਕਮਿੱਟ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਕਿਹੜੇ ਉਸ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹਨ। ਸਰਵਰ ਲੋੜੀਂਦੇ ਕਮਿੱਟਾਂ ਤੋਂ ਰੀਚੇਬਲ ਆਬਜੈਕਟਾਂ ਨੂੰ ਲੱਭਦਾ ਹੈ, ਉਹਨਾਂ ਆਬਜੈਕਟਾਂ ਨੂੰ ਬਾਹਰ ਕੱਢ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਉਸਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹਨ, ਅਤੇ ਬਾਕੀ ਬਚੇ ਆਬਜੈਕਟਾਂ ਨੂੰ ਉਸੇ ਫਾਰਮੈਟ ਵਿੱਚ ਇੱਕ ਪੈਕਫਾਈਲ ਵਜੋਂ ਭੇਜਦਾ ਹੈ ਜਿਸਨੂੰ Git ਡਿਸਕ ਉੱਤੇ ਵਰਤਦਾ ਹੈ। ਇੱਕ ਫੁੱਲ ਕਲੋਨ ਬਿਨਾਂ ਕਿਸੇ ਆਬਜੈਕਟ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਕਲੋਨ ਕੀਤੀ ਜਾ ਰਹੀ ਹਿਸਟਰੀ ਤੋਂ ਰੀਚੇਬਲ ਸਾਰੇ ਆਬਜੈਕਟਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਇੱਕ ਪੁਸ਼ ਸਰਵਰ ਨੂੰ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਰੈਫ਼ਸ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਕਹਿ ਕੇ ਆਬਜੈਕਟਾਂ ਨੂੰ ਦੂਜੀ ਦਿਸ਼ਾ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰਦਾ ਹੈ। ਕਲਾਇੰਟ ਸਰਵਰ ਵੱਲੋਂ ਐਡਵਰਟਾਈਜ਼ ਕੀਤੇ ਗਏ ਰੈਫ਼ਸ ਦੇ ਸੈੱਟ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਉਹਨਾਂ ਆਬਜੈਕਟਾਂ ਨੂੰ ਭੇਜਣ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ ਜੋ ਸਰਵਰ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹਨ। ਇਸ ਲਈ ਭੇਜਿਆ ਜਾ ਰਿਹਾ ਪੈਕ ਮੌਜੂਦਾ ਆਬਜੈਕਟਾਂ 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦਾ ਹੈ: ਨਵੀਂ ਹਿਸਟਰੀ ਨੂੰ ਮੁੜ ਤਿਆਰ ਕਰਨ ਲਈ ਸਿਰਫ਼ ਪੈਕ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੀ ਕਾਫ਼ੀ ਨਹੀਂ ਹੁੰਦਾ।
ਕਿਸੇ Git ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਰੈਪਲੀਕੇਟ ਕਰਨ ਦਾ ਮਤਲਬ ਹੈ ਆਬਜੈਕਟਾਂ ਅਤੇ ਰੈਫ਼ਰੈਂਸਾਂ ਦੋਵਾਂ ਨੂੰ ਕਈ ਸਰਵਰਾਂ 'ਤੇ ਉਪਲਬਧ ਰੱਖਣਾ। ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਕੋਈ ਰੈਪਲੀਕਾ ਕਿਸੇ ਰੈਫ਼ਰੈਂਸ ਦਾ ਨਵਾਂ ਮੁੱਲ ਸਰਵ ਕਰ ਸਕੇ, ਉਸ ਕੋਲ ਉਸ ਮੁੱਲ ਤੋਂ ਰੀਚੇਬਲ ਆਬਜੈਕਟ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਰਵਿਸ ਨੂੰ ਆਪਸ ਵਿੱਚ ਮੁਕਾਬਲਾ ਕਰ ਰਹੇ ਰੈਫ਼ਰੈਂਸ ਅੱਪਡੇਟਾਂ ਵਿੱਚ ਤਾਲਮੇਲ ਬਣਾਉਣ ਦੀ ਵੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਯਾਨੀ ਕਿ ਅਜਿਹੇ ਪੁਸ਼ ਜੋ ਇੱਕੋ ਪੁਰਾਣੇ ਟਿਪ ਤੋਂ ਇੱਕੋ ਬ੍ਰਾਂਚ ਨੂੰ ਵੱਖੋ-ਵੱਖਰੇ ਨਵੇਂ ਕਮਿੱਟਾਂ ਵੱਲ ਲੈ ਜਾਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਅਜਿਹੇ ਸਿਸਟਮ ਜੋ ਕਿਸੇ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਸਾਰੇ ਰਾਈਟਸ 'ਤੇ ਸਿੰਗਲ ਕ੍ਰਮ ਲਾਗੂ ਕਰਦੇ ਹਨ, ਉਹ ਗ਼ੈਰ-ਸੰਬੰਧਿਤ ਬ੍ਰਾਂਚਾਂ ਦੇ ਪੁਸ਼ਾਂ ਨੂੰ ਵੀ ਇੱਕ ਦੂਜੇ ਲਈ ਉਡੀਕ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰ ਸਕਦੇ ਹਨ।
Pando ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਸਮੇਂ, ਅਸੀਂ Git ਦੀ ਵਰਤੋਂ ਨਾਲ ਸੋਰਸ ਕੰਟਰੋਲ ਨੂੰ ਸਕੇਲ ਕਰਨ ਦੇ ਰਵਾਇਤੀ ਤਰੀਕਿਆਂ ਦਾ ਮੁਲਾਂਕਣ ਕੀਤਾ: ਇੱਕ ਉਹ ਜੋ ਥ੍ਰੀ-ਫੇਜ਼ ਕਮਿੱਟ (3PC, ਕਈ ਨੋਡਾਂ ਵਿਚਕਾਰ ਕਮਿੱਟ ਦਾ ਤਾਲਮੇਲ ਕਰਨ ਵਾਲਾ ਪ੍ਰੋਟੋਕੋਲ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਰਿਪੋਜ਼ਟਰੀ ਰੈਪਲੀਕਾਜ਼ ਵਿਚਕਾਰ ਰੈਫ਼ ਅੱਪਡੇਟਾਂ ਵਿੱਚ ਤਾਲਮੇਲ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਦੂਜਾ ਉਹ ਜੋ ਬਲੌਬ ਸਟੋਰੇਜ ਵਿੱਚ ਸਾਂਝੇ ਰਾਈਟ-ਅਹੈੱਡ ਲੌਗ (WAL, ਤਬਦੀਲੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖਿਆ ਜਾਣ ਵਾਲਾ ਰਿਕਾਰਡ) ਰਾਹੀਂ ਅੱਪਡੇਟਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਬੰਨ੍ਹਦਾ ਹੈ।
ਅਸੀਂ ਜਿਸ ਥ੍ਰੀ-ਫੇਜ਼ ਕਮਿੱਟ ਡਿਜ਼ਾਈਨ ਦਾ ਮਾਡਲ ਤਿਆਰ ਕੀਤਾ ਸੀ, ਉਸ ਵਿੱਚ Git ਸਰਵਿਸ ਕਈ ਰੈਪਲੀਕਾਜ਼ ਉੱਤੇ ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਇੱਕ ਪੂਰੀ ਕਾਪੀ ਰੱਖਦੀ ਹੈ। ਜਦੋਂ ਕੋਈ ਵੀ ਸਰਵਰ ਪੁਸ਼ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਆਉਣ ਵਾਲੀ ਪੈਕਫਾਈਲ ਦੀ ਕਾਪੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਪੈਰਲਲ ਵਿੱਚ ਸਾਰੇ ਰੈਪਲੀਕਾਜ਼ ਨੂੰ ਭੇਜ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਪੁਸ਼ ਨੂੰ ਪਬਲਿਸ਼ ਕਰਨ ਲਈ, ਬਹੁਮਤ ਰੈਪਲੀਕਾਜ਼ ਵੱਲੋਂ ਰੈਫ਼ ਅੱਪਡੇਟ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ। ਇਸ ਪ੍ਰਕਿਰਿਆ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਵਾਲਾ ਸਰਵਰ ਕੋਆਰਡੀਨੇਟਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਸ ਲਈ ਕੋਆਰਡੀਨੇਟਰ ਅਤੇ ਹਰੇਕ ਹੋਰ ਰੈਪਲੀਕਾ ਵਿਚਕਾਰ ਸੰਚਾਰ ਦੇ ਕਈ ਰਾਊਂਡਜ਼ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ।
ਕਿਸੇ ਰੈਫ਼ਰੈਂਸ ਅੱਪਡੇਟ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਲਈ, ਹਰੇਕ ਰੈਪਲੀਕਾ ਰੈਫ਼ ਦੀ ਆਪਣੀ ਕਾਪੀ ਨੂੰ ਲੌਕ ਕਰਦਾ ਹੈ ਅਤੇ ਜਾਂਚਦਾ ਹੈ ਕਿ ਕੀ ਇਹ ਅਜੇ ਵੀ ਉਸੇ ਕਮਿੱਟ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਰਿਹਾ ਹੈ ਜਿਸਦੀ ਕਲਾਇੰਟ ਉਮੀਦ ਕਰਦਾ ਹੈ। ਫਿਰ ਕੋਆਰਡੀਨੇਟਰ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੇ ਰੈਪਲੀਕਾਜ਼ ਨੂੰ ਇੱਕ ਪ੍ਰੀ-ਕਮਿੱਟ ਸੁਨੇਹਾ ਭੇਜਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਬਹੁਮਤ ਪ੍ਰੀ-ਕਮਿੱਟ ਸੁਨੇਹੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਕੋਆਰਡੀਨੇਟਰ ਉਹਨਾਂ ਨੂੰ ਅੱਪਡੇਟ ਲਾਗੂ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ। ਫਿਰ ਕੋਈ ਵੀ ਅੱਪ-ਟੂ-ਡੇਟ ਰੈਪਲੀਕਾ ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਆਪਣੀ ਸਥਾਨਕ ਕਾਪੀ ਤੋਂ ਨਵੇਂ ਬ੍ਰਾਂਚ ਟਿਪ ਨੂੰ ਐਡਵਰਟਾਈਜ਼ ਕਰ ਸਕਦਾ ਹੈ।
ਪੂਰੀਆਂ ਰੈਪਲੀਕਾਵਾਂ ਰੱਖਣਾ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਰੀਡਜ਼ ਨੂੰ ਸਰਵ ਕਰਨਾ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਗਰੰਟੀ ਦਿੰਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟਾਂ ਨੂੰ ਸਾਰੇ ਰੈਫ਼ਰੈਂਸਾਂ ਦਾ ਇੱਕ ਇਕਸਾਰ ਦ੍ਰਿਸ਼ ਮਿਲੇ, ਚਾਹੇ ਉਹ ਕਿਸੇ ਵੀ ਰੈਪਲੀਕਾ ਨੂੰ ਚੁਣਨ। ਨਤੀਜੇ ਵਜੋਂ, ਰੈਫ਼ਰੈਂਸਾਂ ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਹਰੇਕ ਪੁਸ਼ ਲਈ ਰੈਪਲੀਕਾਵਾਂ ਵਿਚਕਾਰ ਰੈਫ਼ ਅੱਪਡੇਟ ਦਾ ਤਾਲਮੇਲ ਕਰਨ ਵਾਸਤੇ ਕਈ ਰਾਊਂਡ ਟ੍ਰਿਪਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਕੋਰਮ ਦੀ ਉਡੀਕ ਕਰਨ ਨਾਲ ਰੈਪਲੀਕਾ ਦੀ ਡਿਸਕ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਸੰਚਾਰ ਲੇਟੈਂਸੀ ਪੁਸ਼ ਪਾਥ ਉੱਤੇ ਆ ਜਾਂਦੀ ਹੈ। ਜਿਉਂ-ਜਿਉਂ ਰਾਈਟ ਵਾਲੀਅਮ ਵਧਦਾ ਹੈ, ਰੈਪਲੀਕਾਜ਼ ਨੂੰ ਆਉਣ ਵਾਲੇ ਪੈਕਸ ਦੇ ਨਾਲ-ਨਾਲ ਰੀਡ ਟ੍ਰੈਫਿਕ ਨੂੰ ਵੀ ਬਰਾਬਰ ਸੰਭਾਲਣਾ ਪੈਂਦਾ ਹੈ।
ਅਸੀਂ ਜਿਸ WAL-ਅਧਾਰਿਤ ਡਿਜ਼ਾਈਨ ਦਾ ਮਾਡਲ ਤਿਆਰ ਕੀਤਾ ਸੀ, ਉਸ ਵਿੱਚ Git ਸਰਵਿਸ ਰਿਪੋਜ਼ਟਰੀ ਦੇ ਅੱਪਡੇਟਾਂ ਨੂੰ ਇੱਕ ਕ੍ਰਮ ਵਿੱਚ ਰੱਖਣ ਲਈ ਬਲੌਬ ਸਟੋਰੇਜ ਵਿੱਚ ਇੱਕ ਸਾਂਝੇ ਮੈਨੀਫੈਸਟ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਕੋਈ ਸਰਵਰ ਪੁਸ਼ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਆਉਣ ਵਾਲੀ ਪੈਕਫਾਈਲ ਨੂੰ ਬਲੌਬ ਸਟੋਰ ਵਿੱਚ ਅੱਪਲੋਡ ਕਰਦਾ ਹੈ ਅਤੇ ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਆਪਣੀ ਸਥਾਨਕ ਕਾਪੀ ਵਿੱਚ ਰੈਫ਼ ਅੱਪਡੇਟ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਪੁਸ਼ ਨੂੰ ਪਬਲਿਸ਼ ਕਰਨ ਲਈ, ਇਹ ਬਲੌਬ ਸਟੋਰ ਵਿੱਚ ਮੌਜੂਦ ਸਾਂਝੇ ਮੈਨੀਫੈਸਟ ਵਿੱਚ ਇੱਕ ਐਂਟਰੀ ਜੋੜਦਾ ਹੈ ਜੋ ਰੈਫ਼ ਅੱਪਡੇਟ ਨੂੰ ਰਿਕਾਰਡ ਕਰਦੀ ਹੈ ਅਤੇ ਉਸ ਪੈਕਫਾਈਲ ਵੱਲ ਪੁਆਇੰਟ ਕਰਦੀ ਹੈ। ਫਿਰ Git ਸਰਵਰ ਇੱਕ ਕੰਪੇਅਰ-ਐਂਡ-ਸਵੈਪ ਆਪ੍ਰੇਸ਼ਨ ਰਾਹੀਂ ਮੈਨੀਫੈਸਟ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ। ਇਹ ਐਟੋਮਿਕਲੀ ਮੈਨੀਫੈਸਟ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਫਿਰ ਤਬਦੀਲੀ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਜੇਕਰ ਇਸ ਦੌਰਾਨ ਕਿਸੇ ਹੋਰ ਰਾਈਟਰ ਨੇ ਇਸਨੂੰ ਅੱਪਡੇਟ ਕਰ ਦਿੱਤਾ ਹੋਵੇ, ਤਾਂ ਸਰਵਰ ਵਿਚਕਾਰਲੀਆਂ ਐਂਟਰੀਆਂ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਇਹ ਜਾਂਚਦਾ ਹੈ ਕਿ ਉਸਦਾ ਰੈਫ਼ ਅੱਪਡੇਟ ਅਜੇ ਵੀ ਵੈਲਿਡ ਹੈ, ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਅੱਪਲੋਡ ਕੀਤੀ ਪੈਕਫਾਈਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।
ਰਾਈਟਰਜ਼ ਆਪਣੀਆਂ ਪੈਕਫਾਈਲਾਂ ਨੂੰ ਪੈਰਲਲ ਵਿੱਚ ਅੱਪਲੋਡ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਗ਼ੈਰ-ਸੰਬੰਧਿਤ ਬ੍ਰਾਂਚਾਂ ਦੇ ਪੁਸ਼ਾਂ ਲਈ ਵੀ ਉਸੇ ਸਾਂਝੇ ਮੈਨੀਫੈਸਟ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਸਫਲ ਕੰਪੇਅਰ-ਐਂਡ-ਸਵੈਪ ਦਾ ਰਾਊਂਡ-ਟ੍ਰਿਪ ਸਮਾਂ ਇਸ ਗੱਲ ਨੂੰ ਸੀਮਤ ਕਰ ਦਿੰਦਾ ਹੈ ਕਿ ਰਿਪੋਜ਼ਟਰੀ ਕਿੰਨੀ ਵਾਰ ਨਵਾਂ ਮੈਨੀਫੈਸਟ ਪਬਲਿਸ਼ ਕਰ ਸਕਦੀ ਹੈ। ਇੱਕ ਘੱਟ-ਲੇਟੈਂਸੀ ਵਾਲਾ ਬਲੌਬ ਸਟੋਰ ਇਸ ਪੜਾਅ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ। ਬੈਚਿੰਗ ਇੱਕੋ ਮੈਨੀਫੈਸਟ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਕਈ ਰੈਫ਼ਸ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਪਰ ਇਸਦੀ ਕੀਮਤ ਅੱਪਡੇਟਾਂ ਨੂੰ ਕਤਾਰਬੱਧ ਕਰਨ ਅਤੇ ਲੇਟੈਂਸੀ ਵਧਣ ਦੇ ਰੂਪ ਵਿੱਚ ਚੁਕਾਉਣੀ ਪੈਂਦੀ ਹੈ।
ਬਲੌਬ ਸਟੋਰ ਪੈਰਲਲ ਵਿੱਚ ਪੈਕਫਾਈਲਾਂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਸਾਂਝੇ ਮੈਨੀਫੈਸਟ ਵਿੱਚ ਹੋਣ ਵਾਲੇ ਅੱਪਡੇਟ ਅਜੇ ਵੀ ਇੱਕ ਦੂਜੇ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦੇ ਹਨ। ਕੇਵਲ ਬਲੌਬ ਸਟੋਰ ਦੀ ਸਮਰੱਥਾ ਵਧਾਉਣ ਨਾਲ ਇਹ ਰੁਕਾਵਟ ਹੱਲ ਨਹੀਂ ਹੁੰਦੀ। ਹਰੇਕ ਰੈਪਲੀਕਾ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸਰਵ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬਲੌਬ ਸਟੋਰ ਤੋਂ ਪੈਕਸ ਨੂੰ ਪੜ੍ਹਨ ਅਤੇ ਇੰਡੈਕਸ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਆਉਣ ਵਾਲੇ ਰਾਈਟਸ ਉਸ ਕੰਮ ਨਾਲੋਂ ਤੇਜ਼ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਰੈਪਲੀਕਾਜ਼ ਪਿੱਛੇ ਰਹਿ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕਲਾਇੰਟਾਂ ਨੂੰ ਨਵੇਂ ਪੁਸ਼ ਕੀਤੇ ਕਮਿੱਟਾਂ ਨੂੰ ਫੈਚ ਕਰਨ ਲਈ ਜ਼ਿਆਦਾ ਇੰਤਜ਼ਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
ਇਹ ਸਾਨੂੰ Pando ਵੱਲ ਲੈ ਕੇ ਆਉਂਦਾ ਹੈ। Pando Git ਰਿਪੋਜ਼ਟਰੀਆਂ ਨੂੰ ਸਰਵ ਕਰਨ ਲਈ ਇੱਕ ਨਵਾਂ ਆਰਕੀਟੈਕਚਰ ਹੈ, ਜਿਸਦਾ ਮਕਸਦ ਇੱਕੋ ਸਮੇਂ ਪੁਸ਼ ਕਰਨ ਵਾਲੇ ਕਈ ਕਲਾਇੰਟਾਂ ਤੱਕ ਸਕੇਲ ਕਰਨਾ ਹੈ। ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ:
Pando ਨੂੰ ਵਿਕਸਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਡਾ ਅੰਦਾਜ਼ਾ ਸੀ ਕਿ ਅਸੀਂ Git ਨਾਲ ਸਮਝੌਤਾ ਕੀਤੇ ਬਿਨਾਂ ਆਪਣੀਆਂ ਜ਼ਰੂਰਤਾਂ ਪੂਰੀਆਂ ਕਰ ਸਕਦੇ ਹਾਂ, ਪਰ ਸਾਨੂੰ ਉਨ੍ਹਾਂ ਕੁਝ ਚੀਜ਼ਾਂ 'ਤੇ ਜ਼ਰੂਰ ਸਮਝੌਤਾ ਕਰਨਾ ਪਿਆ ਜਿਨ੍ਹਾਂ ਨੂੰ ਜ਼ਿਆਦਾਤਰ Git ਸਿਸਟਮ ਲਾਜ਼ਮੀ ਜ਼ਰੂਰਤਾਂ ਮੰਨ ਕੇ ਚੱਲਦੇ ਹਨ:
ਰਿਪੋਜ਼ਟਰੀ-ਪੱਧਰੀ ਇਕਸਾਰਤਾ: ਸਾਰੇ ਰੈਫ਼ਰੈਂਸਾਂ ਦਾ ਇੱਕੋ ਸਮੇਂ 'ਤੇ ਇਕਸਾਰ ਸਨੈਪਸ਼ਾਟ ਮੁਹੱਈਆ ਕਰਵਾਉਣ ਲਈ ਪੂਰੀ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਤਾਲਮੇਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਅਜਿਹੇ ਸਿਸਟਮ ਵਿੱਚ ਜੋ ਸਾਰੇ ਰੈਫ਼ਰੈਂਸ ਅੱਪਡੇਟਾਂ ਨੂੰ ਇਕੱਠੇ ਤਰਤੀਬ ਦਿੰਦਾ ਹੈ, ਗ਼ੈਰ-ਸੰਬੰਧਿਤ ਬ੍ਰਾਂਚਾਂ ਵਿੱਚ ਕੀਤੀਆਂ ਗਈਆਂ ਪੁਸ਼ਾਂ ਵੀ ਇੱਕੋ ਤਾਲਮੇਲ ਬਿੰਦੂ 'ਤੇ ਆਪਸ ਵਿੱਚ ਟਕਰਾਉਂਦੀਆਂ ਹਨ।
ਹਰੇਕ ਕਲਾਇੰਟ ਲਈ ਵਿਲੱਖਣ ਪੈਕਫਾਈਲਾਂ: ਜੇਕਰ ਵੱਖ-ਵੱਖ ਲੋਕਲ ਹਿਸਟਰੀ ਵਾਲੇ ਦੋ ਕਲਾਇੰਟ ਇੱਕੋ ਬ੍ਰਾਂਚ ਨੂੰ ਫ਼ੈਚ ਕਰਦੇ ਹਨ, ਤਾਂ ਸਰਵਰ ਨੂੰ ਹਰੇਕ ਲਈ ਇੱਕ ਵੱਖਰਾ ਪੈਕ ਬਣਾਉਣਾ ਪੈ ਸਕਦਾ ਹੈ ਤਾਂ ਜੋ ਉਹ ਆਬਜੈਕਟ ਨਾ ਭੇਜੇ ਜਾਣ ਜੋ ਉਹਨਾਂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹਨ। ਇਹ ਰਿਸਪਾਂਸ ਤਿਆਰ ਕਰਨ 'ਤੇ CPU ਅਤੇ ਡਿਸਕ I/O ਖ਼ਰਚ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਕਾਰਨ ਹਾਈ ਗਿਣਤੀ ਵਿੱਚ ਪੜ੍ਹਨ ਵਾਲਿਆਂ ਲਈ ਇਸਦਾ ਸਕੇਲ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇਸਦੀ ਬਜਾਏ, Pando ਰਾਈਟਸ ਨੂੰ ਸਕੇਲ ਕਰਨ ਲਈ ਇੱਕ ਢਿੱਲਾ ਕੰਸਿਸਟੈਂਸੀ ਮਾਡਲ (ਕਾਰਜ-ਕਾਰਨ ਇਕਸਾਰਤਾ) ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਰੀਡਸ ਨੂੰ ਸਕੇਲ ਕਰਨ ਲਈ ਪੈਕਫਾਈਲਾਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।
ਜਦੋਂ ਕੋਈ ਕਲਾਇੰਟ ਕਿਸੇ ਬ੍ਰਾਂਚ ਵਿੱਚ ਪੁਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ Pando ਆਉਣ ਵਾਲੀ ਪੈਕਫਾਈਲ ਨੂੰ ਬਲੌਬ ਸਟੋਰ ਵਿੱਚ ਅਬਦਲਣਯੋਗ ਬਲੌਬ ਵਜੋਂ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਹਰ ਵਾਰ ਜਦੋਂ ਬ੍ਰਾਂਚ ਅੱਗੇ ਵਧਦੀ ਹੈ, Pando ਮੈਟਾਡਾਟਾ ਸਟੋਰ ਵਿੱਚ ਰੈਫ਼ ਵਰਜ਼ਨ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਨਵਾਂ ਟਿਪ, ਇਸਨੂੰ ਮੁਹੱਈਆ ਕਰਵਾਉਣ ਵਾਲਾ ਪੈਕ, ਅਤੇ ਕੋਈ ਵੀ ਪਿਛਲੇ ਰੈਫ਼ ਵਰਜ਼ਨ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਇਹ ਪੈਕ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਬਲੌਬ ਸਟੋਰ ਅਤੇ ਮੈਟਾਡਾਟਾ ਸਟੋਰ ਦੋਵੇਂ ਹੀ ਹਰੀਜ਼ੋਂਟਲੀ ਸਕੇਲ ਕਰਨ ਯੋਗ ਹਨ।
Pando ਤੋਂ ਕੋਈ ਕਮਿਟ ਜਾਂ ਰੈਫ਼ਰੈਂਸ ਫ਼ੈਚ ਕਰਨ ਲਈ ਕਲਾਇੰਟ ਅੱਗੇ ਰੈਫ਼ ਵਰਜ਼ਨਾਂ (ਪੈਕਫਾਈਲਾਂ) ਦੇ ਇੱਕ ਸਮੂਹ ਨੂੰ ਮੁੜ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਉਸ ਕਲਾਇੰਟ ਦੀ ਸਥਿਤੀ ਨੂੰ ਮੁੜ ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿਸਨੇ ਫ਼ੈਚ ਕੀਤੇ ਜਾ ਰਹੇ ਰੈਫ਼ ਵਰਜ਼ਨ ਨੂੰ ਬਣਾਇਆ ਸੀ। ਇਹ ਪੂਰੀ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਇਕਸਾਰਤਾ ਦਾ ਕਮਜ਼ੋਰ ਰੂਪ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਪਰ ਵਿਅਕਤੀਗਤ ਰੈਫ਼ਰੈਂਸਾਂ ਦੇ ਅੱਪਡੇਟਾਂ ਲਈ ਲੜੀਵਾਰਤਾ ਮੁਹੱਈਆ ਕਰਵਾਉਂਦਾ ਹੈ। ਕਲਾਇੰਟਾਂ ਵਿੱਚ ਟਕਰਾਅ ਸਿਰਫ਼ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਇੱਕੋ ਸਮੇਂ ਇੱਕੋ ਰੈਫ਼ 'ਤੇ ਪੁਸ਼ ਕਰਦੇ ਹਨ। ਕਈ ਬ੍ਰਾਂਚਾਂ ਨੂੰ ਰੀਡ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਇਹ ਮੰਨ ਕੇ ਨਹੀਂ ਚੱਲ ਸਕਦਾ ਕਿ ਉਹ ਰੀਡਸ ਪੂਰੀ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਕਿਸੇ ਇੱਕੋ ਸਮੇਂ ਦੀ ਸਥਿਤੀ ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ।
ਟਰੰਕ ਵਿੱਚ ਕੀਤੀ ਹਰੇਕ ਪੁਸ਼ ਇੱਕ ਵਾਧੂ ਪੈਕ ਜੋੜ ਦਿੰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਇੱਕ ਜਾਂ ਵੱਧ ਕਮਿਟ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਕਿਸੇ ਸਾਈਡ ਬ੍ਰਾਂਚ ਵਿੱਚ ਕੀਤੀ ਹਰੇਕ ਪੁਸ਼ ਉਸ ਟੌਪਿਕ ਦੇ ਪਿਛਲੇ ਕਮਿਟਾਂ ਨੂੰ ਦੁਬਾਰਾ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ, ਤਾਂ ਜੋ ਐਲਾਨੇ ਗਏ ਟਰੰਕ ਵਰਜ਼ਨ ਵਾਲਾ ਕਲਾਇੰਟ ਉਸ ਟੌਪਿਕ ਨੂੰ ਇੱਕੋ ਪੈਕ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰ ਸਕੇ।
ਇਹ ਕਾਰਜ-ਕਾਰਨ ਇਕਸਾਰਤਾ ਦਾ ਹੀ ਇੱਕ ਰੂਪ ਹੈ। ਕਿਸੇ ਰੈਫ਼ਰੈਂਸ ਨੂੰ ਫ਼ੈਚ ਕਰਨ ਲਈ, ਰੀਡਰ ਉਸ ਰਾਈਟਰ ਦੇ ਇਤਿਹਾਸ ਨੂੰ ਦੇਖਦਾ ਹੈ ਜਿਸਨੇ ਇਸਨੂੰ ਤਿਆਰ ਕੀਤਾ ਸੀ। ਪੁਸ਼ ਦੇ ਦੌਰਾਨ, Pando ਇਸ ਗੱਲ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਕਿਸ ਸਾਂਝੀ ਹਿਸਟਰੀ 'ਤੇ ਸਹਿਮਤ ਹੁੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਇਹ ਯਕੀਨੀ ਬਣਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਅਜਿਹੀਆਂ ਪੈਕਫਾਈਲਾਂ ਤਿਆਰ ਕਰਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਸਾਂਝਾ ਕੀਤਾ ਜਾ ਸਕੇ।
ਨਤੀਜੇ ਵਜੋਂ, Pando Git ਕਾਰਵਾਈਆਂ ਦੌਰਾਨ ਸਾਰੇ ਰੈਫ਼ਰੈਂਸਾਂ ਦੀ ਕਿਸੇ ਇੱਕੋ ਸਮੇਂ ਦੀ ਸਥਿਤੀ ਜਾਂ ਕਿਸੇ ਕਲੋਨ ਜਾਂ ਫ਼ੈਚ ਦੇ ਅੰਦਰ ਰੈਫ਼ ਅੱਪਡੇਟਾਂ ਦੀ ਕੋਈ ਤਰਤੀਬ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ। ਠੋਸ ਰੂਪ ਵਿੱਚ ਕਹੀਏ ਤਾਂ, ਮੰਨ ਲਓ ਕਿ ਇੱਕ ਪੂਰੇ ਕਲੋਨ ਦੇ ਤਾਲਮੇਲ ਦੌਰਾਨ foo ਅਤੇ bar ਦੋਵੇਂ ਬ੍ਰਾਂਚਾਂ ਅੱਪਡੇਟ ਹੁੰਦੀਆਂ ਹਨ। ਇਸ ਤਾਲਮੇਲ ਦੌਰਾਨ, ਇੱਕ ਕਲਾਇੰਟ foo ਨੂੰ ਵਰਜ਼ਨ 1 'ਤੇ ਅਤੇ bar ਨੂੰ ਵਰਜ਼ਨ 2 'ਤੇ ਦੇਖ ਸਕਦਾ ਹੈ, ਜਦਕਿ ਦੂਜਾ ਕਲਾਇੰਟ foo ਨੂੰ ਵਰਜ਼ਨ 2 'ਤੇ ਅਤੇ bar ਨੂੰ ਵਰਜ਼ਨ 1 'ਤੇ ਦੇਖਦਾ ਹੈ। ਅਮਲੀ ਤੌਰ 'ਤੇ, ਵਰਤੋਂਕਾਰਾਂ ਅਤੇ ਏਜੰਟਾਂ ਨੂੰ ਰੈਫ਼ ਅੱਪਡੇਟਾਂ ਦੀ ਗਲੋਬਲ ਤਰਤੀਬ ਨਾਲ ਕੋਈ ਫ਼ਰਕ ਨਹੀਂ ਪੈਂਦਾ, ਅਤੇ ਉਹ ਇਸਦੀ ਬਜਾਏ ਕਿਸੇ ਇੱਕ ਰੈਫ਼ਰੈਂਸ ਦੇ ਅੱਪਡੇਟਾਂ ਦੇ ਕ੍ਰਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।
ਇਨ੍ਹਾਂ ਤਿੰਨ ਇਕਸਾਰਤਾ ਮਾਡਲਾਂ ਦੇ ਸਿਮੂਲੇਸ਼ਨ ਵਿੱਚ, ਅਸੀਂ 1,000 ਕਲਾਇੰਟਸ ਨੂੰ ਕੌਨਫ਼ਿਗਰ ਕਰਦੇ ਹਾਂ ਤਾਂ ਜੋ ਹਰੇਕ ਕਲਾਇੰਟ ਇੱਕ ਵੱਖਰੀ ਬ੍ਰਾਂਚ ਚੁਣੇ ਅਤੇ ਫਿਰ ਵਾਰ-ਵਾਰ ਵਿਲੱਖਣ ਕਮਿਟ ਪੁਸ਼ ਕਰੇ, ਜਿਸ ਦੌਰਾਨ ਕੁੱਲ ਵਾਲ ਕਲਾਕ ਸਮਾਂ ਅਤੇ ਪੁਸ਼-ਤੋਂ-ਫ਼ੈਚ ਲੇਟੈਂਸੀ ਨੂੰ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਬਾਅਦ ਵਾਲਾ ਮੈਟ੍ਰਿਕ ਵਰਕਲੋਡਾਂ ਲਈ ਅਹਿਮ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਵਰਤੋਂਕਾਰਾਂ ਅਤੇ ਏਜੰਟਾਂ ਦੇ ਸਹਿਯੋਗ ਕਰਨ ਜਾਂ ਵਰਜ਼ਨ ਕੰਟਰੋਲ 'ਤੇ ਨਿਰਭਰ ਹੋਰ ਸਿਸਟਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਰਾਊਂਡ ਟ੍ਰਿਪ ਸਮੇਂ ਨੂੰ ਮਾਪਦਾ ਹੈ। ਇਹ ਸਿਮੂਲੇਸ਼ਨ ਸਾਧਾਰਨ ਤੋਂ ਲੈ ਕੇ ਪ੍ਰੀਮੀਅਮ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਅਤੇ ਬਲੌਬ ਸਟੋਰੇਜ ਸਿਸਟਮਾਂ ਤੱਕ ਦੇ ਹਾਰਡਵੇਅਰ ਨੂੰ ਮਾਡਲ ਕਰਦਾ ਹੈ। ਇਸ ਸਿਮੂਲੇਸ਼ਨ ਵਿੱਚ, ਅਸੀਂ ਥ੍ਰੀ-ਫ਼ੇਜ਼ ਕਮਿਟ ਲਈ ਪੂਰੀ ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਇਕਸਾਰਤਾ ਦੀ ਸ਼ਰਤ ਢਿੱਲੀ ਕੀਤੀ ਹੈ।
Simulating Git Server Implementations
Follow each writer through repeated pushes, and separately measure when an independent reader can check out each commit.
ਦੋ ਹੋਰ ਤਰੀਕਿਆਂ ਦੇ ਮੁਕਾਬਲੇ Pando ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀ ਤੁਲਨਾ ਕਰਨ ਲਈ ਇਹ ਸਿਮੂਲੇਸ਼ਨ ਚਲਾਓ। ਇਹ ਵੇਖਣ ਲਈ ਕਿ ਉਹਨਾਂ ਦੀ ਤੁਲਨਾ ਕਿਵੇਂ ਹੁੰਦੀ ਹੈ, ਆਮ ਹਾਰਡਵੇਅਰ ਤੋਂ ਲੈ ਕੇ ਪ੍ਰੀਮੀਅਮ ਹਾਰਡਵੇਅਰ, ਕਲਾਇੰਟਾਂ ਦੀ ਗਿਣਤੀ ਅਤੇ ਹੋਰ ਸੈਟਿੰਗਾਂ ਦੀ ਚੋਣ ਕਰੋ।
ਮਾਡਲ ਕੀਤਾ ਗਿਆ ਥ੍ਰੀ-ਫ਼ੇਜ਼ ਕਮਿਟ ਸਿਸਟਮ ਲੋਡ ਅਧੀਨ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਰਾਈਟ ਲੇਟੈਂਸੀ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਦੀਆਂ ਡਿਸਕਾਂ ਸੈਚੁਰੇਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ; ਇਸ ਦੌਰਾਨ, ਰਾਈਟ-ਅਹੈੱਡ ਲੌਗ ਸਿਸਟਮ ਉਸੇ ਕਾਰਨ ਕਰਕੇ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਰੀਡ ਲੇਟੈਂਸੀ ਦਰਸਾਉਂਦੇ ਹਨ, ਕਿਉਂਕਿ ਸਰਵਰ ਜਰਨਲ ਵਿੱਚੋਂ ਲਗਾਤਾਰ ਰੀਡ ਕਰਨ ਦੀ ਗਤੀ ਬਣਾਈ ਰੱਖਣ ਵਿੱਚ ਸੰਘਰਸ਼ ਕਰਦੇ ਹਨ। ਸਾਡੇ ਮੋਨੋਰਿਪੋ 'ਤੇ ਅਸਲ ਟੈਸਟਿੰਗ ਅਤੇ ਇਸ ਸਿਮੂਲੇਸ਼ਨ ਦੋਵਾਂ ਵਿੱਚ, Pando ਹਜ਼ਾਰਾਂ ਅਜਿਹੇ ਕਲਾਇੰਟਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਜੋ ਲੋਡ ਅਧੀਨ ਕਾਰਗੁਜ਼ਾਰੀ 'ਤੇ ਅਸਰ ਪਾਏ ਬਿਨਾਂ ਇੱਕੋ ਸਮੇਂ ਪੁਸ਼ ਕਰਨ ਦੇ ਯੋਗ ਹਨ।
ਕਿਸੇ ਪੁਸ਼ ਨੂੰ ਸੰਭਾਲਣ ਦੌਰਾਨ, Pando ਆਉਣ ਵਾਲੀ ਪੈਕਫਾਈਲ ਨੂੰ ਕਿਸੇ ਲੋਕਲ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਅਨਪੈਕ ਕੀਤੇ ਬਿਨਾਂ, ਬਲੌਬ ਸਟੋਰੇਜ ਵਿੱਚ ਸਟ੍ਰੀਮ ਕਰਦੇ ਹੋਏ ਹੀ ਉਸਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਕਲਾਇੰਟ ਫ਼ੈਚ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਤਾਂ Pando ਉਹ ਸਟੋਰ ਕੀਤੀਆਂ ਪੈਕਫਾਈਲਾਂ ਚੁਣਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਰੀਡਰ ਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਰੀਡਰ ਉਹਨਾਂ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰ ਲੈਂਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਸਰਵਰ ਨੂੰ ਕਿਸੇ ਲੋਕਲ ਰਿਪੋਜ਼ਟਰੀ 'ਤੇ ਪੈਕਫਾਈਲਾਂ ਲਾਗੂ ਕਰਨ ਜਾਂ ਮਹਿੰਗੇ ਅਨਪੈਕ ਅਤੇ ਪੈਕਿੰਗ ਅਪਰੇਸ਼ਨ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਕਿਉਂਕਿ ਇਹ ਸਰਵਰ ਮੁੱਖ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਤਾਲਮੇਲ ਅਤੇ ਪੈਕਫਾਈਲ ਚੋਣ ਦਾ ਕੰਮ ਹੀ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ Pando ਸਰਵਰ ਸਾਧਾਰਨ ਹਾਰਡਵੇਅਰ 'ਤੇ ਵੀ ਚੱਲ ਸਕਦੇ ਹਨ।
ਇਹ Pando ਨੂੰ ਕਲਾਇੰਟਾਂ, ਕਲਾਇੰਟਾਂ ਅਤੇ Pando ਵਿਚਕਾਰਲੇ ਨੈੱਟਵਰਕ, ਅਤੇ ਬਲੌਬ ਸਟੋਰੇਜ ਸੇਵਾ ਦੀਆਂ ਅਧਿਕਤਮ ਸੀਮਾਵਾਂ ਤੱਕ ਸਕੇਲ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਲੋੜੀਂਦੀ ਸਮਰੱਥਾ ਹੋਣ 'ਤੇ, ਸੁਤੰਤਰ ਬ੍ਰਾਂਚਾਂ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਕਲਾਇੰਟ ਆਪੋ-ਆਪਣੇ ਕੁਨੈਕਸ਼ਨ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਸਮਰੱਥਾ ਅਨੁਸਾਰ ਤੇਜ਼ੀ ਨਾਲ ਪੈਕ ਟ੍ਰਾਂਸਫ਼ਰ ਕਰ ਸਕਦੇ ਹਨ। ਉਸੇ ਗਤੀ 'ਤੇ ਹੋਰ ਜ਼ਿਆਦਾ ਕਲਾਇੰਟਾਂ ਨੂੰ ਸੇਵਾ ਦੇਣ ਲਈ, ਅਸੀਂ ਹੋਰ Pando ਸਰਵਰ ਜੋੜ ਸਕਦੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਨਾਲ ਹੀ ਮੈਟਾਡਾਟਾ ਸਟੋਰ ਅਤੇ ਬਲੌਬ ਸਟੋਰ ਨੂੰ ਵੀ ਸਕੇਲ ਕਰ ਸਕਦੇ ਹਾਂ।
Pushing and Fetching a Branch in Pando
Pando stores the writer’s packfile in blob storage and records the ref version in metadata service. On fetch, Pando selects the packs the reader needs, and Express serves them.
ਇੱਕ ਏਜੰਟ ਲੋਕਲ ਤੌਰ 'ਤੇ ਫ਼ਾਈਲਾਂ ਵਿੱਚ ਸੋਧ ਕਰਦਾ ਹੈ, ਕਮਿਟ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ git push ਚਲਾਉਂਦਾ ਹੈ, ਜੋ ਕਿਸੇ ਬ੍ਰਾਂਚ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਉਹਨਾਂ ਬਦਲਾਵਾਂ ਦੀ ਇੱਕ ਪੈਕਫਾਈਲ ਤਿਆਰ ਕਰਦਾ ਹੈ। Pando ਇਸ ਪੈਕ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਬਲੌਬ ਸਟੋਰੇਜ ਵਿੱਚ ਸਟ੍ਰੀਮ ਕਰ ਦਿੰਦਾ ਹੈ। ਸਿੰਗਲ-ਪਾਸ ਡੀਕੋਡ ਨਾਲ ਆਉਣ ਵਾਲੇ ਪੁਸ਼ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਤੋਂ ਬਾਅਦ, Pando ਸਾਡੇ ਮੈਟਾਡਾਟਾ ਸਟੋਰ ਵਿੱਚ ਰੈਫ਼ ਵਰਜ਼ਨ ਦਰਜ ਕਰਨ ਅਤੇ ਐਟੋਮਿਕਲੀ ਰੈਫ਼ ਪੁਆਇੰਟਰ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਮਲਟੀ-ਕੀ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇਹ Pando ਨੂੰ "ਰੀਡ-ਯੂਅਰ-ਓਨ-ਰਾਈਟ" ਇਕਸਾਰਤਾ ਪ੍ਰਦਾਨ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਇਸ ਸਮੁੱਚੇ ਰਾਈਟ ਆਪ੍ਰੇਸ਼ਨ ਲਈ ਮੈਟਾਡਾਟਾ ਰੀਡਸ ਅਤੇ ਰਾਈਟਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਜਦੋਂ ਕੋਈ ਹੋਰ ਕਲਾਇੰਟ ਉਸ ਬ੍ਰਾਂਚ ਨੂੰ ਫ਼ੈਚ ਕਰਦਾ ਹੈ, ਤਾਂ Pando ਕਲਾਇੰਟ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਇਤਿਹਾਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਟੋਰ ਕੀਤੇ ਪੈਕਸ ਦੇ ਸੈੱਟ ਦੀ ਚੋਣ ਕਰਦਾ ਹੈ। ਇਸ ਆਪ੍ਰੇਸ਼ਨ ਲਈ ਮੈਟਾਡਾਟਾ ਰੀਡਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਿੱਥੇ ਕਲਾਇੰਟ ਕੋਲ ਜੋ ਮੌਜੂਦ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਜੋ ਚਾਹੀਦਾ ਹੈ, ਉਹਨਾਂ ਵਿਚਕਾਰ ਰੈਫ਼ ਵਰਜ਼ਨਾਂ ਦੀ ਸਭ ਤੋਂ ਛੋਟੀ ਦੂਰੀ ਹੈ। ਸਰਵਰ ਪੈਕਫਾਈਲ URIs ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਉਹਨਾਂ ਨੂੰ Express ਨਾਮਕ ਸਰਵਿਸ ਰਾਹੀਂ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ, ਜੋ ਪੈਕਫਾਈਲਾਂ ਨੂੰ ਖੇਤਰੀ ਕੈਸ਼ਾਂ ਵਿੱਚ ਸਟੋਰ ਕਰਦੀ ਹੈ।
ਇਹ ਡਿਜ਼ਾਈਨ Pando ਦੇ ਆਰਕੀਟੈਕਚਰ ਦੀਆਂ ਤਿੰਨ ਕੇਂਦਰੀ ਸਰਵਿਸਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ: ਪੁਸ਼ਿਸ, ਫ਼ੈਚਿਸ, ਅਤੇ ਕੰਪੈਕਸ਼ਨ।
ਜਦੋਂ ਕੋਈ ਕਲਾਇੰਟ ਪੁਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਰਵਾਇਤੀ Git ਸਰਵਰ ਆਪਣੇ ਸਾਰੇ ਪੱਤੇ ਦਿਖਾਉਣ ਵਾਲੇ ਪੋਕਰ ਖਿਡਾਰੀ ਵਾਂਗ ਹੁੰਦਾ ਹੈ, ਜੋ ਕਲਾਇੰਟ ਅੱਗੇ ਆਪਣੇ ਕੋਲ ਮੌਜੂਦ ਹਰੇਕ ਬ੍ਰਾਂਚ ਦਾ ਖ਼ੁਲਾਸਾ ਕਰ ਦਿੰਦਾ ਹੈ। ਫਿਰ ਕਲਾਇੰਟ ਉਹਨਾਂ ਆਬਜੈਕਟਾਂ ਨੂੰ ਛੱਡ ਕੇ ਪੈਕਫਾਈਲ ਬਣਾਉਣ ਲਈ ਕਮਿਟਾਂ, ਟ੍ਰੀਆਂ ਅਤੇ ਬਲੌਬਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਉਸਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਸਰਵਰ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹਨ।
ਵੱਧ ਰੈਫ਼ਸ ਦੀ ਮਸ਼ਹੂਰੀ ਕਰਨ ਨਾਲ ਪੁਸ਼ ਦਾ ਆਕਾਰ ਛੋਟਾ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਪੈਕ ਦੀ ਮੁੜ ਵਰਤੋਂ ਨੂੰ ਹੋਰ ਔਖਾ ਵੀ ਬਣਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਕਿਸੇ ਹੋਰ ਕਲਾਇੰਟ ਕੋਲ ਉਹ ਆਬਜੈਕਟ ਮੌਜੂਦ ਨਾ ਹੋਣ ਜੋ ਰਾਈਟਰ ਨੇ ਛੱਡ ਦਿੱਤੇ ਸਨ।
Pando ਵੱਖਰਾ ਤਰੀਕਾ ਅਪਣਾਉਂਦਾ ਹੈ। ਆਪਣੇ ਸਾਰੇ ਪੱਤੇ ਦਿਖਾਉਣ ਦੀ ਬਜਾਏ, ਇਹ ਕਲਾਇੰਟ ਅੱਗੇ ਸਿਰਫ਼ ਚੁਣੀਆਂ ਹੋਈਆਂ ਬ੍ਰਾਂਚਾਂ ਦਾ ਹੀ ਖੁਲਾਸਾ ਕਰਦਾ ਹੈ। ਅਜਿਹਾ ਦੋ ਕਾਰਨਾਂ ਕਰਕੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:
ਹਰੇਕ ਰੈਫ਼ ਦੀ ਇਕਸਾਰ ਝਲਕ ਪ੍ਰਦਾਨ ਕਰਨਾ ਮਹਿੰਗਾ ਹੁੰਦਾ ਹੈ। ਲੱਖਾਂ ਬ੍ਰਾਂਚਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇਕੱਲੀ ਰੈਫ਼ ਐਡਵਰਟਾਈਜ਼ਮੈਂਟ ਹੀ 100 MiB ਤੋਂ ਵੱਧ ਹੋ ਸਕਦੀ ਹੈ। ਅਜਿਹਾ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਹਰੇਕ ਸਰਵਰ ਨੂੰ ਜਾਂ ਤਾਂ ਮੌਜੂਦਾ ਮੈਪਿੰਗ ਬਣਾਈ ਰੱਖਣੀ ਪੈਂਦੀ ਹੈ, ਜਿਸ ਲਈ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਤਾਲਮੇਲ ਓਵਰਹੈੱਡ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਫਿਰ ਅਜਿਹੀ ਡਾਟਾਬੇਸ ਕੁਐਰੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਰੈਫ਼ਸ ਦੀ ਗਿਣਤੀ ਦੇ ਹਿਸਾਬ ਨਾਲ ਸਕੇਲ ਕਰਦੀ ਹੈ।
ਕਲਾਇੰਟ ਨੂੰ ਰੈਫ਼ਸ ਦਾ ਸਿਰਫ਼ ਚੁਣਿਆ ਹੋਇਆ ਹਿੱਸਾ ਮੁਹੱਈਆ ਕਰਵਾ ਕੇ, ਕਲਾਇੰਟ ਅਜਿਹਾ ਪੈਕ ਤਿਆਰ ਕਰੇਗਾ ਜੋ ਸਿਰਫ਼ ਉਸੇ ਸਮੱਗਰੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਛੱਡਣ ਦੀ ਸਰਵਰ ਕਲਾਇੰਟ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇਹਨਾਂ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਟਰੈਕ ਕਰਨ ਨਾਲ Pando ਕਿਸੇ ਕਲਾਇੰਟ ਵੱਲੋਂ ਪੁਸ਼ ਦੌਰਾਨ ਬਣਾਈ ਗਈ ਪੈਕਫਾਈਲ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਆਉਣ ਵਾਲੇ ਫ਼ੈਚ ਦੇ ਜਵਾਬ ਵਜੋਂ ਦੇ ਕੇ ਮੁੜ ਵਰਤੋਂ ਯੋਗ ਬਣਾ ਲੈਂਦਾ ਹੈ।
ਜਿਉਂ-ਜਿਉਂ ਇੱਕ Git ਸਰਵਰ ਵੱਧ ਰੈਫ਼ਸ ਦੀ ਮਸ਼ਹੂਰੀ ਕਰਦਾ ਹੈ, ਪੁਸ਼ ਕਰਨ ਵਾਲੇ ਕਲਾਇੰਟਾਂ ਕੋਲ ਆਬਜੈਕਟਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖਣ ਲਈ ਵੱਧ ਸਰੋਤ ਹੁੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਉਹ ਛੋਟੇ ਪੈਕ ਤਿਆਰ ਕਰਨ ਦੇ ਯੋਗ ਹੁੰਦੇ ਹਨ। ਪਰ, ਇਹਨਾਂ ਪੈਕਫਾਈਲਾਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਨ ਲਈ ਸਰਵਰ ਵਾਸਤੇ ਇਹ ਸਾਬਤ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ ਕਿ ਫ਼ੈਚ ਕਰਨ ਵਾਲੇ ਕਲਾਇੰਟਾਂ ਕੋਲ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਨਿਰਭਰਤਾ ਮੌਜੂਦ ਹੈ। ਨਹੀਂ ਤਾਂ, ਪੈਕਫਾਈਲ ਵਿੱਚੋਂ ਸ਼ਾਇਦ ਉਹ ਆਬਜੈਕਟ ਹੀ ਛੁੱਟ ਜਾਣ ਜਿਨ੍ਹਾਂ ਦੀ ਕਲਾਇੰਟ ਨੂੰ ਲੋੜ ਹੈ।
ਦੂਜੇ ਪਾਸੇ, ਜੇਕਰ ਕੋਈ Git ਸਰਵਰ ਬਿਲਕੁਲ ਵੀ ਰੈਫ਼ਸ ਦੀ ਮਸ਼ਹੂਰੀ ਨਾ ਕਰੇ, ਤਾਂ ਕਲਾਇੰਟ ਅਜਿਹੀ ਪੈਕਫਾਈਲ ਤਿਆਰ ਕਰੇਗਾ ਜਿਸ ਵਿੱਚ ਰਿਪੋਜ਼ਟਰੀ ਦਾ ਪੂਰਾ ਇਤਿਹਾਸ ਸ਼ਾਮਲ ਹੋਵੇਗਾ। ਉਹ ਪੈਕਫਾਈਲ ਕਿਸੇ ਵੀ ਹੋਰ ਕਲਾਇੰਟ ਦੁਆਰਾ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਪਰ ਇਸਦੀ ਬਹੁਤ ਵੱਡੀ ਕੀਮਤ ਇਹ ਹੋਵੇਗੀ ਕਿ ਕਿਸੇ ਵੀ ਬ੍ਰਾਂਚ ਨੂੰ ਫ਼ੈਚ ਕਰਨਾ ਅਸਲ ਵਿੱਚ ਇੱਕ ਪੂਰਾ ਕਲੋਨ ਬਣ ਕੇ ਰਹਿ ਜਾਵੇਗਾ।
ਵੱਧ ਰੈਫ਼ਸ ਦੀ ਮਸ਼ਹੂਰੀ ਕਰਨ ਨਾਲ ਪੈਕਫਾਈਲਾਂ ਦਾ ਆਕਾਰ ਛੋਟਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਆਕਾਰ ਵਿੱਚ ਜ਼ਿਆਦਾਤਰ ਕਮੀ ਸਿਰਫ਼ ਇੱਕ ਰੈਫ਼ ਦੀ ਮਸ਼ਹੂਰੀ ਕਰਨ ਨਾਲ ਹੀ ਆ ਸਕਦੀ ਹੈ।
ਮੂਲ ਰੂਪ ਵਿੱਚ, ਜਦੋਂ ਕੋਈ ਕਲਾਇੰਟ ਨਵੀਂ ਫ਼ੀਚਰ ਬ੍ਰਾਂਚ ਪੁਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ Pando ਸਿਰਫ਼ ਨਿਰਧਾਰਿਤ ਟਰੰਕ ਬ੍ਰਾਂਚ ਨੂੰ ਹੀ ਬੇਸ ਵਜੋਂ ਐਡਵਰਟਾਈਜ਼ ਕਰਦਾ ਹੈ। ਇਹ ਐਡਵਰਟਾਈਜ਼ਮੈਂਟ ਦੇ ਆਕਾਰ ਨੂੰ ਇੱਕਸਾਰ ਰੱਖਦਾ ਹੈ ਭਾਵੇਂ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਬ੍ਰਾਂਚਾਂ ਦੀ ਗਿਣਤੀ ਵਧਦੀ ਰਹੇ, ਪਰ ਇਸਦੇ ਆਪਣੇ ਨਫ਼ੇ-ਨੁਕਸਾਨ ਹਨ। ਜਦੋਂ ਕੋਈ ਇੰਜੀਨੀਅਰ ਜਾਂ ਤਾਂ ਕਿਸੇ ਇੱਕੋ ਬ੍ਰਾਂਚ ਵਿੱਚ ਕਈ ਵਾਰ ਪੁਸ਼ ਕਰਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਫ਼ੀਚਰ ਬ੍ਰਾਂਚ ਦੇ ਉੱਪਰ ਦੂਜੀ ਫ਼ੀਚਰ ਬ੍ਰਾਂਚ ਸਟੈਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਕਲਾਇੰਟ ਨੂੰ ਟਰੰਕ ਤੋਂ ਬਾਹਰਲੀ ਹਰੇਕ ਚੀਜ਼ ਦੁਬਾਰਾ ਭੇਜਣੀ ਪੈਂਦੀ ਹੈ।
ਇਸ ਕਾਰਨ ਲਗਾਤਾਰ ਹੋਣ ਵਾਲੇ ਬ੍ਰਾਂਚ ਪੁਸ਼ ਵੱਡੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਵਾਧੂ ਆਬਜੈਕਟ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਹ ਕਲਾਇੰਟ ਦੀ ਵਾਧੂ ਬੈਂਡਵਿਡਥ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਸਾਡੇ ਮੋਨੋਰਿਪੋ ਵਿੱਚ, ਇਸ ਤਰੀਕੇ ਨਾਲ ਤਿਆਰ ਕੀਤੀ ਗਈ ਮੀਡੀਅਨ ਪੈਕਫਾਈਲ 20 KiB ਤੋਂ ਘੱਟ ਸੀ, ਅਤੇ 99ਵਾਂ ਪਰਸੈਂਟਾਇਲ 3 MiB ਤੋਂ ਘੱਟ ਸੀ। ਸਾਡੇ ਲਈ, ਇਹ ਵਾਜਬ ਸਮਝੌਤਾ ਸੀ ਕਿਉਂਕਿ ਅਜਿਹਾ ਰੀਡਰ ਜਿਸ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਐਡਵਰਟਾਈਜ਼ ਕੀਤਾ ਟਰੰਕ ਇਤਿਹਾਸ ਮੌਜੂਦ ਹੈ, ਉਹ ਸਿਰਫ਼ ਉਸ ਇੱਕ ਪੈਕਫਾਈਲ ਨਾਲ ਹੀ ਬ੍ਰਾਂਚ ਨੂੰ ਫ਼ੈਚ ਕਰ ਸਕਦਾ ਹੈ।
ਕਲਾਇੰਟ ਨੂੰ ਐਡਵਰਟਾਈਜ਼ ਕਰਨ ਲਈ ਰੈਫ਼ਸ ਦੇ ਸੈੱਟ ਦੀ ਚੋਣ ਕਰਨ ਤੋਂ ਬਾਅਦ, Pando ਪੁਸ਼ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਆਪਣੇ ਮੈਟਾਡਾਟਾ ਸਟੋਰ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ। Pando ਮੈਟਾਡਾਟਾ ਅੱਪਡੇਟ ਨੂੰ ਸਿਕ੍ਰੋਨਸ ਅਤੇ ਅਸਿੰਕ੍ਰੋਨਸ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ। ਸਿਕ੍ਰੋਨਸ ਮੈਟਾਡਾਟਾ ਅੱਪਡੇਟ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਨਵੇਂ ਅੱਪਡੇਟ ਕੀਤੇ ਕਮਿਟ ਨੂੰ ਤੁਰੰਤ ਫ਼ੈਚ ਕਰ ਸਕਣ। ਇਹ ਨਵਾਂ ਰੈਫ਼ ਵਰਜ਼ਨ ਲਿਖਦਾ ਹੈ ਅਤੇ ਉਸ ਨਵੇਂ ਵਰਜ਼ਨ ਨਾਲ ਰੈਫ਼ ਪੁਆਇੰਟਰ ਮੈਪਿੰਗ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਉਸ ਨਵੇਂ ਟਿਪ, ਪੈਕਫਾਈਲ ਨੈਗੋਸ਼ੀਏਟ ਕਰਨ ਲਈ ਵਰਤੀਆਂ ਗਈਆਂ ਨਿਰਭਰਤਾਵਾਂ, ਅਤੇ ਪੁਸ਼ ਕੀਤੀ ਗਈ ਪੈਕਫਾਈਲ ਦਾ ਲਿੰਕ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਇਸੇ ਸਮੇਂ, ਉਸੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਵਿੱਚ ਅਸਿੰਕ੍ਰੋਨਸ ਕੰਮ ਵੀ ਦਰਜ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਕੰਪੈਕਸ਼ਨ ਨੂੰ ਸ਼ਡਿਊਲ ਕਰਨਾ। ਬਹੁਤ ਵੱਡੇ ਪੁਸ਼ਾਂ ਲਈ, ਕਮਿਟਾਂ ਦਾ ਸਿਰਫ਼ ਚੁਣਿਆ ਹੋਇਆ ਹਿੱਸਾ ਹੀ ਸਿਕ੍ਰੋਨਸ ਤਰੀਕੇ ਨਾਲ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਸਾਨੂੰ ਪੁਸ਼ ਦੇ ਆਕਾਰ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ, ਮੈਟਾਡਾਟਾ ਸਟੋਰ ਵਿੱਚ ਸਿਰਫ਼ ਨਿਸ਼ਚਿਤ ਗਿਣਤੀ ਦੇ ਰੀਡ ਅਤੇ ਰਾਈਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।
ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ Pando ਸਰਵਰ ਆਪਸ ਵਿੱਚ ਅਸੰਬੰਧਿਤ ਰੈਫ਼ਸ ਦੇ ਪੁਸ਼ਾਂ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਸਵੀਕਾਰ ਕਰ ਸਕਦੇ ਹਨ। ਕੇਵਲ ਕੰਟੈਂਡਿਡ ਕੁੰਜੀ ਹੀ ਰੈਫ਼ ਪੁਆਇੰਟਰ ਹੈ, ਜਿਸਦੀ ਅਸੀਂ ਇੱਕ ਐਟੌਮਿਕ ਕੰਪੇਅਰ-ਐਂਡ-ਸਵੈਪ-ਵਰਗੇ ਓਪਰੇਸ਼ਨ ਰਾਹੀਂ ਰਾਖੀ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਹੋਰ Pando ਸਰਵਰ, ਮੈਟਾਡਾਟਾ ਸਟੋਰ ਸਕੇਲਿੰਗ ਯੂਨਿਟਸ, ਜਾਂ ਬਲੌਬ ਸਟੋਰ ਸ਼ਾਮਲ ਕਰਕੇ ਰਾਈਟ ਥਰੂਪੁੱਟ ਨੂੰ ਸਕੇਲ ਅੱਪ ਕਰ ਸਕਦੇ ਹਾਂ।
ਜਦੋਂ ਕੋਈ ਕਲਾਇੰਟ ਫ਼ੈਚ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਰਵਰ ਨੂੰ ਕਮਿਟ IDs ਦੇ ਦੋ ਸੈੱਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਮੌਜੂਦਾਅਤੇ ਲੋੜੀਂਦੇਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਰਵਾਇਤੀ Git ਸਰਵਰ ਵਿੱਚ, ਸਰਵਰ ਮੌਜੂਦਾ ਕਮਿਟਾਂ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਆਬਜੈਕਟਾਂ ਅਤੇ ਲੋੜੀਂਦੇ ਕਮਿਟਾਂ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਆਬਜੈਕਟਾਂ ਵਿਚਕਾਰ ਸੈੱਟ ਅੰਤਰ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਕੰਪ੍ਰੈੱਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਤੀਜਾ ਕਲਾਇੰਟ ਨੂੰ ਭੇਜਦਾ ਹੈ। ਹਾਲਾਂਕਿ ਓਪਨ-ਸੋਰਸ Git ਸਰਵਰ ਕੋਲ ਇਸ ਓਪਰੇਸ਼ਨ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਇੰਡੈਕਸ ਹੁੰਦੇ ਹਨ, ਪਰ ਇਹਨਾਂ ਪੈਕਫਾਈਲਾਂ ਦੀ ਗਣਨਾ ਕਰਨਾ ਕਾਫ਼ੀ ਮਹਿੰਗਾ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਕੈਸ਼ ਕਰਨਾ ਆਮ ਤੌਰ 'ਤੇ ਔਖਾ ਹੁੰਦਾ ਹੈ।
ਇਸ ਦੀ ਬਜਾਏ, Pando ਕਲਾਇੰਟ ਦੇ ਮੌਜੂਦਾਅਤੇ ਲੋੜੀਂਦੇਕਮਿਟਾਂ ਨੂੰ ਲੱਭਣ ਲਈ ਪੁਸ਼ ਵੇਲੇ ਦਰਜ ਕੀਤੀਆਂ ਗਈਆਂ ਕਮਿਟ ਮੈਪਿੰਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਅਜਿਹੇ ਰੈਫ਼ ਵਰਜ਼ਨਾਂ ਦੇ ਸੈੱਟ ਵਿੱਚ ਰਿਜ਼ੌਲਵ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਉਹ ਕਮਿਟ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਰੈਫ਼ ਵਰਜ਼ਨ ਪਹਿਲਾਂ Pando ਵੱਲੋਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਗਈ ਇੱਕ ਪੈਕਫਾਈਲ ਨਾਲ ਲਿੰਕ ਹੁੰਦਾ ਹੈ। ਸਰਵਰ ਇਸਦੀ ਵਰਤੋਂ ਇਹ ਹੱਲ ਕਰਨ ਲਈ ਕਰਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਨੂੰ ਕਿਸ ਚੀਜ਼ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਪੈਕਫਾਈਲਾਂ ਦੀ ਚੋਣ ਕਰਦਾ ਹੈ ਜੋ ਕਲਾਇੰਟ ਵੱਲੋਂ ਮੰਗੇ ਗਏ ਆਬਜੈਕਟਾਂ ਦੇ ਸੈੱਟ ਨੂੰ ਕਵਰ ਕਰਦੀਆਂ ਹਨ।
Planning fetches in Pando
Pando compares what a client has with what it wants, then selects the stored packfiles needed—including any missing branch dependencies.
Fetch 27 trunk packs.
Select a branch to include its trunk dependencies.
Pando Git ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਕਮਿਟਾਂ ਅਤੇ ਲੋੜੀਂਦੇ ਕਮਿਟਾਂ ਨੂੰ ਰੈਫ਼ ਵਰਜ਼ਨਾਂ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਮੈਪ ਕਰਦਾ ਹੈ। ਕਿਸੇ ਸਾਈਡ ਬ੍ਰਾਂਚ ਦੀ ਮੰਗ ਕਰਨ ਦਾ ਮਤਲਬ ਟਰੰਕ ਉੱਪਰ ਉਸਦੀਆਂ ਨਿਰਭਰਤਾਵਾਂ ਤੱਕ ਦੀ ਮੰਗ ਕਰਨਾ ਹੁੰਦਾ ਹੈ।
Git ਪ੍ਰੋਟੋਕੋਲ ਕਲੋਨ ਜਾਂ ਫ਼ੈਚ ਵੇਲੇ HTTP ਰਿਸਪੌਂਸ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਪੈਕਫਾਈਲ ਭੇਜਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਪਰ, Git ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਅਣਗੌਲਿਆ ਫੀਚਰ, packfile-uri ਸਰਵਰ ਨੂੰ ਵਾਧੂ ਪੈਕ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਡਾਊਨਲੋਡ ਕਰਨ ਲਈ ਲਿੰਕ ਭੇਜਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। Pando ਸਿਰਫ਼ ਇਸੇ ਦੀ ਹੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਨਲਾਈਨ ਇੱਕ ਖਾਲੀ ਪੈਕਫਾਈਲ ਭੇਜਦਾ ਹੈ। ਇਸ ਫ਼ੀਚਰ ਨੂੰ ਸਮਰਥਨ ਦੇਣ ਲਈ, OpenAI ਨੇ ਅੱਪਸਟ੍ਰੀਮ packfile-uri ਵਿੱਚ ਕਈ ਸੁਧਾਰਾਂ ਦਾ ਯੋਗਦਾਨ ਪਾਇਆ।
OpenAI ਸਿਸਟਮ ਕਈ ਭੂਗੋਲਿਕ ਖੇਤਰਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਅਸੀਂ ਹਰੇਕ ਖੇਤਰ ਵਿੱਚ ਲੋਕਲ ਕੈਸ਼ ਵਾਲੇ Pando ਕਲੱਸਟਰ ਬਣਾ ਕੇ ਰੱਖਦੇ ਹਾਂ। ਇੱਕ ਪੈਕ ਡਿਲੀਵਰੀ ਸਰਵਿਸ, Express, ਸਾਡੇ ਬਲੌਬ ਸਟੋਰ ਨੂੰ ਕੈਸ਼ ਕਰਦੀ ਹੈ, ਅਤੇ ਵੱਖਰੀ ਸਰਵਿਸ ਮੈਟਾਡਾਟਾ ਸਟੋਰ ਨੂੰ ਕੈਸ਼ ਕਰਦੀ ਹੈ। ਇਹ ਕੈਸ਼ Pando ਨੂੰ ਕਿਸੇ ਕਮਿਟ ID ਜਾਂ ਕਿਸੇ ਰੈਫ਼ ਦੀ ਖਾਸ ਰੀਡ ਲਈ ਆਈਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਉਸੇ ਕਲੱਸਟਰ ਵਿਚਲੀ ਕੈਸ਼ ਕੀਤੀ ਸਥਿਤੀ ਤੋਂ ਹੀ ਸਰਵ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ। ਅਸੀਂ ਪੈਕਫਾਈਲ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ Express ਸਰਵਰਾਂ ਵੱਲ ਰੂਟ ਕਰਨ ਲਈ ਇਕਸਾਰ ਹੈਸ਼ਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਜਿਸਦੀ ਕੈਸ਼ ਹਿੱਟ ਦਰ 99% ਤੋਂ ਵੱਧ ਹੈ।
ਕੈਸ਼ਾਂ ਦਾ ਇਹ ਸਿਸਟਮ ਬਹੁਤ ਹਾਈ ਥਰੂਪੁੱਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜੋ ਕਲਾਇੰਟਾਂ ਅਤੇ Pando ਵਿਚਕਾਰ ਨੈੱਟਵਰਕ ਸੀਮਾ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੰਤ੍ਰਿਪਤ ਕਰਨ ਦੇ ਸਮਰੱਥ ਹੈ। ਇਹਨਾਂ ਪੈਕਫਾਈਲ URIs ਅਤੇ ਲੋਕਲ ਕੈਸ਼ਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਅਸੀਂ ਪੁਸ਼ਟੀ ਕੀਤੀ ਹੈ ਕਿ ਸਿਰਫ਼ ਸਟੈਂਡਰਡ ਕਲਾਊਡ ਪ੍ਰੋਵਾਈਡਰ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਦੀ ਵਰਤੋਂ ਨਾਲ ਕਲੋਨ ਅਤੇ ਫ਼ੈਚ ਓਪਰੇਸ਼ਨ 10 Gbps ਦੇ ਨੈੱਟਵਰਕ ਲਿੰਕਾਂ ਨੂੰ ਪੂਰੀ ਸਮਰੱਥਾ ਤੱਕ ਪਹੁੰਚਾ ਦਿੰਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ Git ਸਰਵਰਾਂ ਲਈ, ਲਗਾਤਾਰ ਵੱਧ ਰਹੀ ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਵਾਸਤੇ ਰੀਪੈਕਿੰਗ ਅਤੇ ਗਾਰਬੇਜ ਕੁਲੈਕਸ਼ਨ ਬਹੁਤ ਜ਼ਰੂਰੀ ਹੁੰਦੇ ਹਨ। ਇਹ ਦੋਵੇਂ ਪੜਾਅ ਸਪੇਸ ਨੂੰ ਖਾਲੀ ਕਰਦੇ ਹਨ, ਪਰ ਇਹ ਕੰਪਿਊਟ ਅਤੇ I/O ਪੱਖੋਂ ਬਹੁਤ ਭਾਰੀ ਹੁੰਦੇ ਹਨ।
OpenAI ਦੇ ਮੋਨੋਰਿਪੋ ਵਰਗੀ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ ਰਹੀ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ, ਪਿਛਲੇ ਫ਼ੈਚ ਤੋਂ ਬਾਅਦ ਹੋਏ ਹਰ ਪੁਸ਼ ਲਈ ਵੱਖਰੀ ਪੈਕਫਾਈਲ URI ਭੇਜਣਾ ਅਸੰਭਵ ਹੈ। ਹਰ ਰੋਜ਼, ਇੱਕ ਕਲਾਇੰਟ ਨੂੰ ਆਪਣੇ ਟਰੰਕ ਨੂੰ ਅੱਪਡੇਟ ਰੱਖਣ ਲਈ ਹਜ਼ਾਰਾਂ-ਲੱਖਾਂ ਪੈਕਫਾਈਲਾਂ ਡਾਊਨਲੋਡ ਕਰਨੀਆਂ ਪੈਣਗੀਆਂ।
ਇਸ ਦੀ ਬਜਾਏ, Pando ਇਸ ਓਵਰਹੈੱਡ ਨੂੰ ਘਟਾਉਣ ਲਈ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਪੈਕਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ, ਜਿਸ ਲਈ ਲੌਗ-ਸਟ੍ਰਕਚਰਡ ਮਰਜ-ਟ੍ਰੀਜ਼ ਵਿੱਚ ਕੰਪੈਕਸ਼ਨ ਵਰਗਾ ਡਿਜ਼ਾਈਨ ਅਪਣਾਇਆ ਗਿਆ ਹੈ। ਹਰੇਕ ਪੁਸ਼ ਅਜਿਹੀ ਪੈਕਫਾਈਲ ਬਣਾਉਂਦਾ ਹੈ ਜਿਸਨੂੰ Pando "L0" ਪੈਕਫਾਈਲ ਕਹਿੰਦਾ ਹੈ, ਜੋ ਕਿ Pando ਵੱਲੋਂ ਟਰਾਂਸਮਿਟ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਡਾਟੇ ਦੀ ਸਭ ਤੋਂ ਛੋਟੀ ਇਕਾਈ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ। ਸਮੇਂ ਦੇ ਨਾਲ, ਬੈਕਗ੍ਰਾਊਂਡ ਵਰਕਰ ਇਹਨਾਂ ਪੈਕਫਾਈਲਾਂ ਨੂੰ ਰੈਫ਼ ਵਰਜ਼ਨਾਂ ਦੇ ਇੱਕ ਕ੍ਰਮ ਨੂੰ ਕਵਰ ਕਰਨ ਵਾਲੇ ਕਵਰਾਂ ਵਿੱਚ ਇਕੱਠਾ ਕਰਦੇ ਹਨ, ਜੋ L0 ਤੋਂ ਜਿਓਮੈਟ੍ਰਿਕ ਤੌਰ 'ਤੇ ਵਧਦੇ ਹਨ। ਅੱਜ, ਸਾਡਾ ਮੋਨੋਰਿਪੋ L4 ਤੱਕ ਦੇ ਪੈਕਫਾਈਲ ਕਵਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।
ਇਹ ਕਵਰ ਦੋਹਰਾ ਮਕਸਦ ਪੂਰਾ ਕਰਦੇ ਹਨ। ਕਿਸੇ ਕਵਰ ਦੇ ਕਾਫ਼ੀ ਭਰ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਕੰਪੈਕਸ਼ਨ ਵਰਕਰ ਇਸਨੂੰ ਲੈਂਦਾ ਹੈ ਅਤੇ ਸਿੰਗਲ ਪੈਕਫਾਈਲ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਇਹ ਪੈਕਫਾਈਲ ਦੇ ਅੰਦਰ ਆਬਜੈਕਟਾਂ ਨੂੰ ਮੁੜ-ਸੰਗਠਿਤ ਕਰਕੇ ਕੰਪ੍ਰੈਸ਼ਨ ਅਨੁਪਾਤ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦਾ ਹੈ। ਪਰ ਇਹ ਰੈਫ਼ ਵਰਜ਼ਨਾਂ ਉੱਤੇ ਇੱਕ ਸਕਿੱਪ ਲਿਸਟ ਵਜੋਂ ਕੰਮ ਕਰਕੇ ਫ਼ੈਚ ਨੈਗੋਸ਼ੀਏਸ਼ਨ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਵੀ ਬਿਹਤਰ ਬਣਾਉਂਦਾ ਹੈ। ਹਰੇਕ ਲੈਵਲ 'ਤੇ ਇੰਡੈਕਸਾਂ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਸਕੈਨ ਕਰਕੇ, Pando ਲੌਗਰਿਦਮਿਕ ਸਮੇਂ ਵਿੱਚ ਕਲਾਇੰਟ ਨੂੰ ਭੇਜਣ ਲਈ ਪੈਕਾਂ ਦੇ ਸੈੱਟ ਦੀ ਚੋਣ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਪੈਕਫਾਈਲ ਕਵਰ, ਚਾਹੇ ਰੀਪੈਕ ਕੀਤੇ ਹੋਣ ਜਾਂ ਨਾ, ਫ਼ੈਚ ਪਲਾਨਿੰਗ ਲਈ ਵਧੇਰੇ ਕੁਸ਼ਲ ਹੱਲ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ Pando ਲਈ ਥਰੂਪੁੱਟ ਅਤੇ ਲੇਟੈਂਸੀ ਦੋਵਾਂ ਦੀਆਂ ਲੋੜਾਂ ਘਟ ਜਾਂਦੀਆਂ ਹਨ।
Compaction in Pando
Small packfiles are grouped into larger covers across levels, improving compression and speeding up fetches.
ਕੰਪੈਕਸ਼ਨ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਕਈ ਰੈਫ਼ ਵਰਜ਼ਨਾਂ ਤੋਂ ਪੈਕਫਾਈਲਾਂ ਨੂੰ ਆਪਸ ਵਿੱਚ ਜੋੜਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਘੱਟ ਫਾਈਲਾਂ ਰਾਹੀਂ ਫੈਚ ਵਧੇਰੇ ਕੁਸ਼ਲ ਬਣ ਜਾਂਦੇ ਹਨ।
ਕਈ Git ਸਰਵਰਾਂ ਦੇ ਉਲਟ, ਪੈਕਫਾਈਲਾਂ ਨੂੰ ਹਰੇਕ ਲੈਵਲ 'ਤੇ ਸੰਭਾਲ ਕੇ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਹਟਾਇਆ ਜਾਂ ਗਾਰਬੇਜ ਕੁਲੈਕਟ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ। ਕਲਾਇੰਟਾਂ ਵੱਲੋਂ ਫ਼ੈਚ ਵਿੱਚ ਬੇਨਤੀ ਕੀਤੇ ਮੌਜੂਦਾਅਤੇ ਲੋੜੀਂਦੇਕਮਿਟਾਂ ਦੇ ਆਧਾਰ 'ਤੇ, ਹਰੇਕ ਲੈਵਲ ਦੇ ਪੈਕਾਂ ਦੀ ਵਰਤੋਂ ਉਹਨਾਂ ਨੂੰ ਲਗਾਤਾਰ ਸਰਵ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਅਤੇ Pando ਨੂੰ ਇੱਕ API ਵਜੋਂ ਵਰਤਣ ਵਾਲੇ ਕਲਾਇੰਟਾਂ ਲਈ, ਕਿਸੇ ਪੈਕਫਾਈਲ ਵਿੱਚੋਂ ਕਿਸੇ ਵੀ ਮਨਮਰਜ਼ੀ ਦੇ ਆਬਜੈਕਟ ਨੂੰ ਪੜ੍ਹਨ ਲਈ ਆਮ ਤੌਰ 'ਤੇ L4 ਦੇ ਮੁਕਾਬਲੇ L0 ਵਿੱਚੋਂ ਘੱਟ ਡਾਟਾ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਇਸਦੇ ਕੰਪ੍ਰੈੱਸ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੁੰਦੀ ਹੈ।
Pando ਵਿੱਚ ਕੰਪੈਕਸ਼ਨ ਕਲਾਇੰਟਾਂ ਨੂੰ ਭੇਜੇ ਜਾਣ ਵਾਲੇ ਕੁੱਲ ਟਰਾਂਸਫਰ ਸਾਈਜ਼ ਨੂੰ ਕਾਫ਼ੀ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਪੈਕ ਪਲਾਨਿੰਗ ਨੂੰ ਇਸ ਗੱਲ ਦੇ ਆਧਾਰ 'ਤੇ ਸਬ-ਲੀਨੀਅਰ ਢੰਗ ਨਾਲ ਸਕੇਲ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਕਿੰਨਾ ਪਿੱਛੇ ਹੈ। ਇਹ ਵੱਡੀਆਂ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ ਰਹੀਆਂ ਰਿਪੋਜ਼ਟਰੀਆਂ ਲਈ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਜਿਨ੍ਹਾਂ ਦੇ ਅਸੀਂ ਸਾਫਟਵੇਅਰ ਡਿਵੈਲਪਮੈਂਟ ਵਿੱਚ ਨਵਾਂ ਆਮ ਰੁਝਾਨ ਬਣਨ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਾਂ।
ਅਸੀਂ Codex ਦੀ ਮਦਦ ਨਾਲ Pando ਨੂੰ ਤਿਆਰ ਕੀਤਾ, ਅਤੇ ਸ਼ੁਰੂਆਤ ਤੋਂ ਲੈ ਕੇ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਦਾ ਇਹ ਸਫ਼ਰ ਸਿਰਫ਼ 10 ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਪੂਰਾ ਕੀਤਾ। Pando ਦਾ ਮੁੱਖ ਹਿੱਸਾ ਇੱਕ ਇਕੱਲੇ ਇੰਜੀਨੀਅਰ ਵੱਲੋਂ ਡਿਜ਼ਾਈਨ, ਏਜੰਟਾਂ ਦੀਆਂ ਟੀਮਾਂ ਦੁਆਰਾ ਲਾਗੂ, ਅਤੇ ਮੁੱਠੀ ਭਰ ਇੰਜੀਨੀਅਰਾਂ ਵੱਲੋਂ ਡਿਪਲੋਏ ਕੀਤਾ ਗਿਆ ਸੀ। Pando ਨੇ ਇਸੇ ਸਾਲ ਅਪ੍ਰੈਲ ਵਿੱਚ ਪ੍ਰੋਡਕਸ਼ਨ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਸਰਵ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਅਤੇ ਇਹ OpenAI ਵਿਖੇ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸੋਰਸ ਕੰਟਰੋਲ ਮੈਨੇਜਮੈਂਟ ਟੂਲਜ਼ ਦੇ ਇੱਕ ਵੱਡੇ ਸਿਸਟਮ ਦਾ ਇੱਕ ਹਿੱਸਾ ਹੈ।
ਅਸੀਂ Pando ਦੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਵੇਲੇ ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਤਰੀਕੇ ਅਪਣਾਏ। ਅਸੀਂ ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ ਸਾਫਟਵੇਅਰ ਨੀਂਹਾਂ ਤਿਆਰ ਕਰਨ ਲਈ ਆਪਣੇ ਸਿਧਾਂਤਾਂ ਨੂੰ ਲਾਗੂ ਕੀਤਾ। ਇੱਕ ਬਿਲਕੁਲ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਵਜੋਂ, ਅਸੀਂ Pando ਨੂੰ Rust ਵਿੱਚ ਅਤੇ ਪੁਰਾਣੀਆਂ ਨਿਰਭਰਤਾਵਾਂ ਤੋਂ ਬਿਨਾਂ ਲਾਗੂ ਕਰਨ ਦਾ ਫ਼ੈਸਲਾ ਕੀਤਾ। ਅਸੀਂ ਕਨਫਾਰਮੈਂਸ ਟੈਸਟ ਸੂਟ ਲਿਖਿਆ ਤਾਂ ਜੋ ਏਜੰਟ ਸਟੈਂਡਰਡ Git ਵਿਹਾਰ ਦੇ ਮੁਕਾਬਲੇ ਆਪਣੀਆਂ ਤਬਦੀਲੀਆਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕਣ। ਅਸੀਂ ਡਿਟਰਮਿਨਿਸਟਿਕ ਸਿਮੂਲੇਸ਼ਨ ਟੈਸਟਿੰਗ ਜਾਂਚ-ਢਾਂਚਾ ਵੀ ਵਿਕਸਿਤ ਕੀਤੇ ਜਿਨ੍ਹਾਂ ਨੇ ਸਾਨੂੰ ਸਿਸਟਮ ਦੇ ਇਨਵੇਰੀਐਂਟਸ ਅਤੇ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ, ਜਿਸ ਨਾਲ ਅਸੀਂ ਨੈਗੋਸ਼ੀਏਸ਼ਨ ਅਤੇ ਪੈਕ ਪਲਾਨਿੰਗ ਵਿੱਚ ਬਾਰੀਕ ਰੇਸ ਕੰਡੀਸ਼ਨਾਂ ਅਤੇ ਰਿਗ੍ਰੈਸ਼ਨਾਂ ਨੂੰ ਲੱਭਣ ਅਤੇ ਘਟਾਉਣ ਦੇ ਯੋਗ ਹੋ ਸਕੇ।
ਕਈ ਮਾਡਲਾਂ ਨੇ ਇਸ ਸਿਸਟਮ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਇਆ; ਜਿਵੇਂ-ਜਿਵੇਂ ਨਵੇਂ ਮਾਡਲ ਉਪਲਬਧ ਹੁੰਦੇ ਗਏ, ਅਸੀਂ Pando ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ। GPT‑6 Astra ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਏਜੰਟਾਂ ਨੇ "Pando ਦਾ ਸਿਧਾਂਤ" ਨੂੰ ਰਸਮੀ ਰੂਪ ਦੇਣ ਲਈ Lean ਅਤੇ TLA+ ਲਿਖਿਆ, ਜਿਸਦੀ ਵਰਤੋਂ ਅਸੀਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਵਿੱਚ ਬੱਗ ਲੱਭਣ ਅਤੇ ਠੀਕ ਕਰਨ, ਅਤੇ ਸਿਸਟਮ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਸਿੱਧ ਕਰਨ ਲਈ ਕੀਤੀ। Pando ਵਿੱਚ ਐੱਜ ਕੇਸਾਂ ਨੂੰ ਲੱਭਣ ਅਤੇ ਠੀਕ ਕਰਨ ਲਈ ਸੈਂਕੜੇ ਘੰਟਿਆਂ ਤੱਕ ਲਗਾਤਾਰ ਕਈ ਸੈਸ਼ਨ ਚੱਲੇ। ਅਸੀਂ Daybreak-ਸਮਰੱਥ ਮਾਡਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ Git ਅਤੇ Pando ਦੀ ਰੈੱਡ-ਟੀਮਿੰਗ ਕਰਨ ਲਈ 24 ਘੰਟੇ ਏਜੰਟ ਵੀ ਚਲਾਉਂਦੇ ਹਾਂ।
Pando ਦੀ ਸਾਡੀ ਸ਼ੁਰੂਆਤੀ ਡਿਪਲੋਇਮੈਂਟ ਸਾਡੇ ਮੌਜੂਦਾ ਸੋਰਸ ਕੰਟਰੋਲ ਸਿਸਟਮ ਲਈ ਇੱਕ ਰੀਡ- ਅਤੇ ਰਾਈਟ-ਥਰੂ ਪ੍ਰੌਕਸੀ ਵਜੋਂ ਸੀ। ਇਸਨੇ ਸਾਨੂੰ Pando ਅਤੇ ਪਿਛਲੇ ਸਿਸਟਮ ਨੂੰ ਆਪਸ ਵਿੱਚ ਸਿੰਕ ਰੱਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ, ਤਾਂ ਜੋ ਅਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਡਾਊਨਟਾਈਮ ਦੇ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ Pando ਉੱਤੇ ਮੂਵ ਕਰ ਸਕੀਏ।
ਆਪਣੇ ਕੈਸ਼ਿੰਗ ਡਿਜ਼ਾਈਨ ਦੇ ਹਿੱਸੇ ਵਜੋਂ, Pando ਪ੍ਰੌਕਸੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬੇਨਤੀਆਂ ਨੂੰ ਡੀਡੁਪਲੀਕੇਟ ਅਤੇ ਕੰਬਾਈਨ ਵੀ ਕਰ ਸਕਦਾ ਹੈ। ਇਸਨੇ ਸਾਨੂੰ ਆਪਣੇ ਮੌਜੂਦਾ ਟੂਲਜ਼ ਨੂੰ ਸੁਚਾਰੂ ਰੱਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਜਦੋਂ ਅਸੀਂ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਸਿਸਟਮਾਂ ਨੂੰ Pando ਉੱਤੇ ਮੂਵ ਕਰ ਰਹੇ ਸੀ। ਜਿਵੇਂ-ਜਿਵੇਂ ਅਸੀਂ ਹੋਰ ਵਰਕਲੋਡਾਂ ਨੂੰ Pando ਉੱਤੇ ਮਾਈਗ੍ਰੇਟ ਕੀਤਾ, ਉਹਨਾਂ ਦੇ ਪੁਸ਼ਾਂ ਨੇ Pando ਦੇ ਕੈਸ਼ੇ ਨੂੰ ਭਰ ਦਿੱਤਾ ਅਤੇ ਸਾਡੇ ਪਿਛਲੇ ਬੈਕਐਂਡ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕੀਤਾ।
Pando ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ, ਅਸੀਂ Git ਦੀ ਆਪਣੀ ਪਬਲਿਕ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਨੂੰ ਡਿਵੈਲਪਰ ਮਸ਼ੀਨਾਂ ਅਤੇ ChatGPT ਡੈਸਕਟੌਪ ਐਪ ਦੇ ਅੰਦਰ ਭੇਜਣਾ ਸ਼ੁਰੂ ਕੀਤਾ। ਕਲਾਇੰਟਾਂ ਨੂੰ Pando ਉੱਤੇ ਪੜਾਅਵਾਰ ਢੰਗ ਨਾਲ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਲਈ, ਅਸੀਂ Git CLI ਦੁਆਲੇ ਅੰਦਰੂਨੀ ਰੈਪਰ ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਅਸੀਂ ਤਬਦੀਲੀ ਦੀਆਂ ਬੇਨਤੀਆਂ, ਕੋਡ ਸਮੀਖਿਆ, ਅਤੇ ਆਟੋਮੇਸ਼ਨਾਂ ਲਈ API ਸੰਭਾਲਣ ਵਾਸਤੇ ਕਈ ਹੋਰ ਟੂਲ ਤਿਆਰ ਕੀਤੇ। ਅਸੀਂ Git ਟ੍ਰੈਫ਼ਿਕ ਦੇ ਨਾਲ-ਨਾਲ ਪੁਰਾਣੇ API, ਵੈੱਬਹੁੱਕਸ, ਅਤੇ ਰਿਪੋਜ਼ਟਰੀ ਡਾਊਨਲੋਡਾਂ 'ਤੇ ਨਿਰਭਰ ਸੈਂਕੜੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਮਾਈਗ੍ਰੇਟ ਕੀਤਾ।
Codex ਨੇ ਖ਼ੁਦ ਡਿਵੈਲਪਰਾਂ ਅਤੇ ਟੀਮਾਂ ਨੂੰ ਇਹ ਬਦਲਾਅ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕੀਤੀ। ਅਸੀਂ ਮੌਜੂਦਾ ਚੈੱਕਆਊਟਾਂ ਨੂੰ ਤਿਆਰ ਕਰਨ ਅਤੇ ਨਵੇਂ ਸਿਸਟਮ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਏਜੰਟਾਂ ਦੀ ਅਗਵਾਈ ਵਾਸਤੇ ਸਕਿੱਲਜ਼ ਬਣਾਏ। ਸਿੱਟੇ ਵਜੋਂ, ਡਿਵੈਲਪਰ ਆਪਣੇ ਡਿਵੈਲਪਮੈਂਟ ਇਨਵਾਇਰਨਮੈਂਟਸ ਅਤੇ ਸਰਵਿਸਿਜ਼ ਨੂੰ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਲਈ ਸਿਰਫ਼ Codex ਨੂੰ ਕਹਿ ਸਕਦੇ ਸਨ।
Pando ਉੱਤੇ ਸਵਿੱਚ ਕਰਨ ਨਾਲ ਮਰਜ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਵਿੱਚ ਸੁਧਾਰ ਹੋਇਆ ਅਤੇ ਔਸਤ ਪੁਸ਼ ਦੀ ਲੇਟੈਂਸੀ ਲਗਭਗ 80% ਤੱਕ ਘਟ ਗਈ।
Pando ਸਿਰਫ਼ ਮੁੱਠੀ ਭਰ CPU ਕੋਰਾਂ ਨਾਲ ਪ੍ਰਤੀ ਦਿਨ ਇੱਕ ਪੇਟਾਬਾਈਟ Git ਡਾਟਾ ਡਿਲੀਵਰ ਕਰ ਸਕਦਾ ਹੈ। Pando ਨੇ ਇੱਕੋ ਘੰਟੇ ਵਿੱਚ 57 ਟੈਰਾਬਾਈਟ ਤੋਂ ਵੱਧ Git ਪੈਕ ਸਰਵ ਕੀਤੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ 99% ਤੋਂ ਵੱਧ ਬਾਈਟਸ ਲੋਕਲ ਡਿਸਕ ਕੈਸ਼ ਵਿੱਚੋਂ ਆਏ ਸਨ।
ਪੈਕਾਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਨ ਨਾਲ ਕਈ ਕਲਾਇੰਟਾਂ ਨੂੰ ਸਰਵਿੰਗ ਨੋਡਾਂ 'ਤੇ ਬਹੁਤ ਘੱਟ ਕੰਪਿਊਟੇਸ਼ਨ ਨਾਲ ਉਹੀ ਰਿਪੋਜ਼ਟਰੀ ਹਿਸਟਰੀ ਡਾਊਨਲੋਡ ਕਰਨ ਦੀ ਸੁਵਿਧਾ ਮਿਲਦੀ ਹੈ। ਇਹ ਉਦਾਹਰਨ ਇੱਕ ਸਿੰਗਲ ਰਿਪੋਜ਼ਟਰੀ ਦਿਖਾਉਂਦੀ ਹੈ, ਪਰ Pando ਨੂੰ ਹੋਰ ਬਹੁਤ ਸਾਰੀਆਂ ਰਿਪੋਜ਼ਟਰੀਆਂ ਨੂੰ ਸਪੋਰਟ ਕਰਨ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ। ਜਿਵੇਂ-ਜਿਵੇਂ ਮੰਗ ਵਧਦੀ ਹੈ, ਅਸੀਂ ਡਾਟਾ ਡਿਲੀਵਰੀ ਅਤੇ Git ਨੈਗੋਸ਼ੀਏਸ਼ਨ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਸਕੇਲ ਕਰ ਸਕਦੇ ਹਾਂ।
Pando ਨੂੰ Git ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਕਲਾਇੰਟ ਉੱਤੇ ਤਿਆਰ ਕਰਨ ਨਾਲ ਸਾਨੂੰ ਬੱਗਾਂ ਦੀ ਪਛਾਣ ਕਰਨ ਅਤੇ Git ਦੀ ਆਪਣੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਦੇ ਮੌਕੇ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਮਿਲੀ।
ਉਦਾਹਰਨ ਵਜੋਂ, Pando ਮੁੜ ਵਰਤੋਂ ਯੋਗ ਪੈਕ ਸਿੱਧੇ ਕਲਾਇੰਟਾਂ ਨੂੰ ਸਰਵ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਉਹਨਾਂ ਪੈਕਾਂ ਨੂੰ ਡਾਊਨਲੋਡ ਅਤੇ ਇੰਡੈਕਸ ਕਰਨਾ ਸਿਸਟਮ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਦਾ ਇੱਕ ਅਹਿਮ ਹਿੱਸਾ ਬਣ ਗਿਆ। ਇਸ ਕੰਮ ਨੇ ਕਨਕਰੰਟ ਡਾਊਨਲੋਡਾਂ, ਅਧੂਰੇ ਟ੍ਰਾਂਸਫਰਾਂ ਤੋਂ ਬਾਅਦ ਕਲੀਨਅੱਪ, ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਮੁਕੰਮਲ ਹੋ ਚੁੱਕੇ ਡਾਊਨਲੋਡਾਂ ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਵਿੱਚ ਸਾਹਮਣੇ ਆਉਣ ਵਾਲੇ ਐੱਜ ਕੇਸਾਂ ਨੂੰ ਉਜਾਗਰ ਕੀਤਾ। ਅਸੀਂ ਉਹਨਾਂ ਕੋਡ ਪਾਥਾਂ ਨੂੰ ਠੀਕ ਕੀਤਾ, ਫ਼ੈੱਚ ਲਈ ਮੌਜੂਦਾ ਪੈਕ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੇ ਸਮੇਂ ਵੈਲੀਡੇਸ਼ਨ ਸ਼ਾਮਲ ਕੀਤੇ, ਅਤੇ ਇਸ ਕੰਮ ਦਾ ਯੋਗਦਾਨ ਵਾਪਸ ਅੱਪਸਟ੍ਰੀਮ ਵਿੱਚ ਪਾਇਆ।
ਸਾਨੂੰ ਇਹ ਦੇਖਣ ਦੀ ਵੀ ਲੋੜ ਸੀ ਕਿ ਸਮਾਂ ਅਤੇ ਬੈਂਡਵਿਡਥ ਕਿੱਥੇ ਖ਼ਰਚ ਹੋ ਰਹੇ ਸਨ, ਇਸ ਲਈ ਅਸੀਂ packfile-uri ਡਾਊਨਲੋਡਾਂ ਲਈ ਟ੍ਰੇਸਿੰਗ ਅਤੇ ਪੈਕ ਜਨਰੇਸ਼ਨ ਲਈ ਬਾਈਟ ਕਾਊਂਟਸ ਸ਼ਾਮਲ ਕੀਤੇ, ਜਿਸ ਨਾਲ ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਆਸਾਨ ਹੋ ਗਿਆ ਕਿ ਕੀ ਕੋਈ ਸੁਸਤ ਫ਼ੈੱਚ ਆਪਣਾ ਸਮਾਂ ਪੈਕ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਲਗਾ ਰਹੀ ਸੀ ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਵਿੱਚ।
OpenAI ਦੇ Git ਬਿਲਡ(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ), ਕਲਾਇੰਟ ਸੁਤੰਤਰ ਪੈਕਾਂ ਨੂੰ ਪੈਰਲਲ ਵਿੱਚ ਡਾਊਨਲੋਡ ਅਤੇ ਇੰਡੈਕਸ ਕਰ ਸਕਦਾ ਹੈ। ਅਸੀਂ "ਐਕਸਪਲਿਸਿਟ ਹੈਵਜ਼" ਦਾ ਸੰਕਲਪ ਸ਼ਾਮਲ ਕੀਤਾ ਤਾਂ ਜੋ ਸਰਵਰ ਕਿਸੇ ਬ੍ਰਾਂਚ ਦੇ ਮੌਜੂਦਾ ਟਿਪ ਨੂੰ ਉਸ ਹਿਸਟਰੀ ਤੋਂ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਐਡਵਰਟਾਈਜ਼ ਕਰ ਸਕੇ, ਜਿਸ ਨੂੰ ਪੁਸ਼ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਸ਼ਾਇਦ ਆਪਣੇ ਪੈਕ ਵਿੱਚੋਂ ਛੱਡ ਦੇਵੇ। Pando ਉੱਤੇ, ਇਹ ਕਲਾਇੰਟਾਂ ਨੂੰ --force-with-lease ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਹ ਜਾਂਚਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਕੋਈ ਫੀਚਰ ਬ੍ਰਾਂਚ ਅੱਗੇ ਤਾਂ ਨਹੀਂ ਵਧੀ, ਅਤੇ ਆਪਣਾ ਪੈਕ ਸਿਰਫ਼ ਟਰੰਕ ਦੇ ਆਧਾਰ 'ਤੇ ਹੀ ਤਿਆਰ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਫਿਰ ਕੋਈ ਵੀ ਵਿਅਕਤੀ ਜਿਸ ਕੋਲ ਉਹ ਟਰੰਕ ਹਿਸਟਰੀ ਹੈ, ਉਹ ਉਸੇ ਪੈਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਸ ਬ੍ਰਾਂਚ ਨੂੰ ਫ਼ੈੱਚ ਕਰ ਸਕਦਾ ਹੈ।
ਇਹਨਾਂ ਸੁਧਾਰਾਂ ਵਿੱਚੋਂ ਕਈ ਪਹਿਲਾਂ ਹੀ ਅੱਪਸਟ੍ਰੀਮ Git ਵਿੱਚ ਮੌਜੂਦ ਹਨ, ਅਤੇ ਕਈ ਹੋਰ ਸਾਡੀ ਪਬਲਿਕ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਹਨ। ਅਸੀਂ ਇਹਨਾਂ ਸੁਧਾਰਾਂ ਨੂੰ Pando ਤੋਂ ਪਰ੍ਹੇ ਵੀ ਲਾਭਦਾਇਕ ਬਣਾਉਣ ਲਈ Git ਕਮਿਊਨਿਟੀ ਨਾਲ ਮਿਲ ਕੇ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖ ਰਹੇ ਹਾਂ। ਤੁਸੀਂ ਸਾਡੇ ਪਬਲਿਕ ਪੈਚ ਟਰੈਕਰ(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਵਿੱਚ ਇਸ ਕੰਮ ਨੂੰ ਫ਼ਾਲੋ ਕਰ ਸਕਦੇ ਹੋ।
Git ਰਿਪੋਜ਼ਟਰੀਆਂ ਨੂੰ ਸਕੇਲ ਕਰਨ ਬਾਰੇ ਰਵਾਇਤੀ ਸੋਚ 'ਤੇ ਮੁੜ-ਵਿਚਾਰ ਕਰਕੇ, Pando ਸਾਨੂੰ ਸਾਡੇ ਇੰਜੀਨੀਅਰਾਂ ਅਤੇ ਏਜੰਟਾਂ ਦੁਆਰਾ ਪਹਿਲਾਂ ਤੋਂ ਵਰਤੇ ਜਾ ਰਹੇ Git ਵਰਕਫਲੋਅ ਵਿੱਚ ਬਿਨਾਂ ਕੋਈ ਬਦਲਾਅ ਕੀਤੇ ਸਾਡੇ ਮੋਨੋਰਿਪੋ ਨੂੰ ਸਕੇਲ ਕਰਨ ਦੇ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ। ਸਾਡੇ ਮੋਨੋਰਿਪੋ ਵਿੱਚ, Pando ਨੇ ਇੱਕੋ ਸਮੇਂ ਕੰਮ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਨੂੰ ਕਾਫ਼ੀ ਹੱਦ ਤੱਕ ਵਧਾਇਆ ਹੈ, ਮਰਜ ਭਰੋਸੇਯੋਗਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕੀਤਾ ਹੈ, ਅਤੇ ਕੋਡ ਤਬਦੀਲੀਆਂ ਨੂੰ ਪਬਲਿਸ਼ ਕਰਨ ਵਿੱਚ ਲੱਗਣ ਵਾਲੇ ਸਮੇਂ ਨੂੰ ਘਟਾਇਆ ਹੈ। ਸਾਡੇ ਮੋਨੋਰਿਪੋ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ OpenAI ਦੇ ਅੰਦਰ Pando ਦੇ ਹੋਰ ਉਪਯੋਗਾਂ ਦੀ ਵੀ ਖੋਜ ਕਰ ਰਹੇ ਹਾਂ, ਜਿਸ ਵਿੱਚ ਅਜਿਹੇ ਵਰਕਲੋਡ ਸ਼ਾਮਲ ਹਨ ਜਿੱਥੇ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਏਜੰਟਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੀ Git ਰਿਪੋਜ਼ਟਰੀ 'ਤੇ ਆਪਸੀ ਸਹਿਯੋਗ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਜਿਉਂ-ਜਿਉਂ ਇੰਜੀਨੀਅਰ ਅਤੇ ਏਜੰਟ ਹੋਰ ਜ਼ਿਆਦਾ ਸਾਫ਼ਟਵੇਅਰ ਤਿਆਰ ਕਰਨਗੇ, ਤਿਉਂ-ਤਿਉਂ OpenAI ਤੋਂ ਬਾਹਰ ਦੀਆਂ ਹੋਰ ਟੀਮਾਂ ਵੀ ਸੋਰਸ ਕੰਟਰੋਲ ਵਿੱਚ ਉਨ੍ਹਾਂ ਸੀਮਾਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਗੀਆਂ ਜਿਨ੍ਹਾਂ ਦਾ ਅਸੀਂ ਸਾਹਮਣਾ ਕੀਤਾ ਸੀ। ਅਸੀਂ ਇਸ ਸਮੇਂ ਉਸ ਤਕਨਾਲੋਜੀ ਨੂੰ ਆਪਣੇ ਵਰਤੋਂਕਾਰਾਂ ਨਾਲ ਸਾਂਝਾ ਕਰਨ ਦੇ ਤਰੀਕਿਆਂ ਦੀ ਖੋਜ ਕਰ ਰਹੇ ਹਾਂ ਜੋ Pando ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦੀ ਹੈ।
Pando Git ਰਿਪੋਜ਼ਟਰੀਆਂ ਦੇ ਵਰਤੋਂਕਾਰਾਂ ਅਤੇ ਸੰਚਾਲਕਾਂ ਦੇ ਦੋ ਦਹਾਕਿਆਂ ਦੇ ਤਜ਼ਰਬੇ 'ਤੇ ਆਧਾਰਿਤ ਹੈ। ਅਸੀਂ ਓਪਨ-ਸੋਰਸ Git ਭਾਈਚਾਰੇ ਨਾਲ ਮਿਲ ਕੇ ਕੰਮ ਕਰਦੇ ਹੋਏ Pando ਨੂੰ ਵਿਕਸਤ ਕਰਨਾ ਜਾਰੀ ਰੱਖਾਂਗੇ, ਤਾਂ ਜੋ ਅਜਿਹੇ ਕਿਸੇ ਵੀ ਸੁਧਾਰ ਨੂੰ ਸਾਂਝਾ ਕੀਤਾ ਜਾ ਸਕੇ ਜੋ ਵੱਡੇ ਪੱਧਰ 'ਤੇ Git ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਲਾਭ ਪਹੁੰਚਾਉਂਦਾ ਹੋਵੇ।
