Prezentare generală a sistemelor de control al versiunilor

Sistemele de control al versiunilor au devenit o parte integrantă a vieții nu numai a dezvoltatorilor software, dar și toate persoanele care se confruntă cu problema gestionării informațiilor în schimbare intensă și doresc să-și facă viața mai ușoară. Drept urmare, a apărut număr mare oferta de produse variate oportunități ampleși furnizarea de instrumente extinse de control al versiunilor. Acest articol va discuta pe scurt pe cele mai populare dintre ele, enumerându-le avantajele și dezavantajele.

Pentru comparație, au fost alese cele mai comune sisteme de control al versiunilor: RCS, CVS, Subversion, Aegis, Monoton, Git, Bazaar, Arch, Perforce, Mercurial, TFS.

RCS este un sistem de management al revizuirii versiunilor.
(www.gnu.org/software/rcs/rcs.html)

Să începem recenzia noastră cu unul dintre primele sisteme de control al versiunii - RCS (Revision Control System), dezvoltat în 1985. Acesta a înlocuit sistemul de control al versiunilor SCCS (Source Code Control System), care era popular la acea vreme.

Pe acest moment RCS este înlocuit activ de sistemul mai puternic de control al versiunilor CVS, dar este încă destul de popular și face parte din proiectul GNU.

RCS vă permite să lucrați numai cu fișiere individuale, creând un istoric al modificărilor pentru fiecare. Pentru fișierele text, nu toate versiunile fișierului sunt salvate, ci doar cea mai recentă versiune și toate modificările aduse acestuia. RCS poate urmări, de asemenea, modificările aduse fișierelor binare, dar fiecare modificare este stocată ca o versiune separată a fișierului.

Când un utilizator face modificări la un fișier, fișierul rămâne blocat pentru toți ceilalți. Nu îl pot solicita din depozit pentru editare până când primul utilizator nu termină și comite modificările.

Să ne uităm la principalele avantaje și dezavantaje ale sistemului de control al versiunilor RCS.

Avantaje:

1. RCS - ușor de utilizat și bine potrivit pentru familiarizarea cu principiile de funcționare a sistemelor de control al versiunilor.

2. Bun pentru Rezervă copie fișiere separate, care nu necesită modificări frecvente de către un grup de utilizatori.

3. Distribuit pe scară largă și preinstalat în majoritatea sistemelor de operare gratuite.

Defecte:

1. Urmărește modificările numai la fișierele individuale, ceea ce nu permite utilizarea acestuia pentru controlul versiunilor proiecte mari.

2. Nu permite mai multor utilizatori să facă modificări la același fișier în același timp.

3. Funcționalitate scăzută în comparație cu sistemele moderne de control al versiunilor.

Concluzii:

Sistemul de control al versiunilor RCS oferă un set prea slab de instrumente pentru gestionarea proiectelor dezvoltate și este potrivit doar pentru familiarizarea cu tehnologia de control al versiunilor sau pentru menținerea unui istoric mic de rollback-uri ale fișierelor individuale.

CVS este un sistem de control al versiunilor paralele.
(www.nongnu.org/cvs)

Sistemul de versiuni simultane este o dezvoltare logică a sistemului de control al reviziilor (RCS), folosind standardele și algoritmii de control al versiunilor, dar este mult mai funcțional și vă permite să lucrați nu numai cu fișiere individuale, ci și cu proiecte întregi.

CVS se bazează pe tehnologia client-server care interacționează într-o rețea. Clientul și serverul pot fi, de asemenea, localizate pe aceeași mașină dacă o singură persoană lucrează la proiect sau este necesar controlul versiunii locale.

CVS funcționează după cum urmează. Cea mai recentă versiune și toate modificările efectuate sunt stocate în depozitul serverului. Clienții care se conectează la server verifică diferențele versiune locală din cea mai recentă versiune salvată în depozit și, dacă există diferențe, încărcați-le în proiectul dvs. local. Dacă este necesar, rezolvați conflictele și faceți modificările necesare produsului în curs de dezvoltare. După aceasta, toate modificările sunt încărcate în depozitul serverului. CVS, dacă este necesar, vă permite să reveniți la versiunea dorită a proiectului în curs de dezvoltare și să gestionați mai multe proiecte simultan.

Iată principalele avantaje și dezavantaje ale sistemului de control al versiunilor paralele.

Avantaje:

1. Mai mulți clienți pot lucra la același proiect în același timp.

2. Vă permite să gestionați nu doar un fișier, ci proiecte întregi.

3. Posedă o sumă imensă interfețe grafice convenabile care pot satisface aproape orice, chiar și cel mai pretențios gust.

4. Folosit pe scară largă și vine implicit cu majoritatea sistemelor de operare Linux.

5. Când descărcați fișiere de testare din depozit, sunt transferate numai modificările, și nu întregul fișier.

Defecte:

1. Când mutați sau redenumiți un fișier sau director, toate modificările asociate cu acest fișier sau director se pierd.

2. Dificultăți în menținerea mai multor ramuri paralele ale aceluiași proiect.

3. Suport limitat pentru fonturi.

4. Pentru fiecare modificare a unui fișier binar, se salvează întreaga versiune a fișierului, nu doar modificarea făcută.

5. Fișierul modificat este întotdeauna transferat complet de la client la server.

6. Operațiuni care necesită resurse intensive, deoarece necesită acces frecvent la depozit, iar copiile salvate au o oarecare redundanță.

Concluzii:

Deși CVS este depășit și are deficiențe serioase, este încă unul dintre cele mai populare sisteme de control al versiunilor și este excelent pentru gestionarea proiectelor mici care nu necesită crearea mai multor versiuni paralele, care trebuie combinate periodic. CVS poate fi recomandat ca pas intermediar în stăpânirea funcționării sistemelor de control al versiunilor, conducând la tipuri mai puternice și mai moderne de astfel de programe.

Sistem de control al versiunilor Subversion.
(www.subversion.tigris.org)

Subversion este un sistem centralizat de control al versiunilor creat în 2000 și bazat pe tehnologia client-server. Are toate avantajele CVS și își rezolvă principalele probleme (redenumirea și mutarea fișierelor și directoarelor, lucrul cu fișiere binare etc.). Este adesea numită după numele părții client - SVN.

Principiul lucrului cu Subversion este foarte asemănător cu lucrul cu CVS. Clienții copiază modificările din depozit și le îmbină în proiectul local al utilizatorului. Dacă apar conflicte schimbări localeși modificările salvate în depozit, atunci astfel de situații sunt rezolvate manual. Se fac apoi modificări în proiectul local, iar rezultatul este salvat în depozit.

Când lucrați cu fișiere care nu permit îmbinarea modificărilor, se poate folosi următorul principiu:

1. Fișierul este descărcat din depozit și blocat (descărcarea lui din depozit este interzisă).

2. Se fac modificările necesare.

3. Fișierul este încărcat în depozit și deblocat (alți clienți au voie să îl descarce din depozit).

În mare parte datorită simplității și asemănării sale în management cu CVS, dar mai ales datorită funcționalității sale largi, Subversion concurează cu succes cu CVS și chiar îl înlocuiește cu succes.

Cu toate acestea, Subversion are și dezavantajele sale. Să ne uităm la punctele sale slabe și punctele forte pentru comparare cu alte sisteme de control al versiunilor.

Avantaje:

1. Sistem de comandă similar cu CVS.

2. Cele mai multe caracteristici CVS sunt acceptate.

3. Diverse interfeţe grafice şi lucru convenabil din consolă.

4. Istoricul modificărilor aduse fișierelor și directoarelor este urmărit chiar și după ce acestea sunt redenumite și mutate.

5. Eficiență ridicată a muncii, atât cu text, cât și cu fișiere binare.

6. Suport încorporat în multe instrumente de dezvoltare integrate, cum ar fi KDevelop, Zend Studio și multe altele.

7. Posibilitatea de a crea copii în oglindă ale depozitului.

8. Două tipuri de depozit - o bază de date sau un set de fișiere obișnuite.

9. Posibilitatea de a accesa depozitul prin Apache folosind protocolul WebDAV.

10. Disponibilitatea unui mecanism convenabil pentru crearea de etichete și ramuri de proiect.

11. Puteți asocia un set specific de proprietăți fiecărui fișier și director, facilitând interacțiunea cu sistemul de control al versiunilor.

