--- name: roa-git-svn-commit description: Fluxul de commit si sincronizare pentru biblioteca partajata COMUN (SVN = sursa de adevar, git = oglinda), cu arbore de decizie pentru roa_sync, write-back, aprobare explicita si svn commit tintit, ca sa nu pierzi munca necomisa. Foloseste-l OBLIGATORIU cand utilizatorul spune "am terminat, dau commit", "vreau sa comit in COMUN", "comit ce am lucrat", "sincronizeaza cu SVN", "adu ce au facut altii", "ruleaza roa_sync", "de ce nu merge git pull in COMUN" sau cere orice commit/sincronizare care atinge COMUN. Regula centrala: pe main din COMUN scrie DOAR roa_sync, commit-urile se fac tintit pe fisierele aprobate (niciodata pe tot COMUN), iar git pull in COMUN este interzis. Nu improviza ordinea pasilor si nu rula roa_sync pe un tree murdar: distruge munca necomisa. --- # Commit si sincronizare in COMUN (SVN + git) SVN = sursa de adevar. git = oglinda. Pe `main` din COMUN scrie **doar** `roa_sync`. Comenzile le rulezi tu; utilizatorul doar aproba - dar nimic nu se comite fara un "da" explicit de la el. ## Cand se foloseste - "am terminat, dau commit", "vreau sa comit in COMUN", "comit ce am lucrat"; - "sincronizeaza cu SVN", "adu ce au facut altii", "ruleaza roa_sync", "de ce am conflicte"; - intrarea intr-o sesiune de lucru in proiect (sync de inceput). Nu se aplica altui repo decat COMUN + proiectul care il contine. Pentru editarea codului VFP (`.vcx`/`.scx` prin `.vc2`/`.sc2`) vezi skill-ul `roa-vfp-text-edit`. ## Pasi Arbore de decizie - opreste-te la primul caz care se potriveste. 1. **Intri in proiect** -> rulezi `roa_sync.bat`, fara sa intrebi, DOAR daca `svn status` si `git status` sunt curate. Daca nu sunt, intrebi intai (pot fi modificari nefinalizate ale altcuiva). 2. **Ai editat `.prg` / `.md` / `.ps1` / `.sql`** (proiect sau COMUN) -> antetul la zi, testul rulat, diff-ul scris ca fisier in `docs\`. 3. **Ai editat `.vc2` / `.sc2`** -> `txt2vcx.ps1` IMEDIAT, apoi verifici pe binar (reconversie intr-un cache temporar + comparatie; mtime nu dovedeste nimic). Text fara write-back = modificarea nu exista. Abia apoi antet / test / diff. 4. **Ceri aprobarea, explicit si complet**: lista fisierelor de comis + mesajul propus. Nu presupune "da" din tacere si nu amana pentru "mai tarziu" - el nu tine minte pasul, tu il tii. 5. **A zis "da"** -> rulezi tu `svn commit` **tintit**, doar fisierele aprobate: `.prg` sau `.scx` + `.sct`, niciodata `.sc2`. Niciodata tot COMUN (intra zgomotul de compilare VFP). 6. **Imediat dupa** -> `roa_sync.bat`. Raportezi revizia SVN si ce a intrat pe `main`. 7. **A zis "nu" / cere modificari** -> nu comiti, nu insisti, nu rulezi `roa_sync`. Lucrarea ramane necomisa pe disc si o raportezi asa la predarea contextului. ### Cazuri - **Vrei sa-ti tii munca in git** -> branch. In repo-ul proiectului: liber. In COMUN: `claude/`, commit doar acolo, niciodata pe `main`. - **Ai terminat branch-ul** -> proiect: merge in `main`, normal. COMUN: **fara merge**; dupa `svn commit` continutul ajunge pe `main` ca `sync SVN rN`, iar branch-ul se sterge (doar daca `git diff main..branch` e gol). - **Esti pe branch in COMUN 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`. Pe branch cu tree curat face `checkout main` fara sa intrebe (binarele raman de pe branch); pe branch murdar sare peste, dar `svn update` de la pasul 1 ruleaza oricum si poate aduce binare peste ce ai pe disc. - **Vrei `svn update`** -> doar din stare curata, niciodata in mijlocul lucrului. Daca ai text `.??2` 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`. - **Vrei sa aduci ce au facut altii** -> `roa_sync.bat`. **Niciodata `git pull`**: git poarta doar textele, nu binarele; un pull da `.sc2` nou peste `.scx/.sct` vechi, VFP compileaza binarul, iar urmatorul `git_sync` sterge modificarea. - **Copie de COMUN ramasa in urma** -> se aliniaza singura la primul `roa_sync.bat` rulat acolo. - **Predai contextul** -> raporteaza explicit daca ai lasat text `.??2` editat fara write-back (stare periculoasa). ## Interzis - `git commit` / `git push` / `git merge` pe `main` in COMUN. - `git pull` in COMUN - aduce textele fara binare; se foloseste `roa_sync.bat`. - `git commit` pe tot COMUN sau pe `.sc2` - doar tintit, pe fisierele aprobate. - Copierea unui fisier dintr-o copie de COMUN in alta - `svn update` il duce; copierea = intrare dubla. - Write-back pe `.fr2` / `.mn2` / `.lb2` / `.pj2` - nesuportat; acolo se modifica in IDE. - Commit fara un "da" explicit de la utilizator. ## Criterii de acceptare si dovada Fara dovada da/nu de mai jos, commit-ul/sincronizarea NU se raporteaza ca terminata. "Arata bine" nu e dovada. 1. Inainte de commit: `git status --porcelain` contine EXACT fisierele aprobate; nimic neasteptat stagiat. 2. Dupa `svn commit`: `svn status` curat pe fisierele tintite, iar revizia SVN este raportata. 3. Dupa commit: `roa_sync.bat` a rulat si raporteaza succes (exit 0, commit `sync SVN rN` pe `main` in COMUN, fara avertismente de conflict). 4. `git status` curat pe fisierele tintite in COMUN; branch-urile `claude/*` terminate sunt inchise, cele active raportate. 5. Verificarea se face inainte de `svn commit`: fara "da" explicit, commit-ul nu are loc (skill-ul nu comite din proprie initiativa). 6. Daca utilizatorul a zis "nu": dovada e absenta oricarei urme de commit sau sync in log. ## Scripturi - `D:\ROA\ROAFACTURARE\roa_sync.bat` (sau `roa_sync.bat` din radacina proiectului). - `D:\ROA\ROAFACTURARE\COMUN\scripts\roa_sync.ps1` - `-ProjectRoot `, iar `-GitOnly` sare peste SVN si regenerarea textelor. - `D:\ROA\UTIL\foxbin2prg\txt2vcx.ps1` si `git_sync.ps1` - doar daca ai atins binare. ## Referinta (doar la nevoie) - Doar daca ai nevoie de contextul complet, citeste `COMUN\docs\fluxul_svn_git.md` (cazuri, interdictii) pentru fluxul SVN + git.