Files
comun/skills/roa-git-svn-commit/SKILL.md
2026-09-17 17:27:22 +03:00

7.8 KiB

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.

SVN sau git: decizia NU se face manual

Regula de baza: in proiectul ROA si in COMUN, fisierele sursa (.prg, .md, .ps1, .sql, .bat, AGENTS.md, .vcx/.scx, .vc2/.sc2) sunt SVN-tracked. git commit se foloseste doar pentru fisiere care NU sunt in SVN (.gitignore, .gitattributes, fisiere generate). Nu ghici - verifici inainte de orice commit, cu o singura comanda:

svn info "<cale_fisier>" >$null 2>&1
if ($?) { 'SVN -> svn commit' } else { 'git -> git commit' }

Decizia pe svn status <cale>:

  • M / A / D -> SVN -> svn commit (niciodata git commit).
  • ? (neversionat) -> daca e sursa care trebuie sa circule la clienti -> svn add apoi svn commit; daca e local/transient (handoff, plan, .patch, .gitignore) -> NU se comite.

Ce e de comis, descoperit cu comenzi (nu din memorie):

svn status <proiect_sau_COMUN>          # M/A/D = de comis in SVN; ? = neversionat
git -C <repo> status --short            # doar oglinda; nu comiti aici fisierele SVN-tracked

Cazul care a muscat: AGENTS.md e SVN-tracked (svn/ROA/ROAFACTURARE/Trunk/AGENTS.md). Comis cu git commit, creeaza un commit "non-sync" (nu l-a produs roa_sync) si lasa SVN-ul in urma -> alt calculator nu primeste schimbarea prin svn update. Se repara: git reset <ultim_sync> + svn commit AGENTS.md + roa_sync.bat + git push --force (doar daca commit-ul non-sync era deja impins).

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, cu comenzile exacte (nu le alegi tu - le rulezi asa):

    # fisiere noi -> intai svn add
    svn add <fisier1> <fisier2>
    # commit tintit: .prg / .md / .ps1 / .sql / .scx + .sct - niciodata .sc2, niciodata tot COMUN
    svn commit <fisier1> <fisier2> -m "<mesaj>"
    
  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/<subiect>, 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 <root>, 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.