12. Distribuția pe scară largă face posibilă rezolvarea rapidă a majorității problemelor care apar prin apelarea la datele acumulate de comunitatea internetului.

Defecte:

1. O copie completă a depozitului este stocată pe computerul local în fișiere ascunse, care necesită o cantitate destul de mare de memorie.

2. Există probleme cu redenumirea fișierelor dacă un fișier redenumit local de un client a fost în același timp modificat de un alt client și încărcat în depozit.

3. Sprijin sprijin pentru fuziunea ramurilor de proiect.

4. Dificultăți la ștergerea completă a informațiilor despre fișierele din depozit, deoarece conține întotdeauna informații despre modificările anterioare ale fișierului și nu există mijloace standard pentru ștergerea completă a datelor despre un fișier din depozit.

Concluzii:

Subversion este un sistem modern de control al versiunilor care are o gamă largă de instrumente pentru a răspunde oricărei necesități de a gestiona versiunile de proiect folosind un sistem de control centralizat. Există multe resurse pe Internet dedicate funcțiilor Subversion, ceea ce vă permite să rezolvați rapid și eficient toate problemele care apar în timpul muncii dvs.

Ușurința de instalare, pregătirea pentru lucru și capabilitățile ample permit subversiei să ocupe una dintre pozițiile de lider în cursa competitivă a sistemelor de control al versiunilor.

Sistem de control al versiunilor Aegis.

Aegis, creat de Peter Miller în 1991, este prima alternativă la sistemele centralizate de control al versiunilor. Toate operațiunile din acesta sunt efectuate prin sistemul de fișiere Unix. Din păcate, Aegis nu are suport de rețea încorporat, dar interacțiunile pot fi efectuate folosind protocoale precum NFS, HTTP, FTP.

Caracteristica principală a Aegis este modul în care controlează modificările aduse depozitului.

În primul rând, înainte de a face modificări, trebuie să treacă o serie de teste. Și dacă inovațiile în codul sursă al programului nu trec teste, atunci este necesar fie să adăugați noi teste, fie să corectați posibile greșeliîn codul sursă.

În al doilea rând, înainte de a fi aduse modificări la ramura principală a proiectului în curs de dezvoltare, acestea trebuie să fie aprobate de un evaluator.

În al treilea rând, este furnizată o ierarhie de acces la depozit, bazată pe sistemul de drepturi de acces la fișiere ale sistemelor de operare asemănătoare Unix.

Toate acestea fac ca utilizarea sistemului de control al versiunilor Aegis să fie fiabilă, dar extrem de dificilă, iar chiar și o documentare bună nu o face mult mai ușoară.

Să evidențiem principalele avantaje și dezavantaje ale sistemului de control al versiunilor Aegis.

Avantaje:

1. Control fiabil al corectitudinii modificărilor încărcate.

2. Capacitatea de a oferi diferite niveluri de acces la fișierele de depozit, ceea ce oferă un nivel decent de securitate.

3. Documentație de înaltă calitate.

4. Posibilitatea de a redenumi fișierele salvate în depozit fără a pierde istoricul modificărilor.

5. Abilitatea de a lucra cu un depozit local dacă nu există acces la rețea la depozitul principal.

Defecte:

1. Lipsa suportului încorporat pentru interacțiunea în rețea.

2. Dificultate la configurarea și lucrul cu depozitul.

3. Interfețe grafice slabe.

Concluzii:

Complexitatea Aegis poate descuraja utilizatorii să folosească sisteme de control al versiunilor, așa că nu este recomandat pentru referință sau pentru proiecte software mici. Cu toate acestea, are o serie de avantaje care pot fi utile în unele situații specifice, mai ales atunci când este necesar un control strict asupra calității software-ului dezvoltat.

Sistem de control al versiunii monoton.
(monotone.ca)

Monotone este un alt sistem de control al versiunilor descentralizat dezvoltat de Graydon Hoem. În acesta, fiecare client este responsabil pentru sincronizarea versiunilor produsului dezvoltat cu alți clienți.

Lucrul cu acest sistem de control al versiunilor este destul de simplu, iar multe dintre comenzi sunt similare cu comenzile utilizate în Subversion și CVS. Diferențele constă în principal în organizarea fuziunii ramurilor de proiecte de la diferiți dezvoltatori.

Lucrul cu Monotone este structurat după cum urmează. În primul rând, este creată o bază de date de proiect SQLite și cheile sunt generate folosind algoritmul de hashing SHA1 (Secure Hash Algorithm 1).

Apoi, pe măsură ce utilizatorul editează proiectul, toate modificările sunt salvate în această bază de date, similar cu salvarea modificărilor în depozitul altor sisteme de control al versiunilor.

Pentru a sincroniza un proiect cu alți utilizatori, trebuie să:

Exportați cheia (codul hash al celei mai recente versiuni a proiectului) și primiți chei similare de la alți clienți.

Acum toți cei înregistrați în acest mod pot sincroniza dezvoltarea cu colegii lor folosind un set simplu de comenzi.

Să rezumăm avantajele și dezavantajele sistemului de control al versiunii Monotone.

Avantaje:

1. Un set simplu și clar de comenzi, similar comenzilor Subversion și CVS.

2. Acceptă redenumirea și mutarea fișierelor și directoarelor.

3. Documentație de înaltă calitate, care facilitează foarte mult utilizarea sistemului de control al versiunilor.

Defecte:

1. Viteză mică.

2. Lipsa shell-urilor grafice puternice.

3. Potriviri posibile (dar extrem de scăzute) ale codului hash al revizuirilor care diferă ca conținut.

Concluzii:

Monotone este un puternic și instrument la îndemână pentru a gestiona versiunile proiectului în curs de dezvoltare. Setul de comenzi este bine gândit și intuitiv, mai ales convenabil pentru utilizatorii obișnuiți să lucreze cu Subversion și CVS. Documentația bine concepută și completă vă va permite să vă obișnuiți rapid și să utilizați toate funcțiile Subversion la potențialul lor maxim.

Cu toate acestea, relativ viteza mica munca și lipsa de shell-uri grafice puternice pot face oarecum dificilă lucrul cu proiecte mari. Prin urmare, dacă aveți nevoie de un sistem de control al versiunilor pentru a suporta produse complexe și mari, ar trebui să vă uitați la Git sau Mercurial.

Sistemul de control al versiunilor Git.
(www.git-scm.com)

Din februarie 2002 pentru dezvoltare Kernel-urile Linux„și majoritatea programatorilor au început să folosească sistemul de control al versiunilor BitKeeper. Pentru o lungă perioadă de timp nu au fost probleme cu acesta, dar în 2005 Larry McVoy (dezvoltatorul BitKeeper) a retras versiunea gratuită a programului.

Este imposibil să dezvoltați un proiect la scară Linux fără un sistem de control al versiunilor puternic și fiabil. Unul dintre candidați și cel mai potrivit proiect a fost sistemul de control al versiunii Monotine, dar Torvalds Linus nu a fost mulțumit de viteza acestuia. Deoarece particularitățile organizației Monatone nu au permis o creștere semnificativă a vitezei de procesare a datelor, pe 3 aprilie 2005, Linus a început să-și dezvolte propriul sistem de control al versiunilor - Git.

Aproape simultan cu Linus (trei zile mai târziu), până la dezvoltare sistem nou Matt Makal a început și controlul versiunilor. Matt și-a numit proiectul Mercurial, dar mai multe despre asta mai târziu, dar acum să revenim la sistemul distribuit de control al versiunilor Git.

Git este un sistem de control al versiunilor flexibil, distribuit (fără un singur server), care oferă o mulțime de oportunități nu numai dezvoltatorilor de software, ci și scriitorilor pentru modificarea, adăugarea și urmărirea modificărilor „manuscriselor” și poveștilor, iar profesorilor să le ajusteze. și să dezvolte un curs de prelegeri și administratori pentru documentare și pentru multe alte domenii care necesită gestionarea istoriei schimbărilor.

Fiecare dezvoltator care folosește Git are propriul său depozit local, permițând controlul versiunii locale. Apoi, datele salvate în depozitul local pot fi schimbate cu alți utilizatori.

