# 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ă.