COMUN: flux SVN + git

SVN = sursa de adevăr. git = oglindă. Pe main din COMUN scrie doar roa_sync.

De ce: COMUN e același repo git ținut în 8 copii, câte una per proiect. main are un singur furnizor — SVN, prin roa_sync. Conținut intrat pe altă ușă revine oricum ca sync SVN rN după svn commit: același conținut, alt SHA, conflict.

Utilizatorul doar aprobă

Comenzile le rulezi tu: roa_sync.bat, svn commit, roa_sync.bat. El nu ține minte niciun pas și nu tastează nimic — dar nimic nu se comite fără un „da" explicit de la el.

Deci: nu te opri tăcut după ce livrezi diff-ul. Întreabă, cu fișierele și mesajul propuse.

Flux

   .prg / .md / .ps1 / .sql              .vc2 / .sc2
            │                                 │
            │                        txt2vcx.ps1  <- IMEDIAT
            │                                 │
            │                        verifica pe BINAR
            └────────────────┬────────────────┘
                             │
                antet la zi  +  test rulat
                             │
                diff ca fisier in docs\
                             │
                INTREBI: fisiere + mesaj  -->  "da" ?  --no--> stop
                             │ da
                svn commit TINTIT   (.prg | .scx + .sct  -- niciodata .sc2)
                             │
                roa_sync.bat  -->  main:  sync SVN rN

Cazuri

Intri în proiect → rulezi roa_sync.bat, fără să întrebi, dacă svn status și git status sunt curate. Dacă nu sunt, întrebi întâi — pot fi modificări nefinalizate ale altcuiva.

Ai editat .prg / .md / .ps1 / .sql → antetul la zi, testul rulat, diff-ul ca fișier în docs\.

Ai editat .vc2 / .sc2 → txt2vcx.ps1 imediat, apoi verifici pe binar (reconvertești binarul într-un cache temporar și compari cu textul din arbore; mtime nu dovedește nimic). Text fără write-back = modificarea nu există. Abia apoi antet / test / diff.

Vrei să-ți ții munca în git → branch. În repo-ul proiectului: liber. În COMUN: claude/<subiect>, commit doar acolo, niciodată pe main.

Ai terminat branch-ul → în repo-ul proiectului: merge în main, normal. În COMUN: nu face merge. După svn commit, conținutul ajunge pe main ca sync SVN rN; branch-ul se șterge.

Ești pe branch în COMUN și te bate gândul la roa_sync → nu. roa_sync se rulează în exact două momente: la intrarea în proiect și imediat după svn commit. Ce te încurcă e svn update de la pasul 1, nu git-ul:

branch cu modificări necomise → svn update rulează necondiționat și aduce fișierele altor proiecte peste ce ai pe disc; la binare dă conflict și roa_sync se oprește cu eroare. Git, în schimb, e cuminte: vede tree murdar pe branch și sare peste, nu-ți atinge branch-ul.
branch cu tree curat → roa_sync face checkout main fără să întrebe. Textele de pe disc revin la main, binarele nu (git nu le urmărește) → rămâi cu text de pe main peste binare de pe branch. Munca e în commit, dar nu mai e pe disc, iar VFP ar compila altceva.
curățenia de la pasul 5 șterge doar branch-urile claude/* al căror git diff main..branch e gol, adică cele a căror muncă a intrat deja prin SVN. Ce n-a intrat rămâne, raportat „activ".

Dacă chiar trebuie să aduci ceva de la alții în mijlocul lucrului: termină write-back-ul, dă svn commit dacă lucrarea e gata, și abia apoi roa_sync.

Vrei să aduci ce au făcut alții → roa_sync.bat. Niciodată git pull: git poartă doar textele, nu și binarele. Un pull ți-ar da .sc2-ul nou peste un .scx/.sct vechi — VFP compilează binarul, deci modificarea n-ar exista în aplicație, iar următorul git_sync ar regenera textul din binarul vechi și ar șterge-o. În plus, fișierele scrise de git peste un working copy rămas la o revizie veche apar în svn status ca și cum ar fi munca ta. roa_sync face ordinea corectă: svn update (binare + surse) → regenerare text → git prin fast-forward.

Vrei svn update → doar din stare curată. Niciodată în mijlocul lucrului: aduce binare noi peste ce ai pe disc. Dacă ai text .??2 editat fără write-back, fă întâi write-back-ul.

svn update a dat conflict → oprește-te și raportează. Binarele nu se rezolvă manual.

După svn update, git arată fișiere modificate → e oglinda rămasă în urmă, nu munca ta. Nu le comite de mână; le ia roa_sync într-un sync SVN rN.

Diff-ul e gata → ceri aprobarea, explicit și complet: lista fișierelor de comis și mesajul propus. Nu presupune „da" din tăcere și nu amâna întrebarea pentru „mai târziu" — el nu ține minte pasul, tu îl ții.

A zis „da" → rulezi tu svn commit țintit, doar fișierele aprobate — pe binar (.scx + .sct), nu pe .sc2. Niciodată pe tot COMUN: intră zgomotul de compilare VFP. Imediat după, rulezi roa_sync.bat. Raportezi revizia SVN și ce a intrat pe main.

A zis „nu" sau a cerut modificări → nu comiți, nu insiști, nu rulezi roa_sync. Lucrarea rămâne necomisă pe disc și o raportezi ca atare la predarea contextului.

Predai contextul → raportează explicit dacă ai lăsat text .??2 editat fără write-back. E stare periculoasă.

Interzis

git commit / git push / git merge pe main în COMUN
git pull în COMUN — aduce textele fără binare; se folosește roa_sync.bat
copierea unui fișier dintr-o copie de COMUN în alta — svn update îl duce; copierea = intrare dublă
write-back pe .fr2 / .mn2 / .lb2 / .pj2 — nu e suportat; acolo textul se citește, modificarea se face în IDE

Copii rămase în urmă

Nimic nu se sincronizează în fundal. O copie neatinsă de luni se aliniază singură la primul roa_sync.bat rulat de acolo: svn update → regenerare text → sync SVN rN → fetch → ff sau rebase --empty=drop, care aruncă automat sync-urile al căror conținut e deja pe origin. De aceea regula veche „un singur folder publisher" e retrasă: numărul de copii nu mai contează.

6.3 KiB Raw Blame History