Adesea, atunci când lucrați cu Git, creați un depozit central cu care se sincronizează alți dezvoltatori. Un exemplu de organizare a unui sistem cu un depozit central este proiectul de dezvoltare a nucleului Linux (http://www.kernel.org).

În acest caz, toți participanții la proiect își desfășoară dezvoltarea locală și descarcă gratuit actualizări din depozitul central. Când munca necesara finalizate și depanate de participanții la proiect individual, aceștia, după ce proprietarul depozitului central a certificat că munca efectuată este corectă și actualizată, își încarcă modificările în depozitul central.

Având depozite locale, de asemenea, crește semnificativ fiabilitatea stocării datelor, deoarece dacă unul dintre depozite eșuează, datele pot fi recuperate cu ușurință din alte depozite.

Lucrarea la versiunile unui proiect în Git poate fi efectuată în mai multe ramuri, care pot fi apoi îmbinate, distruse, derulate înapoi și extinse în tot mai multe ramuri noi ale proiectului.

Putem discuta despre capabilitățile Git pentru o lungă perioadă de timp, dar pentru concizie și înțelegere mai ușoară, vom prezenta principalele avantaje și dezavantaje ale acestui sistem de control al versiunilor

Avantaje:

1. Un sistem de încredere pentru compararea revizuirilor și verificarea corectitudinii datelor, bazat pe algoritmul de hashing SHA1 (Secure Hash Algorithm 1).

2. Sistem flexibil pentru ramificarea proiectelor și fuzionarea ramurilor între ele.

3. Disponibilitatea unui depozit local care conține informatii complete despre toate modificările, vă permite să mențineți controlul complet asupra versiunilor locale și să încărcați numai modificări complet verificate în depozitul principal.

4. Productivitate și viteză ridicate.

5. Set de comenzi convenabil și intuitiv.

6. Multe shell-uri grafice care vă permit să lucrați rapid și eficient cu Git.

7. Posibilitatea de a face puncte de control în care datele sunt salvate fără compresie delta, dar complet. Acest lucru vă permite să reduceți viteza de recuperare a datelor, deoarece cel mai apropiat punct de control este luat ca bază și recuperarea continuă din acesta. Dacă punctele de control ar lipsi, recuperarea proiectelor mari ar putea dura ore întregi.

8. Distribuție largă, accesibilitate ușoară și documentație de înaltă calitate.

9. Flexibilitatea sistemului vă permite să îl configurați convenabil și chiar să creați controale de sistem specializate sau interfețe de utilizator bazate pe git.

10. Acces universal la rețea folosind protocoale http, ftp, rsync, ssh etc.

Defecte:

1. Unix - orientare. În prezent, nu există o implementare Git matură care să fie compatibilă cu alte sisteme de operare.

2. Potriviri posibile (dar extrem de scăzute) ale codului hash al revizuirilor care diferă ca conținut.

3. Modificările la fișierele individuale nu sunt urmărite, ci doar la întregul proiect, ceea ce poate fi incomod atunci când lucrați cu proiecte mari care conțin multe fișiere deconectate.

4. Când creați inițial un depozit și îl sincronizați cu alți dezvoltatori, veți avea nevoie de suficient perioadă lungă de timp pentru descărcarea datelor, mai ales dacă proiectul este mare, deoarece trebuie să copiați întregul depozit pe computerul local.

Concluzii:

Git este un sistem de control al versiunilor flexibil, convenabil și puternic, care poate satisface marea majoritate a utilizatorilor. Deficiențele existente sunt eliminate treptat și nu cauzează probleme serioase utilizatorilor. Dacă derulați un proiect mare, la distanță geografică și cu atât mai mult, dacă deseori trebuie să dezvoltați software fără acces la alți dezvoltatori (de exemplu, nu doriți să pierdeți timpul când zburați dintr-o țară în alta sau când faceți naveta către funcționează), puteți face orice modificări și le puteți salva în depozitul local, puteți să reveniți, să comutați între ramuri etc.). Git este unul dintre liderii sistemelor de control al versiunilor.

Sistem de control al versiunii Mercurial.
(mercurial.selenic.com)

Sistemul de control al versiunilor distribuite Mercurial a fost dezvoltat de Matt Macal în paralel cu sistemul de control al versiunilor Git creat de Torvalds Linus.

Inițial, a fost creat pentru gestionarea eficientă a proiectelor mari sub Linux și, prin urmare, sa concentrat pe lucrul rapid și fiabil cu depozite mari. În prezent, mercurial este adaptat să funcționeze sub Windows, Mac OS X și majoritatea sistemelor Unix.

Majoritatea sistemului de control al versiunilor este scris în Python și numai zone separate programele care necesită cea mai mare viteză sunt scrise în C.

Verificările sunt identificate pe baza algoritmului de hashing SHA1 (Secure Hash Algorithm 1); cu toate acestea, este posibil să se atribuie numere individuale revizuirilor.

La fel ca în git, acceptă capacitatea de a crea ramuri de proiect și apoi de a le îmbina.

Folosit pentru interacțiunea dintre clienți Protocoale HTTP, HTTPS sau SSH.

Setul de comenzi este simplu și intuitiv, la fel ca și comenzile subversiune. Există, de asemenea, o serie de shell-uri grafice și acces la depozit printr-o interfață web. De asemenea, este important să aveți utilități care vă permit să importați depozite ale multor alte sisteme de control al versiunilor.

Să ne uităm la principalele avantaje și dezavantaje ale lui Mercurial.

Avantaje:

1. Prelucrare rapidă a datelor.

2. Suport multiplatform.

3. Abilitatea de a lucra cu mai multe ramuri ale proiectului.

4. Ușor de utilizat.

5. Abilitatea de a converti depozite ale altor sisteme de suport pentru versiuni, cum ar fi CVS, Subversion, Git, Darcs, GNU Arch, Bazaar etc.

Defecte:

1. Potriviri posibile (dar extrem de scăzute) ale codului hash al revizuirilor care diferă ca conținut.

2. Concentrat pe lucrul în consolă.

Concluzii:

O interfață simplă și șlefuită, un set de comenzi și capacitatea de a importa depozite din alte sisteme de control al versiunilor vor face tranziția la Mercurial și vor învăța funcțiile principale fără durere și rapidă. Este puțin probabil să dureze mai mult de câteva zile.

Fiabilitatea și viteza îi permit să fie utilizat pentru controlul versiunilor de proiecte uriașe. Toate acestea fac din Mercurial un concurent demn pentru Git.

Sistem de control al versiunilor bazar.
(bazaar.canonical.com)

Bazaar este un sistem de control al versiunilor distribuit, disponibil gratuit, dezvoltat cu sprijinul Canonical Ltd. Este scris în Python și rulează pe sistemele de operare Linux, Mac OS X și Windows.

Spre deosebire de Git și Mercurial, care au fost create pentru a controla versiunile nucleului sistemului de operare Linux și, prin urmare, s-au concentrat pe performanță maximă atunci când lucrați cu un număr mare de fișiere, Bazaar s-a concentrat pe o interfață de utilizator convenabilă și prietenoasă. Optimizarea vitezei de lucru a fost realizată deja în a doua etapă, când au apărut deja primele versiuni ale programului.

Ca și în cazul multor alte sisteme de control al versiunilor, sistemul de comandă al lui Bazaar este foarte asemănător cu comenzile CVS sau Subversion, ceea ce, totuși, nu este surprinzător, deoarece oferă o soluție convenabilă, simplă și intuitivă. interfață clară interacțiunea cu programul.

Este bine că se acordă o mare atenție lucrului cu ramurile de proiect (crearea, fuzionarea ramurilor etc.), ceea ce este foarte important atunci când dezvoltați proiecte serioase și vă permite să efectuați îmbunătățiri și experimente fără amenințarea de a pierde versiunea principală a software-ului .

Un mare plus al acestui sistem de control al versiunilor este capacitatea de a lucra cu depozite ale altor sisteme de control al versiunilor, cum ar fi Subversion sau Git.

Să rezumăm pe scurt cele mai semnificative avantaje și dezavantaje ale acestui sistem de control al versiunilor.

Avantaje:

1. Suport multiplatform.

2. Interfață convenabilă și intuitivă.

3. Operare simplă cu ramuri de proiect.

4. Abilitatea de a lucra cu depozite ale altor sisteme de control al versiunilor.

5. Documentare excelentă.

6. Interfață grafică convenabilă.

7. Flexibilitate extremă, permițându-vă să vă adaptați nevoilor unui anumit utilizator.

Defecte:

