git status rampas sur SSHFS tra VPN: movu la laboron

Kopiu dosieron de 200 MB kaj ĝi flugas. Rulu git status en la sama dosierujo kaj la atendo sufiĉas por ŝanĝi taskon. Tiuj du observoj ne kontraŭdiras sin, ĉar amasa transigo mezuras trafluon dum Git mezuras kiom da malgrandaj demandoj al la dosiersistemo ĝi povas fari en sekundo, kaj surmetita fora arbo igas ĉiun demandon reiro. Agordi la VPN ne riparos malĝuste formitan laborŝarĝon.

Kial status estas la malĝusta mezurilo

Git devas scii pri multaj dosieroj: kiuj estas ŝanĝitaj, kiuj ne spurataj, kaj ĉu la kaŝmemoraj indeksaj datumoj ankoraŭ kongruas kun tio, kio kuŝas sur la disko. Tra SSHFS ĉiu el tiuj observoj povas esti reta operacio. La laborunuo ĉi tie estas la nombro de dosieroj, ne la megabajtoj.

Tial la unua status post klonado estas malrapida, kaj tial la postaj povas esti eĉ pli malrapidaj en arbo plena de konstrueligoj. Skanado de nespurataj promenas tra dosierujoj, kiuj eble ne interesas vin, kaj ĉiu paŝo estas plia peto tra la ligo. Sur vojo de 40 ms arbo kun kelkaj miloj da eroj fariĝas kelkaj miloj da reiroj. Neniu paketa kapto necesas por konfirmi tiun aritmetikon.

Elŝuta mezurilo diras, ke la ligo estas bona; ĝi diras nenion pri tio, ĉu mil malgrandaj legadoj finiĝos hodiaŭ posttagmeze.

Movu la laborarbon, ne la agordajn butonojn

Loka klono metas la laborarbon, la indekson kaj la Git-operaciojn sur la saman maŝinon. Pull fariĝas videbla reta paŝo anstataŭ ĉiu dosiera kontrolo.

Tio taŭgas kiam ajn la programisto povas teni la bezonatan fonton loke, kio estas plej ofte. Ĝi ankaŭ akrigas la limon inter commit kaj deplojo, ĉar redakti lokan dosieron ne plu hazarde ŝanĝas runteman foran servon; la ŝanĝo devas esti puŝita kaj deplojita kiel ĉio alia. La prezo estas, ke la kodo ekzistas en du lokoj, do decidu, kiu kopio estas la aŭtoritata kaj kiel hastoriparo sur la servilo revenas en la deponejon. Tiu interparolo kostas malpli ol status-komando, kiun neniu volas ruli.

Se la laborspaco devas resti fora, rulu Git tie

Kelkfoje la laborspaco ne povas moviĝi: la konstruo bezonas tiun ĉirkaŭaĵon, la datumoj tro grandas, aŭ regularo tenas la fonton sur la gastiganto. Tiam rulu Git kaj la rilatajn disvolvajn ilojn apud la dosieroj, tra aprobita fora ŝelo aŭ fora disvolva medio. La redaktilo povas resti sur la tekokomputilo dum ĝia malantaŭo laboras apud la laborarbo.

Multekostaj operacioj tiam okazas loke sur la fora gastiganto, kaj la reto portas redaktilan trafikon anstataŭ miloj da stat-vokoj. Ĝi estas la sama riparo kiel loka klono, esprimita kiel deploja elekto anstataŭ migrado.

Sinkronigo estas laborfluo kun posedantoj, ne kaŝmemoro

Sinkronigita laborspaco povas redukti ripetajn forajn legadojn, sed ĝi ne estas travidebla kaŝmemoro. Ĝi bezonas posedanton por ĉiu ŝanĝo, regulon por konfliktoj kaj interkonsenton pri generitaj dosieroj, kiujn ambaŭ flankoj kredas siaj. Sen tiuj reguloj la aranĝo kreas malkonsenton anstataŭ oportunon.

Dudirekta sinkronigilo sen ili produktas alian problemon ol tiun, kiun ĝi solvis, kutime kunfandon, kiun neniu povas atribui. Evitu ruli du Git-procezojn sur unu komuna laborarbo, krom se vi komprenas, kiel ili kunordiĝas.

Poste agordu, kaj tenu SSH prudentan

Post kiam la aranĝo estas ĝusta, du agordoj ŝanĝas pri kiom da dosieroj Git devas demandi: status.showUntrackedFiles kaj la kaŝmemoro de nespurataj malantaŭ core.untrackedCache. Neniu ŝanĝas, kiom kostas ĉiu demando tra 40 ms; ili nur ŝanĝas kiom da demandoj estas. Turnu butonon nur kiam la reiroj estas lokaj.

Mezuru la tempon de la komando, kiu ĝenas vin, anstataŭ rezonadi el mezurilo, kiu kopias unu grandan dosieron, kaj lasu la subtenatan SSH-ĉifradon trankvila. Malfreŝa ĉifro ne mallongigas reiron; ĝi aldonas duan problemon, kiu postvivas la unuan. La Git status-referenco indas unu legadon, ĉar la komando faras multe pli da laboro ol sia nomo sugestas.