A git status vánszorog SSHFS-en VPN-en át: tegye át a munkát

Másoljon át egy 200 MB-os fájlt, és repül. Futtassa a git status parancsot ugyanabban a könyvtárban, és a várakozás elég hosszú ahhoz, hogy másra gondoljon. A két megfigyelés nem mond ellent egymásnak, mert a tömeges átvitel az áteresztőképességet méri, míg a Git azt, hogy másodpercenként hány apró fájlrendszer-kérdést tud feltenni, és egy felcsatolt távoli fa minden kérdésből egy oda-vissza utat csinál. A VPN hangolása nem javít egy rosszul formált munkaterhelést.

Miért rossz mérce a status

A Gitnek sok fájlról kell tudnia: melyek módosultak, melyek követetlenek, és hogy a gyorsítótárazott indexadatok még egyeznek-e a lemezen lévővel. SSHFS-en át ezek a megfigyelések mindegyike hálózati művelet lehet. A munka egysége itt a fájlok száma, nem a megabájtok.

Ezért lassú az első status klónozás után, és ezért lehetnek a későbbiek még lassabbak egy build-kimenettel teli fában. A követetlen fájlok bejárása olyan könyvtárakon megy át, amelyek esetleg nem érdeklik, és minden lépés egy újabb kérés a kapcsolaton. Egy 40 ms-os útvonalon egy néhány ezer bejegyzésű fa néhány ezer oda-vissza úttá válik. Nem kell csomagrögzítés ahhoz, hogy ezt az aritmetikát megerősítse.

A letöltési mérce azt mondja, hogy a kapcsolat rendben van; arról semmit nem mond, hogy ezer apró olvasás befejeződik-e ma délután.

A munkafát tegye át, ne a hangológombokat

Egy helyi klón ugyanarra a gépre teszi a munkafát, az indexet és a Git-műveleteket. A pull látható hálózati lépéssé válik ahelyett, hogy minden fájlellenőrzés az lenne.

Ez akkor illik, amikor a fejlesztő a szükséges forrást helyben tudja tartani, ami legtöbbször így van. Élesíti a commit és az üzembe helyezés közötti határt is, mert egy helyi fájl szerkesztése már nem változtat véletlenül egy futó távoli szolgáltatást; a változtatást pusholni és telepíteni kell, mint bármi mást. Az ára az, hogy a kód két helyen létezik, ezért döntse el, melyik példány a mérvadó, és hogyan kerül vissza egy szerveren végzett gyorsjavítás a tárolóba. Ez a beszélgetés olcsóbb, mint egy status parancs, amit senki nem akar futtatni.

Ha a munkaterületnek távolinak kell maradnia, futtassa ott a Gitet

Néha a munkaterület nem mozdítható: a buildnek arra a környezetre van szüksége, az adatok túl nagyok, vagy a szabályzat a hoszton tartja a forrást. Akkor futtassa a Gitet és a vonatkozó fejlesztőeszközöket a fájlok mellett, jóváhagyott távoli shellen vagy távoli fejlesztői környezeten keresztül. A szerkesztő maradhat a laptopon, miközben a háttere a munkafa mellett dolgozik.

A drága műveletek akkor helyben, a távoli hoszton történnek, és a hálózat a szerkesztő forgalmát viszi több ezer stat-hívás helyett. Ugyanaz a javítás, mint egy helyi klón, üzembe helyezési döntésként megfogalmazva, nem migrációként.

A szinkronizálás tulajdonosokkal rendelkező munkafolyamat, nem gyorsítótár

Egy szinkronizált munkaterület csökkentheti az ismételt távoli olvasásokat, de nem átlátszó gyorsítótár. Kell hozzá tulajdonos minden változáshoz, szabály az ütközésekhez és megállapodás a generált fájlokról, amelyeket mindkét fél a sajátjának hisz. E szabályok nélkül az elrendezés nézeteltérést teremt a kényelem helyett.

A kétirányú szinkronizáló ezek nélkül más problémát szül, mint amit megoldott, általában olyan összefésülést, amelyet senki nem tud hozzárendelni. Kerülje két Git-folyamat futtatását egyetlen közös munkafán, hacsak nem érti, hogyan hangolódnak össze.

Aztán hangoljon, és tartsa józanul az SSH-t

Amikor az elrendezés helyes, két beállítás változtatja meg, hány fájlról kell a Gitnek kérdeznie: status.showUntrackedFiles és a követetlen gyorsítótár a core.untrackedCache mögött. Egyik sem változtatja meg, mennyibe kerül egy kérdés 40 ms alatt; csak azt változtatják, hány kérdés van. Csak akkor tekerjen egy gombot, amikor az oda-vissza utak helyiek.

Időmérje le azt a parancsot, ami idegesíti, ahelyett hogy egy nagy fájlt másoló mérce alapján következtetne, és hagyja békén a támogatott SSH-titkosítást. Egy elavult titkosítás nem rövidít egy oda-vissza utat; hozzáad egy második problémát, amely túléli az elsőt. A git status referenciája megér egy olvasást, mert a parancs sokkal több munkát végez, mint amennyit a neve sugall.