1. Viteză mai mică în comparație cu git și mercurial, dar această situație se corectează treptat.

2. Pentru funcționalitate completă, este necesar să instalați un număr suficient de mare de plugin-uri care vă permit să dezvăluiți pe deplin toate capacitățile sistemului de control al versiunilor.

Concluzii:

bazar - sistem convenabil controlul versiunilor cu o interfață plăcută. Bun pentru utilizatorii care sunt descurajați de perspectiva de a lucra cu linia de comandă. Multe opțiuni și extensii suplimentare vă vor permite să personalizați programul în funcție de nevoile dvs. Asemănarea sistemului de comandă cu Git și Subversion și capacitatea de a lucra direct cu depozitele lor, vor face tranziția la Bazaar rapidă și nedureroasă. Succesul bazarului este evidențiat și de faptul că este folosit de dezvoltatorii Ubuntu Linux.

Sistem de control al versiunii Arch.

Arch este un sistem distribuit de control al versiunilor creat de Tom Lord. A fost creat inițial pentru a rezolva problemele CVS, pe care au reușit să le facă.

Arch efectuează operații atomice pentru a salva modificările în depozit, de exemplu. elimină situația de descărcare a unui depozit, când unele dintre modificări au fost descărcate, iar unele nu au avut încă timp să se descarce.

Capacitatea de a ramifica versiunile de proiect și de a îmbina ramuri individuale, de a redenumi și de a muta fișiere și directoare, păstrând în același timp istoricul modificărilor și multe alte caracteristici frumoase sunt acceptate.

Nu necesită un serviciu special pentru un depozit de rețea și poate utiliza protocoale precum FTP, SFTP sau WebDAV și așa mai departe.

Dar, din păcate, este acceptat doar de sistemele UNIX; totuși, transferul Arch pe alte sisteme de operare nu ar trebui să fie dificil.

Este greu de observat vreun element fundamental cele mai bune calități, în comparație cu alte sisteme de control al versiunilor distribuite precum git, mercurial, bazaar, așa că dacă ai de ales, este mai bine să folosești ceva mai puternic și mai răspândit.

Sistem de control al versiunilor Perforce.
(www.perforce.com)

Să continuăm revizuirea sistemelor de control al versiunilor și să trecem la programele comerciale. Să începem cu sistemul centralizat de control al versiunilor - Perforce, dezvoltat de Perforce Software.

Sistemul Perforce are o organizare client-server și vă permite să gestionați simultan mai multe proiecte, creându-și propriul depozit pentru fiecare proiect.

Perforce este un sistem multiplatform. Există versiuni care pot rula sub sisteme de operare sisteme Unix, Mac OS X, Microsoft Windows.

Pentru a lucra cu sistemul de control al versiunilor, puteți utiliza atât consola, cât și o interfață grafică special concepută.

Un avantaj major al Perforce este capacitatea de a se integra cu multe instrumente și aplicații de dezvoltare software, cum ar fi Autodesk 3D Studio Max, Maya, Adobe Photoshop, Microsoft Office, Eclipse, emacs și multe altele.

Suportul pentru capacitatea de a crea ramuri versiuni de proiect, de a le gestiona flexibil, de a le îmbina și de a reveni la versiunile anterioare face din Perforce un sistem complet competitiv și contribuie la distribuția sa largă. Cu toate acestea, acesta este un produs comercial, care îi restrânge oarecum domeniul de aplicare și îi limitează răspândirea. Este folosit în principal în marile companii comerciale, pentru care nu numai funcționalitatea este importantă, ci și suportul tehnic în timp util.

Sistemul de control al versiunilor Team Foundation Server.
(msdn.microsoft.com/en-us/library/ms364061.aspx)

Strict vorbind, Team Foundation Server (TFC) nu poate fi numit pur și simplu un sistem de control al versiunilor - este un fel de soluție cuprinzătoare care include un sistem de control al versiunilor, un sistem de colectare a datelor, raportare și alte funcții utile.

Un proiect gestionat atunci când lucrați cu TFC constă din ramuri de cod sursă de proiect, seturi de rapoarte și elemente personalizate. Când creați un proiect, parametrii acestuia sunt selectați în prealabil, pe care îi puteți alege fie dvs., fie să folosiți șabloane. Șabloanele vă permit să determinați calea dezvoltării proiectului, să îl faceți flexibil sau formalizat rigid, să stabiliți o strategie de dezvoltare și să țineți cont de documentele și rapoartele necesare.

TFC se integrează ușor cu Microsoft Excelși Microsoft Project, care facilitează crearea și urmărirea elementelor proiectelor controlate.

Ca sistem de control al versiunilor, TFC vă permite să:

Editați în colaborare fișierele de proiect;

Rezolvarea conflictelor;

Creați ramuri de proiect și apoi îmbinați-le;

Gestionați accesul la depozit;

Reveniți la versiunile anterioare;

Creați modificări în așteptare - modificări care nu sunt adăugate direct în depozit, dar pot fi văzute de alți utilizatori, iar aceste modificări pot fi descărcate doar obținând permisiunea specială de la proprietarul modificărilor;

Marcați versiunile individuale ale fișierelor în depozit și grupați-le;

Bazele de date SQL Server 2005 sunt folosite pentru a salva date și depozite ale proiectelor dezvoltate.

TFC este un instrument puternic și convenabil care vă permite nu numai să gestionați versiunile de cod sursă, ci și să organizați complet întregul ciclu de dezvoltare a proiectului, de la scrierea programelor până la documentația acestora. Cu toate acestea, acest puternic și un sistem complex mai potrivite pentru proiecte mari care necesită un management complex și minuțios al dezvoltării. Dacă aveți o dezvoltare mică, atunci are sens să utilizați un instrument mai puțin puternic, sau chiar mai bine, unul distribuit gratuit, deoarece acest lucru vă va economisi timp, bani și nervi.

Generalizare.

O gamă largă de sisteme de control al versiunilor vă permite să satisfaceți orice cerințe și să vă organizați munca așa cum aveți nevoie. Cu toate acestea, printre varietatea de sisteme există lideri clari. Deci, dacă aveți nevoie să gestionați un proiect uriaș format din zeci de mii de fișiere și la care lucrează mii de oameni, atunci cel mai bine este să alegeți Git sau Mercurial. Dacă principalul lucru pentru tine este interfață ușor de utilizat, iar proiectul în curs de dezvoltare nu este foarte mare, atunci sistemul Bazaar este de preferat pentru dvs.

Pentru programatori solo sau proiecte mici care nu necesită ramificare sau crearea mai multor versiuni, Subversion este cel mai bun pariu.

Dar în cele din urmă alegerea este o chestiune de gust, deoarece acum există multe sisteme de control al versiunilor care vă vor oferi tot ce aveți nevoie. Deci alege si nu vei regreta. Sistemele de control al versiunilor sunt software absolut esențial pentru fiecare dezvoltator și nu numai.

Bazele VCS

Introducere

Înainte de a vorbi despre oricare sistem specific controlul versiunilor, trebuie să înțelegeți ce sunt, ce sunt și de ce au apărut în primul rând. Această prelegere este menită să ofere o introducere inițială în controlul versiunilor și sistemele de control al versiunilor și mai întâi voi vorbi despre originile instrumentelor de control al versiunilor, care sisteme de control al versiunilor sunt populare în prezent și care sunt principalele diferențe între ele.

Despre controlul versiunilor

Ce este controlul versiunilor și de ce aveți nevoie de el?

Probabil că merită să începem cu definirea unui sistem de control al versiunilor (VCS) - acesta este un sistem care înregistrează modificările într-unul sau mai multe fișiere, astfel încât în ​​viitor să fie posibilă revenirea la anumite versiuni vechi ale acestor fișiere.

Recent, fișierele sunt rezultatul final pentru multe profesii (de exemplu, scris, munca științifică și, bineînțeles, dezvoltarea de software). Se cheltuie mult timp și efort pentru dezvoltarea și întreținerea acestor fișiere și nimeni nu vrea să fie nevoit să petreacă și mai mult timp și efort recuperând datele pierdute ca urmare a oricăror modificări.

