git status lēni velkas SSHFS ar VPN: pārvietojiet darbu

Nokopējiet 200 MB failu un tas lido. Palaidiet git status tajā pašā mapē un gaidīšana ir tik ilga, ka gribas pārslēgties uz ko citu. Šie divi novērojumi nav pretrunīgi, jo lielapjoma pārsūtīšana mēra caurlaidspēju, bet Git mēra, cik daudz mazu failu sistēmas jautājumu tas var uzdot sekundē, un piesaistīts attāls koks pārvērš katru jautājumu atgriezeniskā braucienā. VPN regulēšana nesalabos nepareizi veidotu slodzi.

Kāpēc status ir nepareizais mēraukls

Git ir jāzina par daudziem failiem: kuri ir mainīti, kuri nav izsekoti un vai kešatmiņā saglabātie indeksa dati joprojām atbilst tam, kas ir diskā. SSHFS gadījumā katrs no šiem novērojumiem var būt tīkla darbība. Darba vienība šeit ir failu skaits, nevis megabaiti.

Tāpēc pirmais status pēc klonēšanas ir lēns, un tāpēc nākamie var būt vēl lēnāki kokā, kas pilns ar būvēšanas izvadi. Neizsekoto failu skenēšana iet cauri mapēm, kas jums varbūt neinteresē, un katrs solis ir vēl viens pieprasījums pa savienojumu. 40 ms ceļā koks ar dažiem tūkstošiem ierakstu pārvēršas dažos tūkstošos atgriezenisko braucienu. Šīs aritmētikas apstiprināšanai nav vajadzīga pakešu uztveršana.

Lejupielādes mēraukls pasaka, ka savienojums ir labi; tas neko nepasaka par to, vai tūkstotis mazu lasījumu beigsies šodien pēcpusdienā.

Pārvietojiet darba koku, nevis regulēšanas pogas

Vietējs klons ievieto darba koku, indeksu un Git darbības tajā pašā mašīnā. Pull kļūst par redzamu tīkla soli, nevis katra faila pārbaude par tādu.

Tas der vienmēr, kad izstrādātājs var turēt nepieciešamo avotu lokāli, un tā parasti ir. Tas arī saasina robežu starp commit un izvietošanu, jo lokāla faila rediģēšana vairs nejauši nemaina darbojošos attālo pakalpojumu; izmaiņas ir jānostūta un jāizvieto kā viss pārējais. Cena ir tāda, ka kods pastāv divās vietās, tāpēc izlemiet, kura kopija ir autoritatīva un kā steidzams labojums serverī atgriežas repozitorijā. Šī saruna ir lētāka nekā status komanda, kuru neviens negrib palaist.

Ja darbvieta ir jāatstāj attālināta, palaidiet Git tur

Dažkārt darbvietu nevar pārvietot: būvēšanai vajadzīga tā vide, dati ir pārāk lieli vai politika patur avotu uz resursdatora. Tad palaidiet Git un attiecīgos izstrādes rīkus blakus failiem, izmantojot apstiprinātu attālu čaulu vai attālinātas izstrādes vidi. Redaktors var palikt portatīvajā datorā, kamēr tā aizmugure strādā blakus darba kokam.

Dārgās darbības tad notiek lokāli attālajā resursdatorā, un tīkls pārvadā redaktora datu plūsmu, nevis tūkstošiem stat izsaukumu. Tas ir tas pats labojums kā vietējs klons, izteikts kā izvietošanas izvēle, nevis migrācija.

Sinchronizācija ir darbplūsma ar īpašniekiem, nevis kešatmiņa

Sinchronizēta darbvieta var samazināt atkārtotus attālus lasījumus, bet tā nav caurspīdīga kešatmiņa. Tai vajag īpašnieku katram labojumam, noteikumu konfliktiem un vienošanos par ģenerētajiem failiem, kurus abas puses uzskata par savējiem. Bez šiem noteikumiem iekārtojums rada nesaskaņas, nevis ērtības.

Divvirzienu sinchronizators bez tiem rada citādu problēmu nekā to, ko atrisināja, parasti sapludinājumu, kuru neviens nevar attiecināt. Izvairieties palaist divus Git procesus vienā kopīgā darba kokā, ja vien nesaprotat, kā tie saskaņojas.

Tad regulējiet un turiet SSH saprātīgu

Kad iekārtojums ir pareizs, divi iestatījumi maina, par cik failiem Git ir jājautā: status.showUntrackedFiles un neizsekoto kešatmiņa aiz core.untrackedCache. Neviens nemaina to, cik maksā katrs jautājums 40 ms laikā; tie maina tikai jautājumu skaitu. Pagrieziet pogu tikai tad, kad atgriezeniskie braucieni ir lokāli.

Mēriet laiku komandai, kas jūs kaitina, nevis spriediet no mēraukla, kas kopē vienu lielu failu, un atstājiet atbalstīto SSH šifrēšanu mierā. Novecojis šifrs nesaīsina atgriezenisko braucienu; tas pievieno otru problēmu, kas pārdzīvo pirmo. git status uzziņa ir viena lasījuma vērta, jo komanda dara daudz vairāk darba, nekā liecina tās nosaukums.