flora2roa/docs/flux_git_flora2roa.md

Flux SVN + git in FLORA2ROA

Adaptarea locala a procesului comun ROA din D:\ROA\ROACONT\COMUN\docs\fluxul_svn_git.md. Acolo e originalul; aici sunt doar particularitatile acestui proiect. Metoda de editare pe text: COMUN\docs\flux-editare-vfp-text.md.

SVN e sursa de adevar. git e oglinda. Binarele VFP (frm_import.scx/.sct, flora2roa.pjx/.pjt, .fll, .exe) traiesc doar in SVN; git urmareste versiunile TEXT (.sc2, .pj2) generate in arbore de FoxBin2Prg, plus .prg, Teste\, docs\.

• SVN: http://svnroa:3001/svn/ROAIMPORT/FLORA2ROA
• git: git@gitea.romfast.ro:romfast/flora2roa.git (remote origin, branch main)

Utilizatorul doar aproba

Comenzile le rulezi tu: roa_sync.bat, svn commit, roa_sync.bat. El nu tine minte niciun pas si nu tasteaza nimic - dar nimic nu se comite fara un "da" explicit de la el.

Deci nu te opri tacut dupa ce livrezi diff-ul. Intreaba, cu fisierele si mesajul propuse.

Fluxul

   .prg / .md / .ps1 / .sql                    .sc2 / .pj2
            |                                       |
            |                          bin_din_text.ps1   <- IMEDIAT
            |                                       |
            |                          recompileaza_binare.ps1
            |                                       |
            |                              verifica pe BINAR
            +--------------------+------------------+
                                 |
                     antet la zi  +  test rulat
                                 |
                     diff ca fisier in docs\
                                 |
                     INTREBI: fisiere + mesaj  -->  "da" ?  --nu--> stop
                                 | da
                     svn commit TINTIT  (.prg | .scx + .SCT  -- niciodata .sc2)
                                 |
                     roa_sync.bat  -->  main: sync SVN rN

Particularitatea acestui proiect

FLORA2ROA nu are folder COMUN\ (spre deosebire de ROACONT/ROAGEST/ROAFACTURARE, unde COMUN e un external SVN cu repo git propriu). Foloseste doar un comun.h local. Prin urmare:

• nu exista COMUN\.git de sincronizat aici; repo-ul romfast/comun.git e gestionat din proiectele care il contin efectiv;
• scriptul partajat COMUN\scripts\roa_sync.ps1 nu ajunge aici prin svn update, deci exista un echivalent local: Teste\roa_sync.ps1, apelat de roa_sync.bat din radacina. Face aceiasi pasi, minus repo-ul COMUN si minus inchiderea automata a branch-urilor claude/*;
• scripturile de conversie au nume locale: Teste\text_din_bin.ps1 (= git_sync.ps1) si Teste\bin_din_text.ps1 (= txt2vcx.ps1);
• in plus fata de fluxul comun, dupa fiecare write-back e OBLIGATORIU Teste\recompileaza_binare.ps1: write-back-ul reface .scx/.SCT fara cod obiect, deci formularul ruleaza fara #INCLUDE "comun.h" si constantele (CT_SUCCES) crapa in RUNTIME, desi verificarea de sintaxa trece;
• fiind repo de proiect, nu COMUN, branch-urile si commit-urile git pe main sunt permise. Ce e restrictionat e doar push-ul automat: roa_sync publica singur numai commit-urile sync SVN rN; orice commit non-sync nepushed blocheaza push-ul si apare ca avertisment, ca sa treaca intai prin review.

Cazuri

Intri in proiect -> rulezi roa_sync.bat, fara sa intrebi, daca svn status si git status sunt curate. Daca nu sunt, intrebi intai - pot fi modificari nefinalizate ale altcuiva.

Ai editat .prg / .md / .ps1 / .sql -> antetul la zi, testul rulat (Teste\verifica_sintaxa.ps1 dupa orice .prg), diff-ul ca fisier in docs\.

Ai editat .sc2 -> bin_din_text.ps1 imediat, apoi recompileaza_binare.ps1, apoi verifici pe binar (reconvertesti binarul intr-un folder temporar si compari cu textul din arbore; mtime nu dovedeste nimic). Text fara write-back = modificarea nu exista. Abia apoi antet / test / diff.

Vrei sa-ti tii munca in git -> branch, liber (claude/<subiect> e conventia). Fiind repo de proiect, merge-ul in main la final e normal.

Esti pe branch si te bate gandul la roa_sync -> nu. roa_sync se ruleaza in exact doua momente: la intrarea in proiect si imediat dupa svn commit. Ce te incurca e svn update de la pasul 1, nu git-ul:

• branch cu modificari necomise -> svn update ruleaza neconditionat si aduce binare noi peste ce ai pe disc; la conflict roa_sync se opreste cu eroare;
• branch cu tree curat -> ramai cu text de pe main peste binare de pe branch, iar VFP ar compila altceva.

Daca chiar trebuie sa aduci ceva de la altii in mijlocul lucrului: termina write-back-ul, da svn commit daca lucrarea e gata, si abia apoi roa_sync.

Vrei sa aduci ce au facut altii -> roa_sync.bat. Niciodata git pull: git poarta doar textele, nu si binarele. Un pull ti-ar da .sc2-ul nou peste un .scx/.SCT vechi - VFP compileaza binarul, deci modificarea n-ar exista in aplicatie, iar urmatorul text_din_bin ar regenera textul din binarul vechi si ar sterge-o. roa_sync face ordinea corecta: svn update (binare + surse) -> regenerare text -> git prin fast-forward.

Vrei svn update -> doar din stare curata. Niciodata in mijlocul lucrului. Daca ai text .sc2 editat fara write-back, fa intai write-back-ul.

svn update a dat conflict -> opreste-te si raporteaza. Binarele nu se rezolva manual.

Dupa svn update, git arata fisiere modificate -> e oglinda ramasa in urma, nu munca ta. Nu le comite de mana; le ia roa_sync intr-un sync SVN rN.

Diff-ul e gata -> ceri aprobarea, explicit si complet: lista fisierelor de comis si mesajul propus. Nu presupune "da" din tacere si nu amana intrebarea pentru "mai tarziu" - el nu tine minte pasul, tu il tii.

A zis "da" -> rulezi tu svn commit tintit, doar fisierele aprobate - pe binar (frm_import.scx + frm_import.SCT), niciodata pe .sc2. Niciodata pe tot proiectul: intra zgomotul de compilare VFP. Imediat dupa, rulezi roa_sync.bat. Raportezi revizia SVN si ce a intrat pe main.

A zis "nu" sau a cerut modificari -> nu comiti, nu insisti, nu rulezi roa_sync. Lucrarea ramane necomisa pe disc si o raportezi ca atare la predarea contextului.

Predai contextul -> raporteaza explicit daca ai lasat text .sc2 editat fara write-back sau write-back fara recompilare. Amandoua sunt stari periculoase.

Interzis

• git pull - aduce textele fara binare; se foloseste roa_sync.bat
• svn commit pe tot proiectul sau pe .sc2
• write-back pe .pj2 - nu e suportat; acolo textul se citeste, modificarea se face in IDE
• svn commit fara acordul explicit al utilizatorului (atinge binarele)

Comenzi

roa_sync.bat                                                    # inceput de sesiune si dupa svn commit
powershell -File Teste\roa_sync.ps1 -GitOnly                    # verificare rapida, fara SVN

powershell -ExecutionPolicy Bypass -File Teste\text_din_bin.ps1                          # binar -> frm_import.sc2
powershell -ExecutionPolicy Bypass -File Teste\bin_din_text.ps1 -TextFile frm_import.sc2 -DryRun
powershell -ExecutionPolicy Bypass -File Teste\bin_din_text.ps1 -TextFile frm_import.sc2
powershell -ExecutionPolicy Bypass -File Teste\recompileaza_binare.ps1                   # OBLIGATORIU dupa write-back

Textul .sc2 se editeaza byte-safe, in Windows-1252 (vezi COMUN\docs\conventie_encoding_cp1252.md):

$t = [IO.File]::ReadAllText($p, [Text.Encoding]::GetEncoding(1252))
[IO.File]::WriteAllText($p, $t, [Text.Encoding]::GetEncoding(1252))

Write-back-ul face fidelity check pe octeti inainte de a atinge binarul. Dupa el, binarul apare modificat in SVN.

Ce urmareste git

Urmarite: .prg, .h, .sc2/.pj2 (textele binarelor), Teste\, docs\, settings.ini, settings.flora.ini, app.ico, .fll (dependente de rulare, versionate si in SVN), exemplele mici de import care sunt si in SVN.

Ignorate (.gitignore): binarele convertibile (.scx/.sct/.pjx/.pjt/...), compilatele (.fxp), flora2roa.exe, log\, artefactele testelor (Teste\uisync, Teste\screenshots, *_log.txt), patch-urile de review (docs\diff_*.patch), si restul folderului EXEMPLE\ (~900 fisiere, ~80 MB de date locale de lucru; in git raman doar cele 7 exemple versionate si in SVN).

.gitattributes are * -text: SVN ramane autoritatea pentru sfarsiturile de linie, git nu normalizeaza nimic (altfel ar aparea modificari fantoma dupa fiecare svn update).

Simetric, svn:ignore pe radacina acopera .git, .gitignore, .gitattributes si toate textele .??2, ca sa nu ajunga din greseala in SVN.

Copii ramase in urma

Nimic nu se sincronizeaza in fundal. O copie neatinsa de luni se aliniaza singura la primul roa_sync.bat rulat de acolo: svn update -> regenerare text -> sync SVN rN -> fetch -> ff sau rebase --empty=drop, care arunca automat sync-urile al caror continut e deja pe origin.