Să ne imaginăm că un programator dezvoltă un proiect constând dintr-un fișier mic (apropo, exemplul este destul de real, nu sintetic, găsit în viata reala). După lansarea primei versiuni a proiectului, el se confruntă cu o alegere dificilă: este necesar să remedieze problemele raportate de utilizatorii primei versiuni și, în același timp, să dezvolte ceva nou pentru a doua. Chiar dacă trebuie doar să remediați problemele care apar, există o mare probabilitate ca, după unele modificări, proiectul să nu mai funcționeze și trebuie să determinați ce a fost modificat pentru a facilita localizarea problemei. De asemenea, este indicat să păstrați un fel de jurnal al modificărilor și corecțiilor efectuate, pentru a nu face aceeași muncă de mai multe ori.

În cel mai simplu caz, problema de mai sus poate fi rezolvată prin stocarea mai multor copii ale fișierelor, de exemplu, una pentru remedierea erorilor în prima versiune a proiectului și a doua pentru noile modificări. Deoarece modificările nu sunt de obicei foarte mari în comparație cu dimensiunea fișierului, este posibil să stocați numai liniile modificate folosind utilitarul diff și ulterior să le îmbinați folosind utilitarul de corecție. Dar dacă proiectul constă din câteva mii de fișiere și o sută de oameni lucrează la el? Dacă în acest caz folosim metoda cu stocare copii separate fișiere (sau chiar doar modificări), atunci proiectul se va bloca foarte repede. În prelegerile ulterioare, pentru exemple, voi folosi codurile sursă programe, dar de fapt, puteți pune aproape orice tip de fișier sub controlul versiunilor.

Dacă sunteți un designer grafic sau web și doriți să stocați fiecare versiune a unei imagini sau a unui aspect - și probabil ați face-o - atunci folosirea unui sistem de control al versiunilor este o decizie foarte înțeleaptă. VCS face posibilă returnarea fișierelor individuale la Ca înainte, readuceți întregul proiect la starea anterioară, vizualizați modificările care au loc de-a lungul timpului, stabiliți cine a fost ultimul care a făcut modificări unui modul care a încetat brusc să funcționeze, cine și când a introdus un fel de eroare în cod și multe altele. În general, dacă, în timp ce utilizați VCS, distrugeți totul sau pierdeți fișiere, totul poate fi restaurat cu ușurință. În plus, costul general pentru tot ce veți obține va fi foarte mic.

Sisteme locale de control al versiunilor

După cum am menționat mai devreme, un exemplu de VCS local este extrem de simplu: mulți oameni preferă să controleze versiunile prin simpla copiere a fișierelor într-un alt director (de obicei, adăugând data curentă la numele directorului). Această abordare este foarte comună pentru că este simplă, dar și eșuează mai des. Este foarte ușor să uiți că te afli în directorul greșit și să schimbi accidental fișierul greșit sau să copiați fișierele în locul greșit și să suprascrieți fișierele de care aveți nevoie. Pentru a rezolva această problemă, programatorii au dezvoltat de mult timp VCS-uri locale cu o bază de date simplă în care sunt stocate toate modificările. fisierele necesare

Unul dintre cele mai populare VCS de acest tip este RCS (Revision Control System), care este încă instalat pe multe computere. Chiar și pe sistemul de operare modern Mac OS X, utilitarul rcs este instalat împreună cu Instrumentele pentru dezvoltatori. RCS a fost dezvoltat la începutul anilor 1980 de Walter F. Tichy. Sistemul vă permite să stocați versiuni ale unui singur fișier, așa că trebuie să gestionați mai multe fișiere manual. Pentru fiecare fișier aflat sub controlul sistemului, informațiile despre versiune sunt stocate într-un fișier special numit dosarul original la care se adaugă la sfârșit caracterele „,v”. De exemplu, pentru fișierul file.txt, versiunile vor fi stocate în fișierul file.txt,v. Acest utilitar se bazează pe lucrul cu seturi de patch-uri între perechi de versiuni (un patch este un fișier care descrie diferența dintre fișiere). Acest lucru vă permite să recreați orice fișier în orice moment, aplicând patch-uri secvențial. Sistemul folosește utilitarul diff pentru a stoca versiunile. Deși RCS îndeplinește cerințele minime pentru un sistem de control al versiunilor, are următoarele dezavantaje principale, care au servit și ca imbold pentru crearea următorului sistem în considerare:

• Lucrați cu un singur fișier, fiecare fișier trebuie controlat separat;
• Mecanism incomod munca simultana mai mulți utilizatori cu sistemul, stocarea este pur și simplu blocată până când utilizatorul care l-a blocat îl deblochează;
• Nimeni nu te eliberează de backup-uri; riști să pierzi totul.

Sisteme centralizate de control al versiunilor

Următoarea provocare majoră a fost necesitatea de a colabora cu dezvoltatorii de pe alte computere. Pentru a rezolva acest lucru, au fost create sisteme centralizate de control al versiunilor (CVCS). Astfel de sisteme, cum ar fi CVS, Subversion și Perforce, au un server central care stochează toate fișierele sub controlul versiunilor și un număr de clienți care primesc copii ale fișierelor de la acesta. Acesta a fost standardul pentru sistemele de control al versiunilor de mulți ani.

Această abordare are multe avantaje, în special față de SLE local. De exemplu, toată lumea știe cine ce face în proiect. Administratorii au control clar asupra cine poate face ce și, desigur, administrarea CSKV este mult mai ușor decât baze de date locale pe fiecare client. Cu toate acestea, există mai multe dezavantaje serioase ale acestei abordări. Cel mai evident este că serverul centralizat este punctul slab al întregului sistem. Dacă serverul se defectează timp de o oră, atunci dezvoltatorii nu pot interacționa timp de o oră și nimeni nu poate salva o nouă versiune a muncii lor. Dacă discul cu baza de date centrală este deteriorat și nu există copie de rezervă, pierzi absolut totul - întregul istoric al proiectului, cu posibila excepție a mai multor versiuni de lucru salvate pe mașinile de lucru ale utilizatorilor.

CVS

CVS (Concurrent Versions System) este încă cel mai utilizat sistem, dar își pierde rapid din popularitate din cauza neajunsurilor pe care le voi discuta mai jos. Dick Grune a dezvoltat CVS la mijlocul anilor 1980. Pentru a stoca fișiere individuale, CVS (precum și RCS) utilizează fișiere în format RCS, dar vă permite să gestionați grupuri de fișiere situate în directoare. CVS folosește, de asemenea, o arhitectură client-server în care toate informațiile despre versiune sunt stocate pe server. Utilizarea unei arhitecturi client-server permite ca CVS să fie utilizat chiar și de către echipele de utilizatori distribuite geografic, unde fiecare utilizator are propriul director de lucru cu o copie a proiectului. După cum sugerează și numele, utilizatorii pot partaja sistemul.

Posibilele conflicte la modificarea aceluiași fișier sunt rezolvate prin faptul că sistemul permite modificări numai la cea mai recentă versiune a fișierului. Prin urmare, este întotdeauna recomandat să actualizați copia de lucru a fișierelor înainte de a încărca modificările în cazul unor posibile modificări conflictuale. La actualizare, sistemul efectuează automat modificări ale copiei de lucru și numai în cazul unor modificări conflictuale în una dintre locațiile fișierului, este necesară corectarea manuală a locației conflictului.

CVS vă permite, de asemenea, să mențineți mai multe linii de dezvoltare pe un proiect folosind ramuri de dezvoltare. Astfel, după cum am menționat mai sus, puteți corecta erorile din prima versiune a proiectului și puteți dezvolta simultan noi funcționalități.

CVS a fost folosit de un număr mare de proiecte, dar, desigur, nu a fost lipsit de deficiențele sale, care au dus ulterior la apariția următorului sistem luat în considerare. Să ne uităm la principalele dezavantaje:

• Deoarece versiunile sunt stocate în fișiere RCS, nu este posibilă salvarea versiunilor de director. Metoda standard a ocoli acest obstacol înseamnă a salva un fișier (de exemplu, README.txt) într-un director;
• Mutarea sau redenumirea fișierelor nu este supusă controlului versiunii. Modul standard de a face acest lucru este să copiați mai întâi fișierul, să îl eliminați pe cel vechi folosind comanda cvs remove și apoi să îl adăugați cu noul nume folosind comanda cvs add;

Subversiune

