Bogdan’s Developer Blog

Dacă ai făcut commit la ceva ce nu trebuia, sau nu la tot ce trebuia, sau pur şi simplu ai nevoie de asta din alt motiv, soluţia constă în câteva mişcări rapide. Cu magenta, am evidenţiat variabilele din comenzile de mai jos, adică ce trebuie înlocuit în funcţie de situaţia ta.

$ cp /path/to/repo /path/to/repo_backup -R

Am creat mai întâi un backup la structura de fişiere a repository-ului;
/path/to/ este calea către repository (atenţie, nu a lui working copy), iar repo este numele repository-ului; de exemplu, la mine ar putea fi /var/svn/repositories/test.

$ svnadmin dump /path/to/repo - - revision 0:n > dumpfile

Am făcut dump într-un fişier la toate reviziile între 0 şi n, inclusiv;
n este numărul reviziei dinaintea ultimei, n+1 fiind revizia curentă, la care renunţăm;
dumpfile este fişierul în care redirecţionăm output-ul comenzii, care altfel iese în stdout;
Metoda asta poate fi folosită şi pe post de backup la repository.

$ rm -rf repo

Am şters repository-ul, nu mai avem nevoie de el (încă avem repo_backup, dacă ceva nu merge bine de-acum înainte).

$ svnadmin create repo - - fs-type=tip

Am creat un repository gol, cu numele cel vechi;
Nu e suficient să creez doar directorul - când importăm mai târziu din dumpfile, vom primi erori dacă nu avem un repository gol;
Tipul repository-ului nou (bdb - sau - fsfs) trebuie să fie identic celui vechi. Înlocuieşte tip cu valoarea potrivită. Dacă nu eşti sigur care din ele este, poţi să-l afli din backup, cu comanda:

$ cat /path/to/repo_backup/db/fs-type

Trecem mai departe.

$ svnadmin load repo < dumpfile

Am importat conţinutul lui dumpfile, în repository-ul gol, nou creat.

În unele cazuri, mai trebuie ca owner-ul structurii de fişiere a repository-ului nou creat să fie identic cu cel al vechiului repository:

$ cd /path/to
$ ls -al | grep repo_backup
drwxr-xr-x 7 A B 4096 2008-05-18 01:28 repo_backup
$ sudo chown A:B -R repo

Privind iarăşi către backup-ul făcut înainte, am setat owner-ul recursiv pentru întreaga structură de fişiere a noului repository (deseori A coincide cu B);
În cazul meu, fluxurile SVN sunt servite de Apache (prin WebDAV), iar serverul Apache trebuie să aiba drepturi depline asupra directorului unde se află repository-ul; în cazul meu A = B = www-data (userul sub care rulează Apache sub Debian/Ubuntu). Creând acel repository la un pas anterior, owner-ul lui era utilizatorul de linux care a emis comanda .

Gata, asta e!

Un pas suplimentar, pentru cei ce folosesc un mediu Trac pentru urmărirea repository-ului SVN:

$ trac-admin /path/to/trac-environment resync

Am resincronizat mediul Trac (cache-ul lui intern, etc.), cu noul repository, care are mai puţin cu o revizie decât ştia Trac;
/path/to/trac-environment este calea către mediul Trac asociat repo-ului urmărit, de exemplu la mine ar putea fi /var/trac/test.

Note de final

Dacă doar vrei să schimbi comentariul de commit, autorul reviziei sau alte lucruri de genul ăsta, soluţia este alta - svn propset.

Working copy a rămas la revizia n+1 (dând acel commit total nefast) şi lucrurile o să-ţi cam crape în acest moment (am încercat svn cleanup şi alte variante => no use!). Soluţia este să faci un checkout nou într-un alt director şi apoi să mergi cu o unealtă specializată de tip diff (de exemplu, Araxis Merge sau WinMerge sub Windows) şi să faci un merge manual între cele două directoare. Dacă dai peste o soluţie mai buna, feel free to share it!

Ce am scris mai sus, merge de minune în linux (testat în Debian 4.0r3 cu svnadmin 1.4.2 şi trac-admin 0.10.3), în Windows nu am încercat / nu ştiu cum e. De asemenea, trebuie să ai şi drepturile potrivite pentru toate mişcările astea. Ce faci este pe riscul tău, dar dacă ai backup aşa cum am recomandat înca de la început, you should be fine.