git status krûpt oer SSHFS fia in VPN: ferpleats it wurk

Kopiearje in bestân fan 200 MB en it fljocht. Doch git status yn deselde map en it wachtsjen is lang genôch om oan wat oars te tinken. Dy twa waarnimmings tsjinsprekke elkoar net, want bulkferfier mjit trochset, wylst Git mjit hoefolle lytse bestânssysteemfragen it per sekonde stelle kin, en in oanhongen fiere beam makket fan elke fraach in rûnreis. Oan de VPN draaie reparearret gjin ferkeard foarme wurklêst.

Wêrom status de ferkearde mjitstêf is

Git moat oer in protte bestannen leare: hokker feroare binne, hokker net folge binne en oft de bewarre yndeksgegevens noch oerienkomme mei wat op 'e skiif leit. Oer SSHFS kin elk fan dy waarnimmings in netwurkoperaasje wêze. De wurkeenheid hjir is it tal bestannen, net de megabytes.

Dêrom is de earste status nei in kloan stadich, en dêrom kinne lettere noch stadiger wêze yn in beam fol bou-útfier. It skennen fan net-folge bestannen rint troch mappen dêr't jo miskien net om jouwe, en elke stap is noch in fersyk oer de ferbining. Op in paad fan 40 ms wurdt in beam mei in pear tûzen yngongen in pear tûzen rûnreizen. Der is gjin pakketopname nedich om dy rekkenjen te befêstigjen.

In downloadmjitstêf seit dat de ferbining goed is; it seit neat oer de fraach oft tûzen lytse lêzingen hjoed middei klear binne.

Ferpleats de wurkbeam, net de knoppen

In pleatslike kloan set de wurkbeam, de yndeks en de Git-operaasjes op deselde masine. In pull wurdt in sichtbere netwurkstap ynstee fan dat elke bestânskontrôle dat wurdt.

Dit past wannear't de ûntwikkelder de nedige boarne pleatslik hâlde kin, wat meastentiids sa is. It skerpt ek de grins tusken commit en útrôljen oan, want it bewurkjen fan in pleatslik bestân feroaret net mear by ûngelok in rinnende fiere tsjinst; de feroaring moat pushd en útrôle wurde lykas al it oare. De priis is dat de koade op twa plakken bestiet, dus beslute hokker kopy gesachhawwend is en hoe't in hotfix op 'e server weromkomt yn it bewarplak. Dat petear is goedkeaper as in status-opdracht dy't gjinien rinne wol.

As de wurkromte fier bliuwe moat, rinn Git dêr

Soms kin de wurkromte net ferpleatst wurde: de bou hat dat omjouwing nedich, de gegevens binne te grut of belied hâldt de boarne op 'e host. Rin dan Git en de relevante ûntwikkelingsark njonken de bestannen, fia in goedkarde fiere shell of in fiere-ûntwikkelingsomjouwing. De bewurker kin op 'e laptop bliuwe wylst syn backend njonken de wurkbeam wurket.

Djoere operaasjes barre dan pleatslik op 'e fiere host, en it netwurk draacht bewurkersferkear ynstee fan tûzenen stat-oproppen. It is deselde reparaasje as in pleatslike kloan, útdrukt as in útrôlkar ynstee fan in migraasje.

Synkronisaasje is in wurkstream mei eigners, net in cache

In syngronisearre wurkromte kin werhelle fiere lêzingen besunigje, mar it is gjin transparante cache. It hat in eigner foar elke feroaring nedich, in regel foar konflikten en in ôfspraak oer generearre bestannen dy't beide kanten miene dat se derfan binne. Sûnder dy regels makket de regeling ûnienigens ynstee fan gemak.

In twa-rjochting-syngronisator sûnder har makket in oar probleem as dat er oploste, meastentiids in gearfoeging dy't gjinien taskriuwe kin. Foarkom twa Git-prosessen tsjin ien dielde wurkbeam, of jo moatte begripe hoe't se koördinearje.

Dan fine-tune, en hâld SSH ferstannich

As de regeling goed is, feroarje twa ynstellings oer hoefolle bestannen Git freegje moat: status.showUntrackedFiles en de net-folge cache efter core.untrackedCache. Gjin fan beide feroaret wat elke fraach oer 40 ms kostet; se feroarje allinnich hoefolle fragen der binne. Draai in knop pas as de rûnreizen pleatslik binne.

Mjit de tiid fan it kommando dat jo ergeret ynstee fan te redenearjen fan in mjitstêf dy't ien grut bestân kopiearret, en lit stipe SSH-fersifering gewurde. In ferâldere sifer ferkoartet in rûnreis net; it foeget in twadde probleem ta dat it earste oerlibbet. De Git status-referinsje is ien lêzen wurdich, want it kommando docht folle mear wurk as syn namme seit.