Subversion (SVN) a fost dezvoltat în 2000 la inițiativa CollabNet. SVN a fost dezvoltat inițial ca un „CVS mai bun”, iar scopul principal al dezvoltatorilor a fost să corecteze erorile făcute în designul CVS, menținând în același timp o interfață similară. SVN, ca și CVS, utilizează o arhitectură client-server. Cele mai semnificative modificări în comparație cu CVS includ:

• Modificări atomice (commit). Dacă procesarea de comitere este întreruptă, nu se vor face modificări.
• Redenumirea, copierea și mutarea fișierelor păstrează întregul istoric al modificărilor.
• Directoarele, linkurile simbolice și metadatele sunt supuse controlului versiunilor.
• Stocare eficientă a modificărilor pentru fișierele binare.

Sisteme distribuite de control al versiunilor

Și în această situație intră în joc sistemele distribuite de control al versiunilor (DVCS). În sisteme precum Git, Mercurial, Bazaar sau Darcs, clienții nu pur și simplu verifică cele mai recente versiuni de fișiere, ci copiază întregul depozit. Prin urmare, în cazul în care serverul prin care se derula munca „moare”, orice depozit de client poate fi copiat înapoi pe server pentru a restaura baza de date. De fiecare dată când un client preia o nouă versiune de fișiere, el creează singur copie integrală toate datele.

În plus, majoritatea acestor sisteme vă permit să lucrați cu mai multe depozite de la distanță, astfel încât să puteți lucra diferit cu diferite grupuri de oameni pe același proiect în același timp. Astfel, într-un singur proiect puteți conduce simultan mai multe tipuri de procese de lucru, ceea ce este imposibil în sistemele centralizate.

De ce sunt necesare sisteme distribuite?

După cum sugerează și numele, una dintre ideile principale ale sistemelor distribuite este absența unui magazin de versiuni central desemnat clar - un depozit. În cazul sistemelor distribuite, un set de versiuni poate fi distribuit integral sau parțial între diferite depozite, inclusiv cele la distanță. Acest model se încadrează perfect în munca echipelor distribuite, de exemplu, o echipă de dezvoltatori distribuiți în întreaga lume care lucrează la același proiect open source. Dezvoltatorul unei astfel de echipe poate descărca toate informațiile despre versiune și apoi poate lucra numai pe mașina locală. De îndată ce rezultatul uneia dintre etapele de lucru este atins, modificările pot fi încărcate într-unul dintre depozitele centrale sau publicate pentru vizualizare pe site-ul dezvoltatorului sau în listă de email-uri. Alți participanți la proiect, la rândul lor, vor putea să își actualizeze copia depozitului de versiuni cu noi modificări sau să încerce modificările publicate într-o ramură separată de dezvoltare de testare. Din păcate, fără o bună organizare a proiectului, lipsa unui singur depozit central poate fi un dezavantaj al sistemelor distribuite. Dacă în cazul sistemelor centralizate există întotdeauna un singur depozit comun de unde puteți obține cea mai recentă versiune a proiectului, atunci în cazul sistemelor distribuite trebuie să decideți organizațional care dintre ramurile proiectului va fi cea principală. De ce ar fi un sistem distribuit de control al versiunilor de interes pentru cineva care utilizează deja un sistem centralizat - cum ar fi Subversion? Toată munca implică luarea de decizii și, în majoritatea cazurilor, trebuie să încercați diferite opțiuni: atunci când lucrați cu sisteme de control al versiunilor, ramurile de dezvoltare sunt folosite pentru a lua în considerare diferite opțiuni și pentru a lucra la schimbări mari. Deși acesta este un concept destul de natural, nu este ușor de utilizat în Subversion. În plus, totul devine mai complicat în cazul îmbinărilor secvenţiale multiple de la o ramură la alta - în acest caz, trebuie să indicaţi cu exactitate iniţiala şi versiuni finale orice modificare pentru a evita conflictele și erorile. Pentru sistemele de control al versiunilor distribuite, ramurile de dezvoltare sunt unul dintre conceptele fundamentale - în majoritatea cazurilor, fiecare copie a unui magazin de versiuni este o ramură de dezvoltare. Astfel, mecanismul de îmbinare a modificărilor de la o ramură la alta în cazul sistemelor distribuite este unul dintre principalele, ceea ce permite utilizatorilor să depună mai puțin efort atunci când folosesc sistemul.

Scurtă descriere a SUV-urilor populare distribuite

• Git este un sistem distribuit de control al versiunilor dezvoltat de Linus Torvalds. Inițial, Git a fost destinat utilizării în procesul de dezvoltare a nucleului Linux, dar mai târziu a început să fie folosit în multe alte proiecte, cum ar fi, de exemplu, X.org și Ruby on Rails, Drupal. Git este în prezent cel mai rapid sistem distribuit folosind cel mai mic magazin de revizii. Dar, în același timp, pentru utilizatorii care migrează, de exemplu, de la Subversion, interfața Git poate părea complicată;
• Mercurial este un sistem distribuit scris în Python cu mai multe extensii în C. Proiectele care folosesc Mercurial includ Mozilla și MoinMoin.
• Bazaar este un sistem dezvoltat de Canonical, cunoscut pentru distribuția Ubuntu și site-ul web https://launchpad.net/. Sistemul este scris în principal în Python și este folosit de proiecte precum MySQL.
• Codeville este un sistem distribuit scris în Python care utilizează un algoritm inovator pentru combinarea modificărilor (merge). Sistemul este utilizat, de exemplu, în dezvoltarea clientului original BitTorrent.
• Darcs este un sistem distribuit de control al versiunilor scris în Haskell, folosit, de exemplu, de proiectul Buildbot.
• Monotone este un sistem scris în C++ și care folosește SQLite ca stocare de revizuire.

Ce este controlul versiunilor și de ce aveți nevoie de el? Un sistem de control al versiunilor (VCS) este un sistem care înregistrează modificările aduse unuia sau mai multor fișiere, astfel încât în ​​viitor să fie posibilă revenirea la anumite versiuni mai vechi ale acestor fișiere. Vom folosi codul sursă pentru exemplele din această carte, dar, în realitate, puteți pune aproape orice tip de fișier sub controlul versiunilor.

Dacă sunteți un designer grafic sau web și doriți să stocați fiecare versiune a unei imagini sau a unui aspect - și probabil ați face-o - atunci folosirea unui sistem de control al versiunilor este o decizie foarte înțeleaptă. VCS face posibilă readucerea fișierelor individuale la forma lor anterioară, readucerea întregului proiect la starea anterioară, vizualizarea modificărilor care au loc de-a lungul timpului, determinarea cine a fost ultimul care a făcut modificări unui modul care a încetat brusc să funcționeze, cine și când a introdus un fel de eroare în cod și multe altele. În general, dacă, în timp ce utilizați VCS, distrugeți totul sau pierdeți fișiere, totul poate fi restaurat cu ușurință. În plus, costul general pentru tot ce veți obține va fi foarte mic.

Sisteme locale de control al versiunilor

Mulți oameni preferă să controleze versiunile prin simpla copiere a fișierelor într-un alt director (de obicei, adăugând data curentă la numele directorului). Această abordare este foarte comună pentru că este simplă, dar și eșuează mai des. Este foarte ușor să uiți că te afli în directorul greșit și să schimbi accidental fișierul greșit sau să copiați fișierele în locul greșit și să suprascrieți fișierele de care aveți nevoie.

Pentru a rezolva această problemă, programatorii au dezvoltat de mult timp VCS-uri locale cu o bază de date simplă în care sunt stocate toate modificările la fișierele necesare (vezi Figura 1-1).

Figura 1-1. Schema de LES local.

Unul dintre cele mai populare VCS de acest tip este rcs, care este încă instalat pe multe computere. Chiar și pe sistemul de operare modern Mac OS X, utilitarul rcs este instalat împreună cu Instrumentele pentru dezvoltatori. Acest utilitar se bazează pe lucrul cu seturi de patch-uri între perechi de versiuni (un patch este un fișier care descrie diferența dintre fișiere), care sunt stocate în format special pe disc. Acest lucru vă permite să recreați orice fișier în orice moment, aplicând patch-uri secvențial.

Sisteme centralizate de control al versiunilor

Următoarea provocare majoră a fost necesitatea de a colabora cu dezvoltatorii de pe alte computere. Pentru a rezolva acest lucru, au fost create sisteme centralizate de control al versiunilor (CVCS). Astfel de sisteme, cum ar fi CVS, Subversion și Perforce, au un server central care stochează toate fișierele sub controlul versiunilor și un număr de clienți care primesc copii ale fișierelor de la acesta. Acesta a fost standardul pentru sistemele de control al versiunilor de mulți ani (vezi Figura 1-2).

