| subversiune | |
|---|---|
| Tip de | sistem centralizat de control al versiunilor [d] , proiectul Apache Foundation [d] șisoftware open source |
| Autor | CollabNet [d] |
| Dezvoltator | Apache Software Foundation |
| Scris in | C [4] [5] , Python [4] , C++ [6] [7] și Java [6] [7] |
| Sistem de operare | GNU/Linux [8] , Microsoft Windows [8] , macOS [8] și BSD [8] |
| Prima editie | 20 octombrie 2000 [1] |
| ultima versiune |
|
| Formate de fișiere care pot fi citite | Format dump SVN (v1) [d] , format dump SVN (v2) [d] , format dump SVN (v3) [d] și format dump SVN (generic) [d] |
| Formate de fișiere generate | Format dump SVN (v1) [d] , format dump SVN (v2) [d] , format dump SVN (v3) [d] și format dump SVN (generic) [d] |
| Licență | Licență Apache 2.0 [9] |
| Site-ul web | subversion.apache.org _ |
| Fișiere media la Wikimedia Commons | |
Subversion [10] (cunoscut și ca „ SVN ” [11] ) este un sistem de control al versiunilor centralizat gratuit , lansat oficial în 2004 de CollabNet . Din 2010, Subversion este un proiect al Apache Software Foundation și se numește oficial Apache Subversion ( marcă înregistrată [12] ).
Scopul proiectului la începutul dezvoltării a fost să înlocuiască [13] [14] Sistemul de versiuni simultane (CVS) pe atunci larg răspândit , care este acum considerat învechit [15] [16] [17] . Subversion implementează toate caracteristicile principale ale CVS și este lipsită de unele dintre deficiențele acestuia din urmă.
Subversion este încă folosit de unele comunități open source (inclusiv cele care au folosit CVS înainte ), dar aproape toate proiectele majore au trecut la DVCS . Printre ultimii utilizatori ai Subversion printre proiectele deschise rămâne FreeBSD , dar au anunțat și o tranziție la Git [18] , și, de exemplu, Free Pascal . Subversion a fost folosită destul de mult timp de proiecte cunoscute precum Apache , GCC , FFmpeg , LLVM . Subversion este folosit și în proiecte private și în lumea corporativă, dar este greu de evaluat cât de larg. Găzduirea Subversion , inclusiv pentru proiecte open source, este oferită și de proiectele populare de găzduire SourceForge.net , Tigris.org , Google Code și BountySource .
În 2007, Forrester , o firmă de analiză , a evaluat Subversion drept „lider unic în categoria SCM (Standalone Software Configuration Management) și un contribuitor puternic în categoria Software Configuration and Change Management (SCCM)” atunci când a comparat avantajele și dezavantajele diverselor sisteme . [19]
Conform statisticilor privind utilizarea pachetelor Linux - distribuțiile Debian [20] și Ubuntu [21] , numărul de utilizatori activi ai Subversion a atins vârful în jurul anului 2010 și a început să scadă din 2016. Cu toate acestea, există încă mai multe proiecte care folosesc Subversion decât folosind CVS , Mercurial și Bazaar (din august 2019 ).
Documentația oficială este poziționată [22] de cartea publicată de O'Reilly Media , care este disponibilă gratuit [23] și adăugată de autori pe măsură ce sunt lansate noi versiuni ale SVN. De asemenea, își publică traducerile într-o serie de limbi, inclusiv rusă, dar în ciuda faptului că versiunile în engleză ale cărții descriu acum versiunile 1.8 și 1.7, există doar cărți în rusă care descriu versiuni până la 1.4 inclusiv [24] .
Dezvoltarea Subversion a început în 2000 la inițiativa și cu sprijinul financiar al CollabNet. Inițiatorii proiectului au dorit să creeze un sistem gratuit de control al versiunilor, practic similar cu CVS, dar lipsit de bug-urile și inconvenientele acestuia . La acea vreme nu existau cele mai bune programe din această clasă cu licență gratuită, CVS era standardul de facto printre dezvoltatorii de software liber. Alegându-l ca bază, dezvoltatorii Subversion au sperat să simplifice dezvoltarea prin valorificarea conceptelor deja dovedite, făcând în același timp mai ușor pentru mulți utilizatori CVS să migreze la noul sistem. [25]
Evenimente majore din istoria dezvoltării Subversion.
Subversion este un sistem centralizat (spre deosebire de sistemele distribuite precum Git sau Mercurial ), ceea ce înseamnă că datele sunt stocate într-un singur depozit. Depozitul poate fi localizat pe un disc local sau pe un server de rețea .
Lucrul în Subversion nu este mult diferit de lucrul în alte sisteme centralizate de control al versiunilor. Clienții copiază fișiere din seif pentru a crea copii locale de lucru, apoi efectuează modificări la copiile de lucru și commit acele modificări în seif. Mai mulți clienți pot accesa spațiul de stocare în același timp. Subversion utilizează în primul rând modelul copiere-modificare-imbinare pentru colaborarea la fișiere . De asemenea, pentru fișierele care nu pot fi îmbinate (diverse formate de fișiere binare), puteți utiliza modelul lock-modify-unlock .
La salvarea versiunilor noi, se folosește compresia delta : sistemul găsește diferențe între versiunea nouă și cea anterioară și le scrie numai, evitând duplicarea datelor.
Când utilizați accesul WebDAV, este acceptată și versiunea transparentă - dacă orice client WebDAV se deschide pentru scriere și apoi salvează un fișier stocat pe o partajare de rețea, se creează automat o nouă versiune.
Subversion oferă două opțiuni pentru organizarea depozitelor [40] . Arhivele de primul tip sunt folosite pentru a stoca o bază de date bazată pe Berkeley DB , depozitele de al doilea tip sunt fișiere obișnuite cu un format special (accesul la date este organizat folosind propriile biblioteci, fără a utiliza baze de date terțe). Dezvoltatorii Subversion se referă adesea la stocare ca la un „sistem de fișiere”, motiv pentru care al doilea tip se numește FSFS, adică un sistem de fișiere (versiune) ( sistem de fișiere în engleză ) deasupra unui sistem de fișiere (obișnuit).
Ambele tipuri de depozite oferă suficientă fiabilitate atunci când sunt organizate corespunzător [41] (Berkeley DB folosește blocări de fișiere, deci nu poate fi folosit pe unele sisteme de fișiere de rețea care nu suportă blocări), fiecare dintre ele are propriile avantaje și dezavantaje. Se crede că FSFS este mai ușor de configurat corect, necesită mai puțină atenție din partea administratorului. În plus, înainte de lansarea 1.4, depozitele care utilizează Berkeley DB puteau, în anumite condiții, să ajungă într- o așa-numită stare wedged ; a fost necesară intervenția administratorului pentru a-i restabili funcționalitatea.
Începând cu versiunea 1.2, FSFS este utilizat implicit pentru noile stocări. Cu versiunea 1.8, utilizarea Berkeley DB a fost depreciată [37] . Noile funcții care vor fi adăugate în versiunile viitoare pot să nu funcționeze pe serverele care utilizează Berkeley DB. Suportul pentru Berkeley DB poate fi întrerupt în viitor.
Subversion oferă următoarele moduri de a accesa un depozit:
Toate aceste metode pot fi folosite pentru a lucra cu ambele tipuri de depozite (FSFS și Berkeley DB). Pot fi folosite diferite metode în același timp pentru a accesa același depozit.
Din perspectiva utilizatorului, depozitul Subversion este un sistem de fișiere „bidimensional” . Obiectele dintr-un depozit ( fișiere și directoare ) sunt identificate prin două „ coordonate ”: un nume și un număr de revizuire . Cu alte cuvinte, depozitul este o serie de instantanee (revizii) ale unui arbore de fișiere și directoare, indexate după numărul de revizuire. Fiecare astfel de instantanee este un sistem de fișiere obișnuit (unidimensional).
Dacă este necesar să se indice o anumită revizuire a unui obiect, se folosește o intrare a formularului: имя@ревизия, de exemplu, /main.c@29 fișierul /main.c din revizuirea 29. O astfel de indicație a revizuirii folosită pentru a clarifica numele se numește peg revizuire .
Pe fig. 1 prezintă o reprezentare grafică a sistemului de fișiere: axa verticală corespunde setului de nume, axa orizontală corespunde setului de revizuiri.
Nume de fișiereNumele unui obiect de sistem de fișiere în Subversion este format în conformitate cu aceleași reguli ca și în sistemele de operare asemănătoare UNIX: există un singur director rădăcină, elementele de cale sunt separate printr -o bară oblică ("/"). Obiectele sistemului de fișiere sunt fișiere și directoare (precum și legături simbolice , care sunt emulate din fișierele obișnuite prin setarea atributului svn:special).
Numerele reviziilorNumărul de revizuire în Subversion este un număr natural (sau 0 pentru prima revizuire) care se adresează numărului de stare al depozitului pe măsură ce datele pe care le conține se modifică. Fiecare comitere reușită generează exact o nouă revizuire a depozitului, astfel încât cea de-a N -a revizuire este starea depozitului după cea de-a N -a comitere.
În Subversion, o revizuire caracterizează starea nu a unui singur fișier, ci a întregului depozit ca un întreg. De exemplu, revizuirea 32 (punctată în figură) este starea a patru fișiere și două directoare care existau în depozit la acel moment.
Numărul de revizuire este analog cu timpul , în sensul că numerele de revizuire mai mici corespund stărilor anterioare ale depozitului, iar numerele de revizuire mai mari corespund celor ulterioare.
Numărul de revizuire poate fi considerat ca un fel de marcaj de timp în istoricul depozitului. Mai mult, fiecare număr de revizuire are o valoare absolută asociată cu momentul în care a fost efectuată revizuirea ( proprietatea svn:date ). Cu toate acestea, specificarea numărului de revizuire este mai convenabilă decât specificarea orei, deoarece nu există confuzii cu fusurile orare, introducerea numărului este mai scurtă și numărul de revizuire nu poate fi schimbat.
Revizuiri operaționale și de bazăNumărul de revizuire este utilizat în două contexte diferite :
O revizuire se numește operațională dacă specifică revizuirea sau intervalul de revizuiri la care urmează să fie aplicată operația , de exemplu:
svn log -r 199:230 http://some.pathÎn acest exemplu, comanda este executată svn logpentru o serie de revizii 199:230, care este gama de revizuiri online .
Cu toate acestea, specificarea numai a numelui fișierului și a revizuirii online poate indica uneori în mod ambiguu către obiectele depozitului. De exemplu, în situația prezentată în fig. 2, există o ambiguitate atunci când rulați următoarea comandă:
svn log -r 29:33 http://some.path/bar.txtComanda specifică o serie de revizuiri online ( 29:33), dar zonele evidențiate cu albastru și verde în figură pot fi considerate în egală măsură istoricul fișierului /bar.txtîn intervalul de revizuire 29:33. În astfel de cazuri, este, de asemenea, necesar să specificați revizuirea pivot pentru a rezolva ambiguitatea. Revizia de bază este numărul de revizuire specificat în plus față de adresa URL a obiectului sistemului de fișiere (folosind URL@ревизияnotația " "). Numele provine de la cuvântul englezesc peg , care poate fi tradus ca „rod” sau „peg”. Revizia pivot marchează lanțul de stări căruia îi aparține perechea specificată URL@ревизияși astfel identifică în mod unic obiectul de depozit la care urmează să fie aplicată comanda. În exemplul de mai jos, prima comandă va tipări povestea evidențiată cu albastru în figură, iar a doua comandă va tipări povestea evidențiată în verde:
svn log -r 29:33 http://some.path/file.txt@32 svn log -r 29:33 http://some.path/bar.txt@34Ultima stare a obiectului de interes ar trebui specificată ca revizuire de bază. Motivul pentru aceasta este că lanțul de stat este urmărit în mod unic „înapoi”, dar nu „înainte”. De exemplu, adresa URL cu versiunea pivot http://some.path/foo.txt@31 aparține la două lanțuri de stări (evidențiate cu verde și, respectiv, gri). Dintre aceste două lanțuri, adresa URL specificată se adresează lanțului gri, adică atunci când treceți „înainte” de la revizuirea de bază, operațiunile de copiere sunt ignorate.
Operații pe sistemul de fișiereUrmătoarele operațiuni pot fi efectuate pe obiectele sistemului de fișiere din depozitul Subversion [42] (vezi Figura 1). Parantezele indică denumirea scurtă a operației în notația comenzii svn status.
O copie de lucru este o copie locală a unei date din depozitul creat de programul client Subversion care conține, pe lângă datele în sine, unele informații de serviciu (directoare ascunse numite .svn). Informațiile de serviciu sunt necesare pentru funcționarea corectă a copiei de lucru; nimic nu poate fi schimbat în datele de serviciu. Cea mai mică unitate de date care poate fi preluată dintr-un depozit ca copie de lucru este un director. Este posibil ca conținutul unui director să nu fie extras complet: de exemplu, fișierele sau subdirectoarele individuale pot fi excluse. Cu toate acestea, nu este posibil să verificați un singur fișier din seif ca copie de lucru.
Orice subdirector al unei copii de lucru Subversion 1.6 și anterioare este, de asemenea, o copie de lucru completă, deoarece fiecare director conține datele sale de întreținere (directoare .svn). Începând cu versiunea 1.7, fiecare copie de lucru are un singur director .svnla rădăcina directorului său.
Copia de lucru este autonomă, în sensul că Subversion nu stochează date referitoare la copia de lucru în afara acesteia. Prin urmare, având o copie de lucru, puteți face mai multe copii prin simpla copiere, fără a cheltui traficul de rețea.
În directoarele de servicii ale copiei de lucru, printre altele, este stocată așa-numita copie curată ( de exemplu , copie netedă ) - fișierele copiei de lucru în formă nemodificată, așa cum au fost extrase din depozit (pentru svn aceasta este o revizuire numită BASE). A avea o copie curată vă permite să vizualizați și să anulați rapid modificările locale fără a accesa depozitul. Cu toate acestea, dimensiunea copiei de lucru de pe disc este de aproximativ două ori mai mare (date + copie curată a datelor) decât dimensiunea datelor în sine. Această abordare se datorează faptului că resursele de disc sunt mai ieftine și mai accesibile decât resursele rețelei de date .
În mod obișnuit, crearea unei copii de lucru este primul și necesar pentru a efectua modificări locale, deoarece numai modificările făcute în copia de lucru pot fi trimise în depozit. Excepție fac operațiunile care pot fi efectuate direct pe seif fără a crea o copie de lucru.
TranzacțiiStocarea în Subversion este organizată sub formă de tranzacții cu proprietăți de atomicitate și izolare din setul de proprietăți ACID . Astfel, sistemul de control al versiunilor garantează în orice moment integritatea, consistența și disponibilitatea depozitului.
Aceste proprietăți nu sunt garantate pentru o copie de lucru Subversion - spre deosebire de un depozit, poate fi într-o stare intermediară sau blocată dacă se blochează sau este întreruptă (adică va trebui restaurată printr-o comandă svn cleanupsau recreată înainte de a continua).
Forme de comandă locale și de la distanțăToate comenzile clientului Subversion pot fi împărțite în următoarele grupuri:
În mod oficial, Subversion nu impune nicio restricție asupra structurii fișierelor a proiectului - poate fi orice în cadrul regulilor de denumire a obiectelor din sistemul de fișiere. Cu toate acestea, există recomandări pentru a facilita lucrul cu ramuri și etichete. În cel mai simplu caz, se recomandă să creați cel puțin trei subdirectoare în directorul rădăcină al depozitului:
/. trunk branches tagsÎntreaga structură de fișiere a proiectului (linia principală de dezvoltare) trebuie să fie conținută în subdirectorul trunk, subdirectorul branchestrebuie să conțină ramurile proiectului șitags etichetele . De exemplu, următoarea structură de director de depozit:
/. trunk branches branch_1 tags tag_1 tag_2
presupune că proiectul ( trunk) are o ramură „ branch_1” și două etichete „ tag_1” și „ tag_2”. Fiecare dintre aceste directoare ( trunk, branch_1, tag_1și tag_2) conține o copie a versiunii corespunzătoare a proiectului.
Dacă există mai multe (sub)proiecte în depozit, atunci este creată următoarea structură de subdirectoare pentru fiecare (sub)proiect:
/. project1 trunk branches tags project2 trunk branches tagsAdică, directorul rădăcină conține directoare de proiect, iar fiecare dintre ele are propriile sale trunk, branches, tags, legate doar de acest proiect. Structurile directoarelor de stocare descrise sunt doar exemple, în practică stocarea poate fi organizată într-un mod care se potrivește cel mai bine unui caz particular dat. [43] [44]
O altă modalitate de a stoca mai multe proiecte este crearea mai multor depozite. Proiectele care nu sunt legate în niciun fel ar trebui să fie localizate în depozite diferite, deoarece operațiunile de copiere, mutare și îmbinare nu pot fi efectuate între depozite. Mai multe depozite pot fi îmbinate într-unul singur, dacă este necesar, cu istoricul revizuirilor păstrat (prin import cu comanda svnadmin loadcu parametrul --parent-dir).
RamuriSubversion folosește un model „fișier” (la fel ca și Perforce [45] ) pentru a implementa ramuri și etichete, adică o ramură este doar un director (puteți face și o ramură dintr-un singur fișier în loc de un director). O nouă ramură este creată de comanda svn copy. O ramură poate fi creată în orice director de depozit, dar este logic să urmați convențiile descrise mai sus despre unde să creați ramuri noi. Pentru mai multe informații despre ramuri, consultați Ramificare și fuzionare .
EticheteCrearea unei etichete se face și prin comanda svn copy, adică din punct de vedere tehnic este același cu crearea unei ramuri. Singura diferență este în metoda de utilizare: se presupune că nimeni nu va schimba datele din etichetă (commiteți modificări la aceasta). De exemplu, în fig. 1 etichetă creată în versiunea 29: directorul /trunkdin versiunea 27 copiat sub numele /tags/R1. Acum, dacă nu modificați datele din director /tags/R1, atunci va rămâne pentru totdeauna o copie exactă a directorului /trunk@27, adică va fi o etichetă .
Conceptul de etichete folosit în Subversion este diferit de conceptul de etichete din alte sisteme de control al versiunilor. De obicei, o etichetă este un nume simbolic care se adresează unui set de fișiere și a stării acestora. În Subversion, o etichetă copiază un set de fișiere și starea acestora. Etichetele de copiere în Subversion au avantajele și dezavantajele lor.
Avantaje:
Defecte:
Una dintre caracteristicile importante ale Subversion este suportul pentru proprietăți, adică perechi de text nume = valoare , care pot fi setate pe obiectele din magazin. Proprietățile sunt utilizate în două contexte diferite: pentru obiectele sistemului de fișiere și pentru revizuiri.
Proprietăți ale obiectelor sistemului de fișiereFiecărui fișier sau director dintr-un seif i se poate atribui un set de proprietăți. Modificările de proprietate sunt stocate în istoric în același mod ca și modificările aduse sistemului de fișiere. Utilizatorii pot seta proprietăți cu orice nume; există, de asemenea, un set predefinit de proprietăți de utilitate care sunt utilizate de programul client Subversion (numele proprietăților de utilitate sunt prefixate cu „svn:”).
Proprietăți fișier svn:executable Face fișierul executabil (pentru copii de lucru sub sistemele de operare ale familiei UNIX ). svn:mime-type Stochează tipul MIME al fișierului. Afectează modul în care funcționează comenzile care arată diferențele dintre fișiere și îmbină modificările (imbinare). svn:keywords Lista de cuvinte cheie ( ing. cuvinte cheie ), care vor fi înlocuite în fișier cu valorile corespunzătoare. Pentru ca înlocuirea să aibă loc, cuvântul cheie trebuie să fie prezent în fișier ca $keyword$. Folosit pentru a actualiza automat valorile dintr-un fișier care se schimbă de la o versiune la alta (de exemplu, numărul de revizuire). svn:eol-style Specifică regula pentru conversia caracterelor de final de linie ( EOL ) într-un fișier text . Folosit în cazurile în care fișierul trebuie să aibă un anumit tip de caracter EOL. De obicei se folosește „nativ” - în acest caz, tipul de caractere de final de linie corespunde cu cel adoptat în sistemul de operare în care este creată copia de lucru. svn:needs-lock Indică faptul că fișierul va fi doar pentru citire când este preluat din stocare. Această proprietate este destinată să fie utilizată împreună cu mecanismul de blocare . Interzicerea scrierii într-un fișier este un memento pentru a obține o blocare asupra fișierului înainte de a-l edita: atunci când o blocare este achiziționată, programul client Subversion face automat fișierul inscriptibil (eliberarea blocării din nou face fișierul nemodificabil). Încuietorile pot fi folosite fără a seta această proprietate. Cu toate acestea, acest lucru nu este recomandat, deoarece există riscul ca un alt utilizator să înceapă editarea fișierului blocat, iar acest lucru va fi descoperit doar când modificările sunt efectuate. svn:special Proprietatea nu este destinată să fie setată sau modificată de către utilizatori. Folosit în prezent pentru a stoca link- uri simbolice în depozit. Când o legătură simbolică este adăugată la un depozit, un fișier este creat în depozit cu svn:special. Când acest fișier este verificat pe un sistem asemănător UNIX , programul client Subversion îl convertește înapoi într-un link. svn:mergeinfo Stochează informații despre căile care au fost îmbinate în acest fișier. Proprietatea a fost introdusă în versiunea 1.5, este folosită pentru urmărirea îmbinării . Este un set de șiruri de caractere sub forma nume_fișier: interval_reviziune . Aici filename este numele complet (cu calea de la rădăcina sistemului de fișiere al depozitului) al fișierului sau directorului din care a fost îmbinat intervalul specificat de revizuiri. Rândurile sunt actualizate automat în timpul operațiunilor de îmbinare; la îmbinările ulterioare, Subversion ia în considerare liniile adăugate anterior, evitând astfel îmbinarea repetată a acelorași modificări. Nu este recomandat să schimbați manual proprietatea - acest lucru poate rupe mecanismul de urmărire a îmbinării.svn:mergeinfo Proprietăți director svn:ignore O listă de modele de nume de fișiere și directoare pe care programul client Subversion le va ignora în acest director. Această proprietate este similară cu un fișier .cvsignoredin CVS . De regulă, proprietatea este configurată în așa fel încât programul client „nu vede” fișierele și directoarele care sunt create automat de diverse programe și nu trebuie versionate (de exemplu, fișiere obiect , fișiere temporare etc.). Această proprietate nu se aplică subdirectoarelor. svn:externals Vă permite să extrageți automat un set de directoare într-o copie de lucru, specificând adresa URL a acestora (puteți chiar și dintr-un alt depozit). svn:mergeinfo La fel ca și pentru fișiere . Proprietăți revizuireAl doilea tip de obiect pentru care există proprietăți sunt revizuirile în sine. În acest caz, numele proprietăților pot fi, de asemenea, orice; unele proprietăți prefixate cu „svn:” au o semnificație specială. Diferența dintre proprietățile revizuirilor și proprietățile obiectelor sistemului de fișiere este că pentru primele, conceptul de istoric al versiunilor nu este aplicabil (deoarece o anumită valoare de proprietate este atribuită unei versiuni). Cu alte cuvinte, proprietățile de revizuire pot fi modificate, dar vechea valoare se pierde. În mod implicit, modificările aduse proprietăților revizuirii sunt dezactivate; pentru a permite administratorului să creeze un script ( eng. hook ) care gestionează evenimentul pre-revprop-change.
svn:date Data și ora la care a fost creată revizuirea. svn:author Numele utilizatorului care a comis modificările incluse în această revizuire. svn:log O descriere a modificărilor comise în această revizuire (textul introdus de utilizator la efectuarea modificărilor).De regulă, proprietățile revizuirii sunt modificate numai de administratorul depozitului pentru a corecta datele incorecte. De exemplu, dacă utilizatorul a uitat să furnizeze o descriere text când a efectuat modificările, atunci administratorul poate crea această descriere prin editarea fișierului svn:log.
O iterație tipică a fluxului de lucru cu Subversion include următorii pași.
Branching -ul este un aspect important al modului în care funcționează sistemele de control al versiunilor, deoarece tehnicile tipice de versiuni [47] (cel puțin în dezvoltarea de software ) implică utilizarea ramurilor. Subversion are capacități de ramificare și îmbinare destul de avansate (cu toate acestea , nu acceptă îmbinarea fișierelor și directoarelor redenumite).
Pe fig. Figura 3 prezintă în mod convențional un exemplu de evoluție a ramurilor din depozit. Culoarea verde arată linia principală de dezvoltare a proiectului ( ing. linie principală, trunchi ), galben - ramuri, albastru - etichete, magenta - o ramură a cărei dezvoltare a fost întreruptă. Săgețile roșii arată modificările de îmbinare.
Crearea ramurilorO nouă ramură (precum și o etichetă ) este creată de comanda svn copy, care creează o copie în depozit cu moștenirea istoricului de revizuire a sursei ( operațiune A+ ). Ar trebui să utilizați întotdeauna forma „la distanță” a comenzii pentru a crea ramuri svn copy, de exemplu:
svn copy http://.../trunk/dir http://.../branches/branch_name -m "Crearea unei ramuri de dir"Copia rezultată va fi o ramură (sau o etichetă, în funcție de modul în care lucrați cu ea). În viitor, modificările efectuate pe o ramură pot fi făcute la sursa din care a fost creată această ramură, astfel de propagare a modificărilor se numește îmbinare .
Operațiunile de copiere în Subversion sunt ieftine ( de exemplu, copie ieftină ), adică necesită o cantitate fixă mică de timp și spațiu pe disc. Stocarea este concepută în așa fel [48] încât în timpul oricărei copieri, datele nu sunt duplicate, ci se creează o legătură către sursă (asemănătoare unei legături rigide ), cu toate acestea, acest mecanism este pur intern - din punctul de vedere al utilizatorului vedere, este crearea unei copii care are loc. Datorită eficienței ridicate a ramificării, ramurile pot fi create ori de câte ori este necesar (cu toate acestea , fuziunea - un plus necesar ramificării - este mai lentă în Subversion decât în alte sisteme moderne de control al versiunilor).
Lucrul cu ramuriÎn general, lucrul pe o ramură nu este diferit de lucrul pe linia principală de dezvoltare ( trunchi ). Comenzile specifice sunt necesare numai pentru activitățile care implică mai mult de o ramură. Aceste comenzi includ (pe lângă comanda create branch svn copy):
De regulă, ciclul complet de lucru cu sucursale include următorii pași:
O îmbinare în Subversion este aplicația la o ramură a unui set de modificări efectuate pe o altă ramură (sau aceeași). Pentru a implementa o îmbinare, trebuie să utilizați o comandă svn merge - aceasta aplică un set de modificări unei copii de lucru; atunci trebuie să comiteți modificările ( svn commit).
Îmbinarea terminologiei este oarecum confuză. Termenul de îmbinare nu este în întregime corect, deoarece nu există o fuziune a ramurilor ca atare . În plus, nu ar trebui să echivalați îmbinarea și comanda : în primul rând, pentru îmbinare, trebuie să efectuați (pe lângă ) soluționarea și comiterea conflictelor, iar în al doilea rând, aplicația nu se limitează la îmbinare. svn mergesvn mergesvn merge
Alte utilizări ale comenzii svn mergeComanda svn mergepoate fi folosită pentru mai mult decât doar îmbinare. De fapt, comanda face modificări ale copiei de lucru egale cu diferența dintre două directoare sau fișiere din depozit , prin urmare svn mergeeste un instrument universal pentru transferul modificărilor. Iată câteva exemple de utilizare a comenzii svn merge:
Comanda este folosită pentru a crea un seif svnadmin create. Această operațiune va crea un magazin gol în directorul specificat.
Mai jos este o comparație a parametrilor sistemelor Subversion și CVS, deoarece Subversion este poziționat tocmai ca o îmbunătățire a CVS. Se face o comparație numai pentru acei parametri în care aceste sisteme diferă. În general, Subversion depășește CVS în toate privințele, cu excepția etichetelor în sensul convențional (adică, etichete care se adresează obiectelor sistemului de fișiere).
| Parametru | subversiune | CVS |
|---|---|---|
| Capabilități | ||
| Cataloagele | Urmărește versiunile nu numai ale fișierelor, ci și ale directoarelor. | Versiunile de director nu sunt urmărite, adică structura directorului este aceeași (cea care există în depozit în acest moment) pentru toate revizuirile și toate ramurile. Dacă modificați structura directorului, atunci când extrageți stările vechi, obținem revizuirile corecte (vechi) ale fișierelor, dar în structura de director greșită (existentă la momentul extracției). |
| Tranzacții | Atomicitatea comiterilor cu mai multe fișiere. | Atomicitatea este doar la nivelul comiterilor cu un singur fișier. De fapt, efectuarea modificărilor în mai multe fișiere este împărțită într-o secvență de comiteri către fișiere individuale. Dacă o astfel de secvență de comitere este întreruptă, atunci unele dintre fișiere rămân comise, în timp ce altele rămân necomitate. |
| Seturi de modificări | Seturile de modificări sunt acceptate . | Seturile de modificări nu sunt acceptate. |
| Modificări ale numelui fișierului | Acceptă copierea, mutarea și redenumirea fișierelor și directoarelor fără a pierde istoricul modificărilor. | La copierea, mutarea și redenumirea fișierelor, fișierul cu noul nume nu are istoric, adică conexiunea cu vechiul nume și istoricul versiunilor acestuia se pierde complet. Același lucru pentru fișierele din interiorul unui director la modificarea numelui acestuia [49] . |
| proprietăți | Fiecare fișier și director poate avea asociat un set arbitrar de proprietăți, constând dintr-un nume și o valoare. Proprietățile sunt, de asemenea, sub controlul versiunilor. | Proprietățile nu sunt acceptate. |
| Încuietori | Blocarea opțională a fișierelor este acceptată (din versiunea 1.2). | Blocările nu sunt acceptate, dar există un mecanism similar numit urmărire . |
| ramuri | Ramurile ( ramură , vezi Glosar ) sunt implementate în spațiul de cale. Aceasta înseamnă că pentru a crea o ramură, directorul este copiat (copia va fi ramura). Crearea unor astfel de copii este o operațiune rapidă și nu necesită multă resurse, deoarece datele nu sunt duplicate , în schimb este remediată o nouă versiune, care diferă de cea anterioară doar în locația fișierelor. | Ramurile sunt implementate în „a treia dimensiune”. Aceasta înseamnă că un fișier dintr-o ramură este adresat cu trei parametri: cale în sistemul de fișiere, revizuire (sau un alt mod de a indica revizuirea, cum ar fi ora), numele ramurului . |
| Etichete | Nu există etichete ( etichetă , vezi dicționar ) ca atare. În schimb, se folosește o ierarhie de directoare - este creat un director separat pentru etichetă (precum și pentru ramură). O etichetă este o ramură la care, prin convenție, nu se mai fac modificări. O etichetă este o copie a stării etichetate a fișierelor și directoarelor. | Etichetele sunt acceptate. Eticheta se adresează stării etichetate a fișierelor. |
| Eficienţă | ||
| Schimb client-server | Orice actualizări de versiune între client și server transferă doar diferențele de fișiere, ceea ce poate reduce semnificativ traficul de rețea. | Diferențele sunt transferate de la server la client, iar întregul obiect este transferat de la client la server. |
| Binare | Funcționează la fel de eficient atât cu fișiere text , cât și cu fișiere binare . | Lucrul cu fișiere binare este mai puțin eficient: fiecare versiune nouă este stocată în depozit în întregime. |
| Crearea de ramuri și etichete | Necesită o cantitate fixă mică de timp și spațiu pe disc. | Costurile de timp sunt mari (în funcție de numărul de fișiere implicate). Numele de ramuri și etichete sunt stocate redundant (în toate fișierele implicate). |
| Suprafața în copie de lucru | Directoarele de servicii ale copiei de lucru stochează o copie curată. Prin urmare, navigarea și derularea înapoi a modificărilor locale sunt rapide (fără a merge la stocare), dar dimensiunea copiei de lucru de pe disc este de aproximativ două ori mai mare decât dimensiunea datelor în sine. | O copie curată nu este stocată, dimensiunea copiei de lucru este aproximativ egală cu dimensiunea datelor. Ca rezultat, operațiunile de vizualizare și de retragere pentru modificările locale necesită acces la depozit și sunt lente. |
| Consumul de memorie pe server | Mai puțin [50] . | Mai Mult. |
Există un program cvs2svn conceput pentru a converti un depozit CVS într-un depozit Subversion gata făcut (sau un depozit git ) sau într-un depozit de text, care poate fi apoi importat în depozit folosind svnadmin. În același timp, cvs2svn salvează toate informațiile conținute în depozitul CVS: ramuri, etichete, descrieri ale modificărilor, nume de autori, date de comitere. În plus, modificările în diferite fișiere comise împreună sunt convertite într-o singură revizuire.
Diferențele de utilizare Diferențele de gestionare a fișierelorÎn CVS, mutarea (redenumirea) și copierea fișierelor și directoarelor se realizează prin adăugarea din nou a unui obiect cu un nume nou și (la mutarea și redenumirea) ștergerea obiectului vechi. Cu această muncă, fișierele și directoarele din depozit sunt create din nou și își pierd istoricul modificărilor. Subversion trebuie să folosească comenzile mutare ( movesau mv) și copiere ( copy) pentru a efectua aceste operațiuni. Utilizarea lor păstrează istoricul modificărilor și vă permite să evitați operațiunile inutile (mai ales atunci când aveți de-a face cu directoare sau chiar ramuri ale sistemului de fișiere).
Spre deosebire de CVS, unele operațiuni de copiere (cum ar fi ștergerea și mutarea unui fișier) sunt gestionate chiar de Subversion. Diferențele descrise și alte diferențe atunci când lucrați cu fișiere de copiere de lucru sunt rezumate în următorul tabel (operația commit, unde este necesară în ambele cazuri, este omisă):
| Operațiune | CVS | subversiune | Note |
|---|---|---|---|
| Ștergerea unui fișier | fișier rm cvs fișier rm |
svn rm file | fișierul nu trebuie să fie șters manual mai întâi |
| Ștergerea fișierelor prin mască | rm * cvs rm fisier1 fisier2 ... |
svn rm * | fișierele nu trebuie să fie șterse manual în prealabil, nu este nevoie să enumerați toate fișierele |
| Redenumiți/Mutați | mv fisier1 fisier2 cvs rm fisier1 cvs adauga fisier2 |
svn mv file1 file2 | fișierul nu trebuie mutat manual , istoricul fișierului este păstrat |
| copierea | cp fisier1 fisier2 cvs adauga fisier2 |
svn copy file1 file2 | fișierul nu trebuie copiat manual , istoricul fișierului este păstrat (furcat) |
| Adăugarea (crearea) unui director | mkdir dir cvs add dir |
svn mkdir dir svn commit |
directorul nu poate fi creat manual după ce este necesară adăugarea directoruluicommit |
| Adăugarea unui director cu fișiere | cvs add dir cd dir cvs adauga fisier1 fisier2 |
svn add dir | directorul este adăugat cu fișierele pe care le conține |
| Redenumirea unui director cu fișiere (fără subdirectoare) |
mkdir dir2 cvs add dir2 mv dir1/* dir2 cvs rm dir1/file1 dir1/file2 ... cvs add dir2/* |
svn mv dir1 dir2 | nu este nevoie să creați și să adăugați directoare nu este nevoie să mutați manual fișierele nu este nevoie să enumerați toate fișierele. Istoricul fișierelor este salvat |
| Redenumirea unei ramuri a sistemului de fișiere (directoare cu fișiere și subdirectoare) |
repetați comenzile de mai sus pentru fiecare nivel de imbricare sau pentru fiecare subdirector [51] |
svn mv dir1 dir2 | vezi mai sus nu depinde de numărul de niveluri și directoare |
În Subversion, nu este necesar să creați etichete sau să folosiți o dată/oră pentru a aborda starea depozitului, în cazuri simple (de exemplu, pentru a obține o versiune după o anumită comitere), va fi mai ușor să specificați numărul de revizuire necesar .
Subversion este conceput ca un set de biblioteci împărțite pe mai multe niveluri. Fiecare dintre ele îndeplinește o sarcină specifică și permite dezvoltatorilor să-și creeze propriile instrumente, în funcție de complexitate și sarcină.
fs Cel mai de jos nivel; implementează un sistem de fișiere versionat care stochează date. Repos Nivelul de stocare implementat pe sistemul de fișiere. La acest nivel sunt implementate multe funcții auxiliare și, de asemenea, acceptă lansarea de handlere ( English hooks ), adică scripturi care sunt lansate atunci când are loc un eveniment. Împreună, nivelurile Fs și Repos alcătuiesc interfața sistemului de fișiere . mod_dav_svn Oferă acces WebDAV / Delta-V prin Apache 2. Ra Implementează accesul la stocare (atât local, cât și la distanță). Începând de la acest nivel, depozitul poate fi referit prin URL, adică.Utilitarul client standard al Subversion, SVN, este configurat de variabilele de mediu și fișierele INI create în directorul principal al utilizatorului într-un subdirector .subversion(locația configurației pe sistemele Windows, în fișiere sau registry, depinde de setările sistemului). În configurație, SVN memorează și certificate SSL, autentificări, parole etc. (cu excepția cazului în care este dezactivat în configurare) pentru accesarea serverelor Subversion.
Conținutul directorului .subversion:
Este posibil ca Subversion să nu gestioneze întotdeauna corect redenumirea fișierelor dacă conținutul fișierului este modificat în același timp cu redenumirea. Probleme pot apărea și dacă un fișier redenumit în copia locală este modificat de altcineva din depozit. Unele dintre aceste probleme sunt rezolvate în versiunea 1.5, dar această soluție nu este încă completă. [53]
Operațiunile de fuziune a ramurilor sunt, de asemenea, considerate un punct slab al Subversion. Înainte de versiunea 1.5, toate astfel de operațiuni trebuiau urmărite manual de către utilizatori folosind intrări detaliate din jurnalul de modificări. Începând cu versiunea 1.5, a fost introdus suport de bază pentru urmărirea automată a îmbinării, pe care dezvoltatorii plănuiesc să îl îmbunătățească în edițiile ulterioare [54] . Subversion suportă în prezent scenariile comune de îmbinare destul de bine; în cazuri mai complexe, problemele sunt posibile. Se recomandă [55] organizarea fluxului de lucru în așa fel încât să se evite scenariile problematice. Îmbinarea fișierelor și directoarelor redenumite nu este acceptată.
Informațiile odată plasate în depozitul Subversion rămân acolo pentru totdeauna: un fișier poate fi șters la revizuirea curentă, dar este întotdeauna posibil să preluați din depozit una dintre versiunile anterioare în care a existat fișierul. Deși păstrarea revizuirilor anterioare este de fapt scopul utilizării sistemelor de control al versiunilor, uneori este necesar să eliminați complet informațiile dintr-un depozit care a fost plasat în mod greșit acolo. Subversion nu oferă nicio modalitate nativă de a face acest lucru [56] ; singura posibilitate este să creați un dump de stocare, să îl procesați cu utilitarul standard svndumpfilter și apoi să restaurați stocarea din dump. Există și programe de la terți pentru automatizarea acestui proces, dar în orice caz, această operațiune necesită o suspendare temporară a accesului la stocare și intervenția unui administrator cu privilegii suficient de mari pentru a șterge complet vechiul stocare și a o înlocui cu una nouă. unu.
|
Nume |
Descriere |
Limba |
DB |
Licență |
Site-ul web |
Actualizați |
Versiune |
|
un instrument bazat pe tehnologia Wiki |
Piton |
SQLite, PostgreSQL, MySQL și MariaDB |
trac.edgewall.org Arhivat 8 aprilie 2013 la Wayback Machine |
21.06.2017 |
1.2.2 | ||
|
urmărire suplimentară a erorilor |
rubin |
MySQL, PostgreSQL, SQLite, Oracle. |
redmine.org Arhivat pe 27 aprilie 2011 la Wayback Machine |
09.12.2018 |
4.0.0 | ||
|
utilitate pentru crearea și gestionarea accesului la depozite, specializată pentru SVN |
PHP |
MySQL, SQLite |
CeCill (licență compatibilă GPL). |
www.usvn.info Arhivat pe 12 mai 2011 la Wayback Machine |
13.01.2012 |
1.0.6 | |
|
ViewVC |
fără management al utilizatorilor, nu necesită suport DAV de către serverul web. |
Piton |
MySQL |
Două clauze în stil Berkeley |
www.viewvc.org Arhivat 4 mai 2011 la Wayback Machine |
02.12.2010 |
1.1.8 |
|
WebSVN |
interfață de navigare către SVN |
PHP |
XML |
websvn.tigris.org Arhivat pe 12 iunie 2006 la Wayback Machine |
10.12.2010 |
2.3.2 | |
|
utilitate pentru gestionarea depozitelor (crearea, ștergerea, încărcarea și descărcarea; gestionarea utilizatorilor și a grupurilor) |
PHP |
MySQL sau SQLite |
svnmanager.sourceforge.net Arhivat 30 aprilie 2011 la Wayback Machine |
28.01.2012 |
1.09 | ||
|
Submin (MIT) |
utilitar pentru gestionarea depozitelor și utilizatorilor, inclusiv gestionarea controlului accesului pentru directoare individuale dintr-un depozit |
Piton |
MIT/X Arhivat pe 6 iunie 2011 la Wayback Machine |
24.12.2012 |
2.1 | ||
|
cSvn |
interfață web pentru vizualizarea depozitelor Subversion |
C |
csvn.radix.pro Arhivat 16 martie 2022 la Wayback Machine |
17.11.2020 |
0.1.3 |
| Sisteme de control al versiunilor ( categorie ) | |
|---|---|
| Doar local | |
| Client server | |
| Distribuit | |
| scheme URI | |
|---|---|
| Oficial | |
| neoficial | |