git status kravler på SSHFS over en VPN: flyt arbejdet

Kopiér en fil på 200 MB, og den flyver afsted. Kør git status i samme mappe, og ventetiden er lang nok til at skifte opgave. De to observationer modsiger ikke hinanden, fordi bulkoverførsel måler gennemstrømning, mens Git måler, hvor mange små filsystemspørgsmål det kan stille i sekundet, og et monteret fjerntræ gør hvert spørgsmål til en rundtur. At tune VPN'en løser ikke en arbejdsbyrde, der er formet forkert.

Hvorfor status er det forkerte pejlemærke

Git skal lære om mange filer: hvilke der er ændret, hvilke der ikke er sporet, og om cachede indeksdata stadig svarer til det, der ligger på disken. Over SSHFS kan hver af disse observationer være en netværksoperation. Arbejdsenheden her er antallet af filer, ikke megabytes.

Derfor er det første status efter et klon langsomt, og derfor kan senere være endnu langsommere i et træ fuld af build-output. Scanning af usporede filer går gennem mapper, du måske ikke er interesseret i, og hvert skridt er endnu en anmodning over forbindelsen. På en vej på 40 ms bliver et træ med et par tusind poster til et par tusind rundture. Der skal ikke pakkefangst til at bekræfte den aritmetik.

En downloadmåling fortæller, at forbindelsen er fin; den siger intet om, hvorvidt tusind små læsninger bliver færdige i eftermiddag.

Flyt arbejdstræet, ikke tune-knapperne

Et lokalt klon lægger arbejdstræet, indekset og Git-operationerne på samme maskine. Et pull bliver et synligt netværkstrin i stedet for, at hvert filtjek gør det.

Det passer, når udvikleren kan holde den nødvendige kildekode lokalt, hvilket er det meste af tiden. Det skærper også grænsen mellem commit og udrulning, fordi redigering af en lokal fil ikke længere ændrer en kørende fjernservice ved et uheld; ændringen skal pushes og udrulles som alt andet. Prisen er, at koden findes to steder, så beslut, hvilken kopi der er autoritativ, og hvordan et hotfix på serveren kommer tilbage i repoet. Den samtale er billigere end en status-kommando, som ingen vil køre.

Hvis arbejdsområdet skal blive fjernt, så kør Git der

Nogle gange kan arbejdsområdet ikke flyttes: build'et kræver det miljø, dataene er for store, eller politik holder kilden på værten. Så kør Git og de relevante udviklingsværktøjer ved siden af filerne, gennem en godkendt fjernshell eller et fjernudviklingsmiljø. Editoren kan blive på laptop'en, mens dens backend arbejder ved siden af arbejdstræet.

Dyre operationer sker så lokalt på fjernværten, og netværket bærer editortrafik i stedet for tusindvis af stat-kald. Det er samme løsning som et lokalt klon, udtrykt som et udrulningsvalg snarere end en migrering.

Synkronisering er et workflow med ejere, ikke en cache

Et synkroniseret arbejdsområde kan skære gentagne fjernlæsninger væk, men det er ikke en transparent cache. Det kræver en ejer for hver ændring, en regel for konflikter og en aftale om genererede filer, som begge sider mener, de ejer. Uden de regler skaber arrangementet uenighed i stedet for bekvemmelighed.

En tovejssynkronisator uden dem skaber et andet problem end det, den løste, som regel et merge, som ingen kan tilskrive. Undgå at køre to Git-processer mod ét delt arbejdstræ, medmindre du forstår, hvordan de koordinerer.

Så tune, og hold SSH fornuftigt

Når arrangementet er rigtigt, ændrer to indstillinger, hvor mange filer Git skal spørge om: status.showUntrackedFiles og den usporede cache bag core.untrackedCache. Ingen af dem ændrer, hvad hvert spørgsmål koster over 40 ms; de ændrer kun, hvor mange spørgsmål der er. Drej først på en knap, når rundturene er lokale.

Tag tid på den kommando, der irriterer dig, i stedet for at ræsonnere ud fra en måling, der kopierer én stor fil, og lad understøttet SSH-kryptering være. En forældet cipher forkorter ikke en rundtur; den tilføjer et andet problem, der overlever det første. Git status-referencen er værd at læse én gang, fordi kommandoen gør langt mere arbejde, end navnet antyder.