Un branch poate sa faca oricine are access la subversion fara sa intrebe pe nimeni. Intr-un branch este OK sa experimentezi cu absolut orice fara sa-ti faci griji ca strici site-ul pentru altii. Cand consideri ca este gata de copiat in trunk poti sa chemi pe cineva sa se uite peste modificari. Modificarile pot fi acceptate in trunk, sau pot aparea observatii si branchul poate fi respins. Daca un branch este respins poti sa ii rezolvi problemele si sa il propui din nou pentru includere in trunk.

Ne dorim sa punem doar modificari aproximativ atomice in trunk, care sa nu introduca bug-uri. Este in continuare OK sa aplici bugfix-uri si tweak-uri minore de CSS direct in trunk. Branch-urile sunt necesare pentru feature-uri de genul blog, latex, array_validate, dataset-uri, caching, tag-uri, etc.

Ne dorim sa punem doar modificari aproximativ atomica in trunk, care sa nu introduca bug-uri. Este in continuare OK sa aplici bugfix-uri si tweak-uri minore de CSS direct in trunk. Branch-urile sunt necesare pentru feature-uri de genul blog, latex, array_validate, dataset-uri, caching, tag-uri, etc.

h3. Responsabilitati

h3. Wiki

La baza site-ului vom avea o componenta de versionare de fisiere. Aceasta componenta nu stie absolut nimic de useri, probleme, securitate sau tag-uri. Orice semnificatie a fisierelor este data doar de mai sus. De la aceasta componenta ne dorim urmatoarele:
 * Fetch rapid, cu cache transparent pe disc. Nu servim fisiere direct baza de date.
 * Istorie completa a modificarilor
 * Delete reversibil, care sa apara in istorie
 * Mutare/copiere pastrata in istorie.
 * Posibilitatea de a distruge complet o revizie
 
Nu avem nevoie de:
 * Directoare. Ne trebuie doar fisiere.
 * Meta-date. Versionam doar blob-uri; eventual cu cateva coloane strongly-typed (mime type?)
 * Notiuni de securitate.
 * Schimbari atomice pe mai multe fisiere.
 
Este dificil sa satisfacem toate cerintele folosind tabele de SQL, dar se poate face. Multe cerinte pot fi relaxate pana aproape de nivelul infoarena2. O varianta interesanta ar fi sa folosim subversion pentru versionare, dar din pacate nu se mapeaza perfect pe ce vrei noi.
 

h3. MVC

Avem ca si in infoarena2 un singur entry-point in tot site-ul. Acolo analizam requestul (ne uitam la url si query string) dupa care pasam munca la un controller. Un controller este o functie python care se ocupa de un intreg request. Controllerele nu se cheama niciodata unul pe altul.
 
Multe controllere vor folosi probabil suportul de versionare. Trebuie sa putem refolosi usor codul de editare si istorie.
 

h3. Securitate
h3. Logica de concursuri