Developers sasa wanaweza kuanzisha vipindi kadhaa vya wakala wa uandishi wa kodi (coding-agent sessions) kwa wakati mmoja bila kuogopa faili za hali (state files) kufutwa au migongano ya faili iliyojificha. Mfumo wa kutoa ushauri wa “share-nothing” hutenga eneo la kazi la kila wakala na kutoa onyo kuhusu migongano inayoweza kutokea. Njia hii inabadilisha vizuizi vikali (hard locks) kwa rejista nyepesi inayotambua kazi zinazogongana kabla hazijatokea, na kuwezesha mifumo ya kazi (pipelines) kuendelea hata wakati kikao kinapofeli.

Kwa nini wakala sambamba hukwama

Kuendesha zaidi ya msaidizi mmoja wa uandishi wa kodi wa kiotomatiki katika sehemu moja (repository) huongeza kasi ya uundaji wa kodi, upimaji, au uboreshaji wa kodi (refactoring). Katika vitendo, matatizo mawili hujitokeza mara moja.

  • Uharibifu wa hali (State corruption) – Wakala wawili wanaandika kwenye faili moja ya hali; maandishi ya baadaye yanafuta yale ya awali, na hivyo kufuta maendeleo.
  • Mgongano wa faili (File collision) – Wakala wawili wanahariri faili moja ya chanzo bila kujua kuhusu mwingine. Mgongano huo hujitokeza baadaye, wakati tofauti (diff) inapoonyesha mabadiliko yanayotofautiana.

Matatizo yote mawili yanapoteza muda wa mwanatengenezaji na yanaweza kuleta hitilafu (bugs) ngumu kufuatilia.

Kanuni ya “share nothing”

Wazo kuu ni rahisi: kila wakala hupata sehemu yake binafsi ya muda (scratchpad) kwenye diski na huandika kwenye faili zinazomilikiwa na kikao hicho pekee. Inaruhusiwa faili moja tu inayoshirikiwa kwa makusudi kwa kila tawi (branch), na inafuata kanuni ya “last-writer-wins”—wakala yeyote atakayeandika mwisho ndiye anayeamua maudhui ya mwisho.

Tabaka la uwepo (presence layer) hufuatilia kila kikao kinachofanya kazi:

  • Jina la tawi (branch name)
  • Orodha ya faili zinazoguswa
  • Muda wa shughuli ya mwisho

Kikao kipya kinapoanza, hurejelea rejista. Ikiwa kikao kingine tayari kinashughulikia faili yoyote ile ile, mwanatengenezaji hupokea onyo kabla ya kazi yoyote kuanza.

Kuzuia kwa kutoa ushauri (Advisory) dhidi ya kuzuia kabisa (Blocking)

Faili za kizuizi (lock files) za kimapokeo hufanya kazi kama barabara isiyo na mwisho: mara tu kizuizi kinapochukuliwa, mchakato mwingine wowote unasubiri hadi kizuizi hicho kiachiliwe. Ikiwa kikao kinachomiliki kizuizi hicho kitafeli (crash), kizuizi kinaweza kubaki bila sababu kwa muda mrefu, na kulazimisha utafutaji wa kumanusia wa faili za kizuizi zilizopitwa na wakati.

Mfumo wa kutoa ushauri (advisory model) ni mwanana zaidi. Unatoa onyo wakati mgongano unaoweza kutokea unapogunduliwa lakini hauzuia kikao kipya. Ikiwa ingizo la rejista ni la zamani—ikimaanisha mchakato uliolitengeneza haupo tena—mfumo bado unatoa onyo tu, na kumwacha mwanatengenezaji kuamua ikiwa ataendelea.

Jinsi ya kutekeleza mfumo huu

  1. Gawanya hali kulingana na mwandishi – Mpe kila wakala directory yake ya faili za muda na hali. Weka faili zinazoshirikiwa kwa ajili ya data za kimataifa pekee na utumie kanuni ya last-writer-wins pale tu.
  2. Ingiza uelewa wakati wa kuanza – Kabla ya wakala kuanza, soma rejista ya uwepo na ulinganishe orodha ya faili zinazohitajika na ingizo zilizopo. Kataa au toa onyo ikiwa kuna mwingiliano utakaopatikana.
  3. Hakiki uhai wakati wa kusoma – Unaporejelea ingizo la rejista, angalia ikiwa ID ya mchakato iliyorekodiwa bado inafanya kazi kwenye OS. Futa ingizo zinazomilikiwa na michakato iliyokufa.
  4. Pendelea kutoa ushauri badala ya kuzuia – Waruhusu wanatengenezaji kubaki na udhibiti. Onyo huwaruhusu kuendelea, kusimama, au kusitisha, na kuepuka kukwama (deadlock).
  5. Fuatilia hali za kusubiri – Wakala wengi wanapokuwa hai, umakini wa mwanatengenezaji un