git status se târăște pe SSHFS prin VPN: mută munca

Copiați un fișier de 200 MB și zboară. Rulați git status în același director și așteptarea este destul de lungă încât să vă mutați atenția. Cele două observații nu se contrazic, pentru că transferul în bloc măsoară debitul, în timp ce Git măsoară câte întrebări mici către sistemul de fișiere poate pune pe secundă, și un arbore la distanță montat transformă fiecare întrebare într-un dus-întors. Reglarea VPN-ului nu va repara o încărcare prost formată.

De ce status este reperul greșit

Git trebuie să știe despre multe fișiere: care sunt modificate, care nu sunt urmărite și dacă datele de index din cache mai corespund cu ce este pe disc. Prin SSHFS fiecare dintre aceste observații poate fi o operație de rețea. Unitatea de lucru aici este numărul de fișiere, nu megabaiții.

De aceea primul status după un clone este lent, și de aceea următoarele pot fi chiar mai lente într-un arbore plin de rezultate de compilare. Scanarea celor neurmărite trece prin directoare care poate nu vă interesează, iar fiecare pas este încă o cerere prin legătură. Pe o cale de 40 ms un arbore cu câteva mii de intrări devine câteva mii de dus-întorsuri. Nu este nevoie de captură de pachete pentru a confirma această aritmetică.

Un test de descărcare vă spune că legătura este bună; nu spune nimic despre dacă o mie de citiri mici se vor termina astăzi după-amiază.

Mutați arborele de lucru, nu butoanele de reglaj

Un clone local pune arborele de lucru, indexul și operațiile Git pe aceeași mașină. Un pull devine un pas de rețea vizibil, în loc să fie fiecare verificare de fișier.

Acest lucru se potrivește oricând dezvoltatorul poate păstra sursa necesară local, ceea ce este de obicei cazul. Ascute și granița dintre commit și implementare, pentru că editarea unui fișier local nu mai schimbă din greșeală un serviciu la distanță care rulează; schimbarea trebuie împinsă și implementată ca orice altceva. Prețul este că codul există în două locuri, așa că decideți care copie este autoritară și cum o corecție urgentă pe server se întoarce în depozit. Acea conversație este mai ieftină decât o comandă status pe care nimeni nu vrea să o ruleze.

Dacă spațiul de lucru trebuie să rămână la distanță, rulați Git acolo

Uneori spațiul de lucru nu poate fi mutat: compilarea are nevoie de acel mediu, datele sunt prea mari sau politica ține sursa pe gazdă. Atunci rulați Git și instrumentele de dezvoltare relevante lângă fișiere, printr-un shell la distanță aprobat sau un mediu de dezvoltare la distanță. Editorul poate rămâne pe laptop în timp ce backend-ul său lucrează lângă arborele de lucru.

Operațiile scumpe au loc atunci local pe gazda la distanță, iar rețeaua transportă traficul editorului în loc de mii de apeluri stat. Este aceeași corecție ca un clone local, exprimată ca alegere de implementare și nu ca migrare.

Sincronizarea este un flux de lucru cu proprietari, nu un cache

Un spațiu de lucru sincronizat poate reduce citirile la distanță repetate, dar nu este un cache transparent. Are nevoie de un proprietar pentru fiecare schimbare, de o regulă pentru conflicte și de o înțelegere privind fișierele generate pe care ambele părți le cred ale lor. Fără aceste reguli aranjamentul creează dezacord în loc de confort.

Un sincronizator bidirecțional fără ele produce o problemă diferită de cea pe care a rezolvat-o, de obicei o îmbinare pe care nimeni nu o poate atribui. Evitați să rulați două procese Git pe un singur arbore de lucru partajat dacă nu înțelegeți cum se coordonează.

Apoi reglați, și păstrați SSH rezonabil

Când aranjamentul este corect, două setări schimbă la câte fișiere trebuie să întrebe Git: status.showUntrackedFiles și cache-ul celor neurmărite din spatele core.untrackedCache. Niciuna nu schimbă cât costă fiecare întrebare pe 40 ms; schimbă doar câte întrebări există. Rotiți un buton doar când dus-întorsurile sunt locale.

Măsurați timpul comenzii care vă enervează în loc să raționați pornind de la un test care copiază un fișier mare, și lăsați în pace criptarea SSH acceptată. Un cifru învechit nu scurtează un dus-întors; adaugă o a doua problemă care supraviețuiește primei. Referința git status merită o lectură, pentru că comanda face mult mai multă muncă decât sugerează numele.