VPN üzərindən SSHFS-də git status sürünür: işi köçürün
Böyük fayl asanlıqla köçür, amma git status sürünür. Ağac VPN üzərindən SSHFS-dədirsə, xərc hər fayl üçün gediş-dönüşlərdir, bant genişliyi deyil. İşi köçürün.
200 MB-lıq faylı köçürün və uçur. Həmin qovluqda git status işlədin və gözləmə o qədər uzun olur ki, diqqəti başqa işə keçirəsən. Bu iki müşahidə zidd deyil, çünki kütləvi ötürmə buraxılış sürətini ölçür, Git isə saniyədə neçə kiçik fayl sistemi sualı verə biləcəyini ölçür və quraşdırılmış uzaq ağac hər sualı gediş-dönüşə çevirir. VPN-i tənzimləmək səhv qurulmuş iş yükünü düzəltməyəcək.
Niyə status yanlış ölçüdür
Git çoxlu fayl haqqında məlumat toplamalıdır: hansı dəyişdirilib, hansı izlənmir və keşlənmiş indeks məlumatı diskdəkinə hələ uyğundurmu. SSHFS üzərində bu müşahidələrin hər biri şəbəkə əməliyyatı ola bilər. Burada iş vahidi meqabaytlar deyil, fayl sayıdır.
Buna görə klondan sonra ilk status yavaşdır və buna görə build çıxışı ilə dolu ağacda sonrakılar daha da yavaş ola bilər. İzlənməyənlərin skanı səni maraqlandırmayan qovluqları gəzir və hər addım link üzərindən başqa bir sorğudur. 40 ms-lik yolda bir neçə min girişi olan ağac bir neçə min gediş-dönüşə çevrilir. Bu hesabı təsdiqləmək üçün paket tutmağa ehtiyac yoxdur.
Yükləmə ölçüsü linkin yaxşı olduğunu deyir; min kiçik oxumanın bu gün bitəcəyi barədə heç nə demir.
İş ağacını köçürün, tənzim düymələrini yox
Lokal klon iş ağacını, indeksi və Git əməliyyatlarını eyni maşına qoyur. Pull görünən bir şəbəkə addımına çevrilir, hər fayl yoxlaması isə yox.
Bu, tərtibatçının lazımi mənbəni lokal saxlaya bildiyi hər halda uyğundur ki, bu da çox vaxt belədir. O, həmçinin commit və yerləşdirmə sərhədini kəskinləşdirir, çünki lokal faylı redaktə etmək artıq təsadüfən işləyən uzaq xidməti dəyişmir; dəyişiklik hər şey kimi push və deploy olunmalıdır. Güzəşt kodun iki yerdə olmasıdır, ona görə hansı nüsxənin səlahiyyətli olduğunu və serverdəki hotfix-in repoya necə qayıdacağını qərarlaşdırın. Bu söhbət heç kimin işlətmək istəmədiyi status əmrindən ucuzdur.
İş sahəsi uzaq qalmalıdırsa, Git-i orada işlədin
Bəzən iş sahəsi köçə bilmir: build həmin mühiti tələb edir, məlumat çox böyükdür və ya siyasət mənbəni hostda saxlayır. Onda Git-i və müvafiq inkişaf alətlərini faylların yanında, təsdiqlənmiş uzaq shell və ya uzaq inkişaf mühiti ilə işlədin. Redaktor noutbukda qala bilər, onun backend-i iş ağacının yanında işləyərkən.
Bahalı əməliyyatlar sonra uzaq hostda lokal baş verir və şəbəkə minlərlə stat çağırışı yerinə redaktor trafikini daşıyır. Bu, lokal klonla eyni düzəlişdir, sadəcə miqrasiya deyil, yerləşdirmə seçimi kimi ifadə olunur.
Sinxronizasiya keş deyil, sahibləri olan iş axınıdır
Sinxronlaşdırılmış iş sahəsi təkrarlanan uzaq oxumaları azalda bilər, amma şəffaf keş deyil. Hər dəyişiklik üçün sahib, ziddiyyətlər üçün qayda və hər iki tərəfin öz bildiyi yaradılmış fayllar barədə razılıq lazımdır. Bu qaydalar olmadan quruluş rahatlıq deyil, fikir ayrılığı yaradır.
Onlarsız ikiistiqamətli sinxronlaşdırıcı həll etdiyindən fərqli bir problem yaradır, adətən heç kimin aid edə bilmədiyi merge. İki Git prosesini bir paylaşılan iş ağacında işlətməkdən çəkinin, əgər onların necə koordinasiya etdiyini anlamırsınızsa.
Sonra tənzimləyin və SSH-ı sağlam saxlayın
Quruluş düzgün olduqdan sonra iki parametr Git-in nə qədər fayl haqqında soruşacağını dəyişir: status.showUntrackedFiles və core.untrackedCache arxasındakı izlənməyən keş. Heç biri 40 ms üzərində hər sualın xərcini dəyişmir; onlar yalnız sualların sayını dəyişir. Düyməni yalnız gediş-dönüşlər lokal olandan sonra çevirin.
Sizi narahat edən əmrin vaxtını ölçün, bir böyük fayl köçürən ölçüdən nəticə çıxarmaq əvəzinə, və dəstəklənən SSH şifrələməsini toxunulmaz buraxın. Köhnəlmiş şifr gediş-dönüşü qısaltmır; birincidən uzun yaşayan ikinci bir problem əlavə edir. Git status sənədi bir dəfə oxumağa dəyər, çünki əmr adının təklif etdiyindən qat-qat çox iş görür.