Figura 1-2. Schema centralizată de control al versiunilor.

Această abordare are multe avantaje, în special față de SLE local. De exemplu, toată lumea știe cine ce face în proiect. Administratorii au control clar asupra cine poate face ce și, desigur, CSKB este mult mai ușor de administrat decât bazele de date locale pe fiecare client.

Cu toate acestea, există mai multe dezavantaje serioase ale acestei abordări. Cel mai evident este că serverul centralizat este punctul slab al întregului sistem. Dacă serverul se defectează timp de o oră, atunci dezvoltatorii nu pot interacționa timp de o oră și nimeni nu poate salva o nouă versiune a muncii lor. Dacă discul cu baza de date centrală este deteriorat și nu există o copie de rezervă, pierzi absolut totul - întregul istoric al proiectului, cu posibila excepție a mai multor versiuni de lucru salvate pe mașinile de lucru ale utilizatorilor. Sistemele locale de control al versiunilor suferă de aceeași problemă: dacă întregul istoric al unui proiect este stocat într-un singur loc, riscați să pierdeți totul.

Sisteme distribuite de control al versiunilor

Și în această situație intră în joc sistemele distribuite de control al versiunilor (DVCS). În sisteme precum Git, Mercurial, Bazaar sau Darcs, clienții nu pur și simplu verifică cele mai recente versiuni de fișiere, ci copiază întregul depozit. Prin urmare, în cazul în care serverul prin care se derula munca „moare”, orice depozit de client poate fi copiat înapoi pe server pentru a restaura baza de date. De fiecare dată când clientul verifică cea mai recentă versiune a fișierelor, acesta creează o copie completă a tuturor datelor pentru el însuși (vezi Figura 1-3).

Figura 1-3. Diagrama unui sistem distribuit de control al versiunilor.

În plus, majoritatea acestor sisteme vă permit să lucrați cu mai multe depozite de la distanță, astfel încât să puteți lucra diferit cu diferite grupuri de oameni pe același proiect în același timp. Astfel, într-un singur proiect puteți conduce simultan mai multe tipuri de procese de lucru, ceea ce este imposibil în sistemele centralizate.

Bună, Habr. Am decis să ating un subiect care a fost epuizat în multe articole, mai precis, pentru a descrie utilizarea în mare parte non-standard (aș spune, nesortată) a sistemelor de control al versiunilor (denumite în continuare VCS). Colegii programatori, haideți să ascundem roșiile putrede și să mergem mai departe, pentru că acest articol nu este pentru voi. Da, cu toții ați învățat deja toate complexitățile Git, SVN, CVS și cunoașteți multe altele cuvinte inteligente. Să ne familiarizăm, simpli muritori, cu toate avantajele folosirii monedei forte.
Invit pe toți cei care doresc să se familiarizeze cu sistemul valutar, precum și pe toți cei care, într-un fel sau altul, se ocupă de date în schimbare rapidă.

De ce este necesar acest lucru?

Ce se poate face în acest sens sau ce este SLE

Ce tipuri de valută puternică există?

De la teorie la practică sau începerea utilizării SLE

Pentru cine este acest articol?

P.S. Mutat pe blogul „Sisteme de control al versiunilor”.

Etichete:

• sisteme de control al versiunilor
• mercurial
• bitbucket

Sistem de control al versiunilor

Sistem de control al versiunilor(din engleza Sistem de control al versiunilor, VCS sau Revision Control System) - software pentru a facilita lucrul cu informații în schimbare. Un sistem de control al versiunilor vă permite să stocați mai multe versiuni ale aceluiași document, să reveniți la versiunile anterioare dacă este necesar, să determinați cine a făcut o anumită modificare și când și multe altele.

Astfel de sisteme sunt cele mai utilizate în dezvoltarea de software pentru stocarea codurilor sursă ale programului în curs de dezvoltare. Cu toate acestea, ele pot fi aplicate cu succes în alte domenii în care se lucrează cu un număr mare de schimbări continue documente electronice. În special, sistemele de control al versiunilor sunt utilizate în CAD, de obicei ca parte a sistemelor de management al datelor de produs (PDM). Versiunea este utilizată în instrumentele de gestionare a configurației ( Instrumente de management al configurației software).

Atunci când se determină admisibilitatea îmbinării modificărilor în cadrul aceluiași fișier text, funcționează un mecanism standard de comparare a textului linie cu linie (un exemplu de implementare a acestuia este utilitarul sistemului GNU diff), care compară versiunile îmbinate cu cea de bază și construiește un lista de modificări, adică seturi de linii adăugate, șterse și înlocuite. Unitatea minimă de date pentru acest algoritm este un șir; chiar și cea mai mică diferență face ca șirurile să fie diferite. Având în vedere că caracterele delimitare, în cele mai multe cazuri, nu poartă nicio încărcare semantică, mecanismul de îmbinare poate ignora aceste caractere atunci când compară șiruri.

Acele seturi de șiruri modificate găsite care nu se intersectează sunt considerate compatibile și îmbinarea lor se face automat. Dacă fișierele îmbinate conțin modificări care afectează aceeași linie de fișier, acest lucru duce la un conflict. Astfel de fișiere pot fi îmbinate numai manual. Orice fișiere altele decât fișierele text sunt binare din punct de vedere VCS și nu permit îmbinarea automată.

Conflictele și rezolvarea lor

Se numește situația în care, la îmbinarea mai multor versiuni, modificările făcute în ele se intersectează între ele conflict. Dacă există un conflict de modificări, sistemul de control al versiunilor nu poate crea automat un proiect fuzionat și este forțat să contacteze dezvoltatorul. După cum s-a menționat mai sus, conflictele pot apărea în etapele de comitere a modificărilor, actualizarea sau fuzionarea sucursalelor. În toate cazurile, atunci când este detectat un conflict, operația corespunzătoare este oprită până când este rezolvată. Unele sisteme (de ex. Subversion) nici măcar nu încearcă să rezolve conflictele la etapa de comitere sau de ramură; Dacă apar astfel de conflicte, operațiunea este complet anulată și dezvoltatorului i se cere să actualizeze mai întâi copia de lucru (evident, vor apărea aceleași conflicte), să rezolve conflictele și abia apoi să îmbine modificările sale în ramura de bază.

Pentru a rezolva un conflict, sistemul, în general, oferă dezvoltatorului trei opțiuni pentru fișierele aflate în conflict: de bază, local și server. Modificările aflate în conflict fie sunt afișate dezvoltatorului într-un modul software special pentru îmbinarea modificărilor (în acest caz, opțiunile îmbinate și versiunea combinată a fișierului care se schimbă dinamic în funcție de comenzile utilizatorului) sau pur și simplu sunt marcate direct cu un marcaj special. în textul fișierului îmbinat (atunci dezvoltatorul trebuie să genereze el însuși textul dorit în zonele în litigiu și să-l păstreze).

Conflictele din sistemul de fișiere sunt rezolvate mai ușor: doar ștergerea unui fișier poate intra în conflict cu una dintre celelalte operațiuni, iar ordinea fișierelor din director nu contează, astfel încât dezvoltatorul poate alege doar ce operație trebuie salvată în versiune combinată.

Încuietori

Mecanismul de blocare permite unuia dintre dezvoltatori să utilizeze exclusiv un fișier sau un grup de fișiere pentru a le face modificări. În timp ce fișierul este blocat, acesta rămâne doar în citire pentru toți ceilalți dezvoltatori și orice încercare de a-i face modificări este respinsă de server. Din punct de vedere tehnic, blocarea poate fi organizată în diferite moduri. Următorul mecanism este tipic pentru sistemele moderne.

Utilizarea masivă a blocărilor, atunci când toate sau majoritatea fișierelor dintr-un proiect sunt blocabile și pentru orice modificare este necesară blocarea setului corespunzător de fișiere, se mai numește și strategia de „verificare blocată”. Sistemele timpurii de control al versiunilor au susținut exclusiv această strategie, prevenind astfel apariția conflictelor în primul rând. În VCS modern, se preferă utilizarea recuperărilor neblocante, în timp ce blocarea este considerată mai mult un rău necesar care ar trebui limitat ori de câte ori este posibil. Dezavantajele utilizării încuietorilor sunt evidente:

