Git-status kruip oor SSHFS via ’n VPN: skuif die werk

Kopieer ’n 200 MB-lêer en dit vlieg. Voer git status in dieselfde gids uit en die wag is lank genoeg om van dit weg te skakel. Dié twee waarnemings is nie teenstrydig nie, want groot oordrag meet deurset, terwyl Git meet hoeveel klein lêerstelselvrae dit per sekonde kan vra, en ’n gemonteerde afgeleë boom verander elke vraag in ’n rondte. Om die VPN te stel gaan nie ’n werklading regmaak wat verkeerd gevorm is nie.

Waarom status die verkeerde maatstaf is

Git moet oor baie lêers leer: watter is gewysig, watter is onopgespoor, en of gekasde indeksdata nog ooreenstem met wat op die skyf sit. Oor SSHFS kan elkeen van daardie waarnemings ’n netwerkbewerking wees. Die werkeenheid hier is die lêertelling, nie die megabytes nie.

Dis hoekom die eerste status ná ’n kloon stadig is, en hoekom latere selfs stadiger kan wees in ’n boom vol bou-uitsette. Onopgespoorde skandering loop deur gidse waarvoor jy dalk nie omgee nie, en elke stap is nog ’n versoek oor die skakel. Op ’n pad van 40 ms word ’n boom met ’n paar duisend inskrywings ’n paar duisend rondtes. Geen pakkie-opname is nodig om daardie rekenkunde te bevestig nie.

’n Aflaai-maatstaf sê die skakel is reg; dit sê niks oor of duisend klein leesaksies vanmiddag klaar sal wees nie.

Skuif die werkkopie, nie die stelknoppe nie

’n Plaaslike kloon plaas die werkboom, die indeks en die Git-bewerkings op dieselfde masjien. ’n Pull word ’n sigbare netwerkstap in plaas van elke lêerkontrole wat een word.

Dit pas wanneer die ontwikkelaar die vereiste bron plaaslik kan hou, wat meestal die geval is. Dit maak ook die commit- en ontplooiingsgrens skerper, want om ’n plaaslike lêer te wysig verander nie meer per ongeluk ’n lopende afgeleë diens nie; die verandering moet gestoot en ontplooi word soos enigiets anders. Die prys is dat die kode op twee plekke bestaan, so besluit watter kopie gesaghebbend is en hoe ’n hotfix op die bediener terug in die bewaarplek kom. Daardie gesprek is goedkoper as ’n status-opdrag wat niemand wil uitvoer nie.

As die werkarea afgeleë moet bly, laat loop Git daar

Soms kan die werkarea nie skuif nie: die bou het daardie omgewing nodig, die data is te groot, of beleid hou die bron op die gasheer. Laat loop dan Git en die relevante ontwikkelingsnutsgoed langs die lêers, deur ’n goedgekeurde afgeleë skul of ’n afgeleë-ontwikkelingsomgewing. Die redigeerder kan op die skootrekenaar bly terwyl sy agterkant langs die werkboom werk.

Duur bewerkings gebeur dan plaaslik op die afgeleë gasheer, en die netwerk dra redigeerderverkeer in plaas van duisende stat-oproepe. Dit is dieselfde oplossing as ’n plaaslike kloon, uitgedruk as ’n ontplooiingskeuse eerder as ’n migrasie.

Sinchronisering is ’n werkvloei met eienaars, nie ’n kas nie

’n Gesinchroniseerde werkarea kan herhaalde afgeleë lees verminder, maar dit is nie ’n deursigtige kas nie. Dit het ’n eienaar vir elke verandering nodig, ’n reël vir konflikte, en ’n ooreenkoms oor gegenereerde lêers wat beide kante dink hulle besit. Sonder daardie reëls skep die reëling onenigheid eerder as gerief.

’n Tweerigting-sinchroniseerder sonder hulle lewer ’n ander probleem as die een wat dit opgelos het, gewoonlik ’n samesmelting wat niemand kan toeskryf nie. Vermy twee Git-prosesse teen een gedeelde werkboom tensy jy verstaan hoe hulle koördineer.

Stel dan, en hou SSH verstandig

Nadat die reëling reg is, verander twee instellings hoeveel lêers Git moet vra: status.showUntrackedFiles en die onopgespoorde kas agter core.untrackedCache. Nie een verander wat elke vraag oor 40 ms kos nie; hulle verander net hoeveel vrae daar is. Draai ’n knop eers wanneer die rondtes plaaslik is.

Meet die opdrag wat jou irriteer eerder as om te redeneer uit ’n maatstaf wat een groot lêer kopieer, en los ondersteunde SSH-enkripsie alleen. ’n Verouderde syfer verkort nie ’n rondte nie; dit voeg ’n tweede probleem by wat die eerste oorleef. Die Git-statusverwysing is een lees werd, want die opdrag doen baie meer werk as wat sy naam voorstel.