• Blocările pur și simplu interferează cu munca productivă, deoarece vă obligă să așteptați eliberarea fișierelor blocate, deși, în majoritatea cazurilor, chiar și modificările comune ale acelorași fișiere care sunt făcute în cursul diferitelor lucrări nu se suprapun și sunt îmbinate automat la îmbinare. .
• Frecvența conflictelor și complexitatea rezolvării lor în majoritatea cazurilor nu sunt atât de mari încât să creeze dificultăți serioase. Apariția unui conflict serios de modificări semnalează cel mai adesea fie o diferență semnificativă în opiniile diferiților dezvoltatori cu privire la proiectarea aceluiași fragment, fie o organizare incorectă a muncii (când doi sau mai mulți dezvoltatori fac același lucru).
• Blocările creează probleme administrative. Exemplu tipic: Un dezvoltator poate uita să deblocheze fișierele cu care este ocupat în timp ce pleacă în vacanță. Pentru a rezolva astfel de probleme, este necesar să se aplice măsuri administrative, inclusiv să includă mijloace tehnice în sistem pentru a reseta încuietori incorecte, dar chiar dacă acestea sunt prezente, se petrece timp pentru a pune în ordine sistemul.

Pe de altă parte, în unele cazuri, utilizarea încuietorilor este destul de justificată. Un exemplu evident este organizarea muncii cu fișiere binare pentru care nu există instrumente de îmbinare a modificărilor sau o astfel de îmbinare este fundamental imposibilă (ca, de exemplu, pentru fișierele imagine). Dacă îmbinarea automată nu este posibilă, atunci în funcționarea normală orice modificare concomitentă fișiere similare va duce la conflict. ÎN în acest caz, Este mult mai convenabil să faceți blocarea unui astfel de fișier pentru a vă asigura că orice modificări ale acestuia vor fi făcute numai secvenţial.

Versiuni de proiect, etichete

Sistemul de control al versiunilor asigură stocarea tuturor versiunilor existente de fișiere și, ca urmare, a tuturor versiunilor de proiect în ansamblu care au apărut de la începutul dezvoltării acestuia. Dar însăși conceptul de „versiune” în sisteme diferite poate fi interpretat în două moduri diferite.

Unele sisteme acceptă versiunea fişiere. Aceasta înseamnă că orice fișier care apare în proiect primește propriul număr versiunea (de obicei numărul 1, versiunea condiționată „zero” a fișierului este luată în considerare dosar gol cu acelasi nume). De fiecare dată când un dezvoltator comite modificări într-un fișier, partea corespunzătoare a modificărilor comise este aplicată fișierului și fișierul primește un nou număr de versiune, de obicei secvenţial. Deoarece commit-urile afectează de obicei doar o parte din fișierele din depozit, numerele de versiune ale fișierelor disponibile în același moment diferă în timp, iar proiectul în ansamblu (adică întregul set de fișiere din depozit) nu nu are de fapt niciun „număr de versiune”, deoarece constă din multe fișiere cu numere de versiune diferite. De exemplu, sistemul de control al versiunilor CVS funcționează într-un mod similar.

Pentru alte sisteme, conceptul de „versiune” se referă nu la un fișier individual, ci la repertoriuîn întregime. Un depozit gol nou creat are versiunea 1 sau 0, orice comitere a modificărilor duce la o creștere a acestui număr (adică, chiar dacă un fișier se modifică cu un octet, întregul depozit este considerat modificat și primește un nou număr de versiune). Acesta este modul în care numerele de versiune sunt interpretate, de exemplu, de sistemul Subversion. Numărul versiunii unui fișier individual aici, de fapt, nu există; putem considera condiționat că numărul versiunii curente a depozitului este un astfel de (adică, să presupunem că, cu fiecare modificare făcută în depozit, toate fișierele sale schimbă versiunea număr, chiar și cele care nu s-au schimbat). Uneori, când vorbim despre o „versiune de fișier” în astfel de sisteme, se referă la versiunea depozitului în care fișierul a fost modificat ultima dată (înainte de momentul de interes pentru noi).

În scopuri practice, de obicei, nu dosarul individual contează, ci întregul proiect. În sistemele care acceptă versiunea fișierelor individuale, data și ora pot fi utilizate pentru a identifica o anumită versiune a unui proiect - atunci versiunea proiectului va consta din acele versiuni ale fișierelor incluse în el care se aflau în depozit la un moment dat. . Dacă versiunea arhivei în întregime este acceptată, numărul versiunii proiectului poate fi numărul versiunii depozitului. Cu toate acestea, ambele opțiuni nu sunt foarte convenabile, deoarece nici data, nici numărul versiunii depozitului nu conțin de obicei informații despre schimbările semnificative ale proiectului, despre cât de mult și intens au lucrat la el. Pentru a marca mai convenabil versiunile unui proiect (sau ale părților sale), sistemele de control al versiunilor susțin conceptul Etichete.

Etichetă este o etichetă simbolică care poate fi asociată cu o anumită versiune a unui fișier și/sau director din depozit. Folosind comanda corespunzătoare, toate sau o parte din fișierele de proiect care îndeplinesc anumite condiții (de exemplu, incluse în versiunea principală a ramurii principale a proiectului pe anumit moment timp) i se poate atribui o etichetă specificată. În acest fel, puteți identifica versiunea proiectului (versiunea „XX.XXX.XXX” este un set de versiuni ale fișierelor de depozit cu eticheta „XX.XXX.XXX”), reparându-i astfel starea la un moment dorit. De regulă, sistemul de etichetare este destul de flexibil și vă permite să etichetați mai multe versiuni de fișiere și directoare cu o singură etichetă. Acest lucru vă permite să construiți o „versiune de proiect” în orice mod arbitrar. Din perspectiva unui utilizator de sistem, etichetarea poate arăta diferit. În unele sisteme, este descris exact ca un semn (o etichetă poate fi creată, aplicată anumitor versiuni de fișiere și directoare sau eliminată). În alte sisteme (de exemplu, Subversion), o etichetă este pur și simplu un director separat în arborele de fișiere de depozit, unde se fac copii din trunchiul și ramurile proiectului folosind comanda copy versiunile necesare fișiere. Deci vizual, o etichetă este pur și simplu o copie a anumitor versiuni ale fișierelor de depozit plasate într-un director separat. Prin convenție, arborele de directoare corespunzător unei etichete nu are voie să comite modificări (adică versiunea proiectului reprezentată de etichetă este imuabilă).

Principii de bază ale dezvoltării software în VCS

Procedura de utilizare a unui sistem de control al versiunilor în fiecare caz specific este determinată de reglementările tehnice și regulile adoptate de compania sau organizația specifică care desfășoară proiectul. Cu toate acestea, principii generale utilizarea corectă VCS sunt puține și uniforme pentru orice dezvoltare și sisteme de control al versiunilor.

1. Orice versiuni de lucru, de testare sau demo ale proiectului sunt colectate numai din depozitul de sistem. Compilările „personale”, care includ modificări care nu au fost încă efectuate, pot fi făcute numai de dezvoltatori în scopuri de testare intermediară. Acest lucru asigură că depozitul conține tot ce este necesar pentru a crea versiune de lucru proiect.
2. Versiunea actuală a ramului principal este întotdeauna corectă. Nu este permisă efectuarea unor modificări la ramura principală care sunt incomplete sau care nu au trecut cel puțin testele preliminare. În orice moment, construirea proiectului din versiunea curentă ar trebui să aibă succes.
3. Orice schimbare semnificativă ar trebui să fie documentată ca o ramură separată. Rezultatele intermediare ale activității dezvoltatorului sunt înregistrate în această ramură. Odată ce schimbarea este finalizată, ramura este îmbinată cu trunchiul. Sunt permise excepții numai pentru modificări minore, lucrările la care sunt efectuate de către un dezvoltator în cel mult o zi lucrătoare.
4. Versiunile de proiect sunt marcate cu etichete. Versiunea evidențiată și etichetată nu se mai schimbă niciodată.

Sisteme distribuite de control al versiunilor

Vezi si

• Managementul configurației (Software Configuration Management), instrumente de management al configurației (Software Configuration Management Tools)
• Produse software cu control transparent al versiunilor
  • Câteva implementări