Sistem de control al versiunilor (utilizat și definiția „sistem de control al versiunii [1] ”, din limba engleză Version Control System, VCS sau Revision Control System ) - software pentru a facilita lucrul cu informații în schimbare. Sistemul 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 modificare și când și multe altele.
Astfel de sisteme sunt cele mai utilizate în dezvoltarea de software pentru a stoca codurile sursă ale programului în curs de dezvoltare. Cu toate acestea, ele pot fi aplicate cu succes și în alte domenii în care se lucrează cu un număr mare de documente electronice aflate în continuă schimbare. Î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 software .
Software- ul Wikipedia menține un istoric al revizuirilor pentru toate articolele sale folosind metode similare cu cele utilizate în sistemele de control al versiunilor.
Situația în care un document electronic suferă o serie de modificări pe parcursul existenței sale este destul de tipică. În acest caz, este adesea important să aveți nu numai cea mai recentă versiune, ci și mai multe versiuni anterioare. În cel mai simplu caz, puteți stoca pur și simplu mai multe versiuni ale documentului, numerotându-le corespunzător. Această metodă este ineficientă (trebuie să stocați mai multe copii aproape identice), necesită atenție și disciplină sporite și adesea duce la erori, așa că au fost dezvoltate instrumente pentru automatizarea acestei lucrări.
Sistemele tradiționale de control al versiunilor folosesc un model centralizat în care există un singur depozit de documente gestionat de un server special care realizează majoritatea funcțiilor de control al versiunilor. Un utilizator care lucrează cu documente trebuie să obțină mai întâi versiunea documentului de care are nevoie din depozit; de obicei, se creează o copie locală a documentului, așa-numita „copie de lucru”. Se poate obține cea mai recentă versiune, sau oricare dintre cele anterioare, care poate fi selectată după numărul versiunii sau data creării, uneori după alte criterii. După ce se fac modificările dorite în document, noua versiune este plasată în depozit. Spre deosebire de simpla salvare a unui fișier, versiunea anterioară nu este ștearsă, dar rămâne și în depozit și poate fi preluată de acolo în orice moment. Serverul poate folosi așa-numitul. Compresia Delta este o modalitate de stocare a documentelor care salvează doar modificările dintre versiunile succesive, ceea ce reduce cantitatea de date stocate. Deoarece cea mai recentă versiune a unui fișier este de obicei cea mai solicitată, sistemul poate salva întregul fișier atunci când salvează o nouă versiune, înlocuind ultima versiune salvată anterior în depozit cu diferența dintre aceasta și cea mai recentă versiune. Unele sisteme (de exemplu, ClearCase ) acceptă salvarea versiunilor de ambele tipuri: majoritatea versiunilor sunt salvate ca delte, dar periodic (prin comanda specială a administratorului) toate fișierele sunt salvate în versiuni complete; această abordare asigură cea mai completă recuperare a istoricului în caz de deteriorare a depozitului .
Uneori, crearea unei noi versiuni este realizată imperceptibil pentru utilizator (în mod transparent), fie printr-un program de aplicație care are suport încorporat pentru o astfel de funcție, fie prin utilizarea unui sistem de fișiere special . În acest caz, utilizatorul pur și simplu lucrează cu fișierul ca de obicei, iar atunci când fișierul este salvat, o nouă versiune este creată automat.
Se întâmplă adesea ca mai multe persoane să lucreze la același proiect în același timp. Dacă două persoane modifică același fișier , una dintre ele poate anula accidental modificările făcute de cealaltă. Sistemele de control al versiunilor urmăresc astfel de conflicte și oferă instrumente pentru a le rezolva. Majoritatea sistemelor pot îmbina (imbina) automat modificările făcute de diferiți dezvoltatori. Cu toate acestea, o astfel de îmbinare automată a modificărilor este de obicei posibilă numai pentru fișierele text și cu condiția ca diferite părți (nesuprapuse) ale acestui fișier să fi fost modificate. Această limitare se datorează faptului că majoritatea sistemelor de control al versiunilor sunt axate pe sprijinirea procesului de dezvoltare a software-ului, iar codurile sursă ale programului sunt stocate în fișiere text. Dacă îmbinarea automată eșuează, sistemul poate oferi rezolvarea manuală a problemei.
Este adesea imposibil să îmbinați fie automat, fie manual, de exemplu, dacă formatul fișierului este necunoscut sau prea complex. Unele sisteme de control al versiunilor vă oferă opțiunea de a bloca un fișier în seif. Blocarea împiedică alți utilizatori să obțină o copie de lucru sau împiedică modificarea copiei de lucru a unui fișier (de exemplu, prin intermediul sistemului de fișiere) și astfel oferă acces exclusiv numai utilizatorului care lucrează cu documentul.
Multe sisteme de control al versiunilor oferă o serie de alte caracteristici:
Fiecare sistem de control al versiunii are propriile caracteristici specifice în ceea ce privește setul de comenzi, comportamentul utilizatorului și administrarea. Cu toate acestea, procedura generală de operare pentru majoritatea VCS-urilor este complet stereotipată. Se presupune aici că proiectul, oricare ar fi el, există deja și că depozitul său este găzduit pe server , la care dezvoltatorul are acces.
Prima acțiune pe care trebuie să o efectueze un dezvoltator este să verifice o copie funcțională a proiectului sau a părții din acesta pe care urmează să se lucreze. Această acțiune este efectuată folosind comanda version checkout (de obicei checkout sau clone ). Dezvoltatorul specifică versiunea care ar trebui copiată, în mod implicit, cea mai recentă versiune (sau alegerea administratorului ca principală) este de obicei copiată.
Comanda de extracție stabilește o conexiune la server, iar proiectul (sau o parte a acestuia - unul dintre directoarele cu subdirectoare) este copiat pe computerul dezvoltatorului sub forma unui arbore de directoare și fișiere. O practică obișnuită este duplicarea copiei de lucru: în plus față de directorul principal cu proiectul, o altă copie a acesteia este scrisă suplimentar pe discul local (fie într-un director separat, special selectat, fie în subdirectoarele de sistem ale proiectului principal). copac). În timp ce lucrează la un proiect, dezvoltatorul modifică doar fișierele din copia principală de lucru. A doua copie locală este stocată ca referință, permițându-vă să determinați în orice moment, fără a contacta serverul, ce modificări au fost făcute unui anumit fișier sau proiect în ansamblu și din ce versiune a fost „produsă” copia de lucru; de regulă, orice încercare de a modifica manual această copie are ca rezultat erori în funcționarea software-ului VCS.
Cu unele variații, determinate de caracteristicile sistemului și de detaliile procesului tehnologic adoptat, ciclul obișnuit al muncii dezvoltatorului în timpul zilei de lucru este următorul.
Actualizarea unei copii de lucru Pe măsură ce se fac modificări la versiunea principală a proiectului, copia de lucru de pe computerul dezvoltatorului devine mai veche: discrepanța sa cu versiunea principală a proiectului crește. Acest lucru crește riscul unor modificări conflictuale (vezi mai jos ). Prin urmare, este convenabil să păstrați copia de lucru într-o stare cât mai apropiată de versiunea majoră curentă, pentru care dezvoltatorul efectuează operațiunea de actualizare a copiei de lucru ( update ) cât mai des posibil (se determină frecvența reală a actualizărilor). de frecvența modificărilor, în funcție de activitatea de dezvoltare și de numărul de dezvoltatori, precum și de timpul petrecut pentru fiecare actualizare - dacă este mare, dezvoltatorul este obligat să limiteze frecvența actualizărilor pentru a nu pierde timpul) . Modificarea proiectului Dezvoltatorul modifică proiectul prin modificarea fișierelor incluse în acesta în copia de lucru în conformitate cu sarcina proiectului. Această lucrare se face local și nu necesită apeluri către serverul VCS. Comiterea Schimbărilor După ce a finalizat următoarea etapă de lucru asupra sarcinii, dezvoltatorul își comite ( commite ) modificările, transferându-le pe server (fie în ramura principală, dacă munca la sarcină este complet finalizată, fie într-o ramură de dezvoltare separată a acestei sarcini. ). VCS poate solicita dezvoltatorului să actualizeze copia de lucru înainte de comitere. Dacă sistemul acceptă modificări amânate ( rafturi ), modificările pot fi transferate pe server fără a fi comise. Dacă politica de lucru aprobată în VCS permite acest lucru, atunci repararea modificărilor poate fi efectuată nu zilnic, ci numai după finalizarea lucrărilor la sarcină; în acest caz, toate modificările asociate sarcinii sunt salvate numai în copia de lucru locală a dezvoltatorului până la finalizarea lucrării.Puteți face corecții minore în proiect prin editarea directă a copiei de lucru și apoi comiterea modificărilor direct în ramura principală (în trunk) de pe server. Cu toate acestea, atunci când se efectuează lucrări la scară largă, această ordine devine incomodă: lipsa remedierii modificărilor intermediare pe server nu permite lucrul la nimic într-un mod de grup, în plus, riscul de a pierde modificări în timpul accidentelor locale crește și capacitatea de a analizați și reveniți la versiunile anterioare ale codului într-o anumită lucrare. Prin urmare, pentru astfel de modificări, este o practică obișnuită să se creeze ramuri ( ramură ), adică „ramificare” din trunchi într-o versiune a unei noi versiuni a proiectului sau a unei părți a acestuia, a cărei dezvoltare se realizează în paralel. cu modificări în versiunea principală. Ramura este creată printr-o comandă specială. Copia de lucru a unei ramuri poate fi recreată în mod obișnuit (cu comanda de verificare a copiei de lucru, specificând adresa sau ID-ul ramurii) sau prin comutarea unei copii de lucru existente la o anumită ramură.
Ciclul de lucru de bază atunci când se utilizează ramuri rămâne exact același ca în cazul general: dezvoltatorul actualizează periodic copia de lucru (dacă mai mult de o persoană lucrează pe ramură) și își angajează munca zilnică. Uneori, o ramură de dezvoltare rămâne singură (atunci când modificările generează o nouă versiune a proiectului, care apoi se dezvoltă separat de cea principală), dar mai des, atunci când lucrarea pentru care a fost creată ramura, ramura este reintegrată în trunchiul (ramura principală). Acest lucru se poate face cu o comandă merge (de obicei merge ), sau prin crearea unui patch ( patch ) care conține modificările făcute în timpul dezvoltării ramurilor și aplicând acel patch la versiunea majoră curentă a proiectului.
Trei tipuri de operații efectuate în controlul sursei pot duce la necesitatea îmbinării modificărilor. Aceasta:
În toate cazurile, situația este în esență aceeași și are următoarele trăsături caracteristice:
Este destul de evident că dacă condiția (2) nu este îndeplinită (adică dacă modificările au fost făcute numai la original sau numai la o copie), fuzionarea este elementară - este suficient să copiați partea modificată acolo unde nu a existat. schimbări. În caz contrar, îmbinarea modificărilor se transformă într-o sarcină non-trivială, în multe cazuri necesitând intervenția dezvoltatorului. În general, mecanismul de îmbinare automată a modificărilor funcționează pe baza următoarelor principii:
În toate cazurile, versiunea de bază pentru îmbinare este versiunea în care a fost făcută împărțirea versiunilor îmbinate. Dacă aceasta este o operațiune de commit, atunci versiunea de bază va fi versiunea ultimei actualizări de dinainte de commit, dacă este actualizată, apoi versiunea actualizării anterioare, dacă sunt îmbinate ramuri, apoi versiunea în care a fost creată ramura corespunzătoare. În consecință, seturile de modificări potrivite vor fi seturile de modificări realizate de la versiunea de bază la versiunea curentă în toate variantele îmbinate.
Marea majoritate a sistemelor moderne de control al versiunilor se concentrează în primul rând pe proiecte de dezvoltare software în care tipul principal de conținut al fișierelor este textul. În consecință, mecanismele de îmbinare automată a modificărilor sunt orientate către procesarea fișierelor text, adică fișiere care conțin text format din șiruri de caractere alfanumerice, spații și file separate prin linii noi .
Atunci când se determină admisibilitatea îmbinării modificărilor în cadrul aceluiași fișier text, funcționează un mecanism tipic 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 separatoare, în cele mai multe cazuri, nu poartă o încărcare semantică, motorul de îmbinare poate ignora aceste caractere atunci când compară șiruri.
Acele seturi găsite de șiruri modificate care nu se intersectează unele cu altele sunt considerate compatibile și îmbinarea lor se face automat. Dacă există modificări în fișierele îmbinate care afectează aceeași linie a fișierului, 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 punctul de vedere al VCS și nu permit îmbinarea automată.
Situația în care, atunci când mai multe versiuni sunt îmbinate, modificările aduse acestora se intersectează între ele, se numește conflict . Dacă există un conflict de modificări, sistemul de control al versiunilor nu poate crea automat un proiect fuzionat și trebuie să contacteze dezvoltatorul. După cum s-a menționat mai sus, conflictele pot apărea în etapele de comitere a modificărilor, de actualizare sau de fuzionare a ramurilor. În toate cazurile, atunci când este detectat un conflict, operația corespunzătoare este încheiată până când este rezolvată.
Pentru a rezolva un conflict, sistemul oferă, în general, 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 special de program pentru îmbinarea modificărilor (în acest caz, opțiunile îmbinate și versiunea îmbinată a fișierului care se modifică dinamic în funcție de comenzile utilizatorului sunt afișate acolo), fie sunt pur și simplu marcate cu marcaj special direct în textul fișierului îmbinat (atunci dezvoltatorul trebuie să formeze el însuși textul dorit în locuri disputate și să-l păstreze).
Conflictele din sistemul de fișiere sunt mai ușor de rezolvat: 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 să păstreze în versiunea îmbinată .
Mecanismul de blocare permite unuia dintre dezvoltatori să preia proprietatea asupra unui fișier sau a unui 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 orice modificare necesită blocarea setului corespunzător de fișiere, se mai numește și strategia de „verificare blocată”. [3] Sistemele timpurii de control al versiunilor au susținut exclusiv această strategie, prevenind astfel apariția conflictelor din start. În VCS modern, se preferă utilizarea recuperărilor neblocante, în timp ce încuietorile sunt considerate mai degrabă un rău necesar care ar trebui limitat pe cât posibil. Dezavantajele utilizării încuietorilor sunt evidente:
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 fuziune este fundamental imposibilă (ca, de exemplu, pentru fișierele imagine). Dacă îmbinarea automată nu este posibilă, atunci, în cursul normal al activității, orice modificare paralelă a unor astfel de fișiere va duce la un conflict. Î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.
Sistemul de control al versiunilor oferă stocarea tuturor variantelor existente de fișiere și, ca urmare, a tuturor variantelor proiectului în ansamblu care au avut loc de la începutul dezvoltării acestuia. Dar însăși conceptul de „versiune” în diferite sisteme poate fi interpretat în două moduri.
Unele sisteme acceptă versiunea . Aceasta înseamnă că orice fișier care apare în proiect primește propriul său număr de versiune (de obicei numărul 1, versiunea condiționată „zero” a fișierului este un fișier gol cu același nume). De fiecare dată când un dezvoltator comite modificări care afectează un fișier, partea corespunzătoare a modificărilor comise este aplicată fișierului, iar fișierul primește un număr de versiune nou, de obicei în ordinea următoare. Deoarece commit-urile afectează de obicei doar un subset de fișiere 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 au de fapt orice „număr de versiune”, deoarece constă din multe fișiere cu numere de versiune diferite. Sistemul de control al versiunilor CVS, de exemplu, funcționează într-un mod similar.
Pentru alte sisteme, conceptul de „versiune” nu se referă la un singur fișier, ci la întregul depozit . Un depozit gol nou creat are o versiune de 1 sau 0, orice commit face ca acest număr să crească (adică, chiar dacă un fișier este modificat cu un octet, întregul depozit este considerat modificat și primește un număr nou de versiune). Numerele versiunilor sunt tratate în acest fel, de exemplu, de către sistemul Subversion. Numărul versiunii unui fișier separat nu există de fapt aici, poate fi considerat condiționat ca atare numărul versiunii curente a depozitului (adică se poate presupune 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, vorbind de „versiunea fișierului” în astfel de sisteme, se referă la versiunea depozitului în care fișierul a fost modificat ultima dată (până în momentul în care ne interesează).
În scopuri practice, de obicei nu contează un singur fișier, ci întregul proiect în ansamblu. În sistemele care acceptă versiunea fișierelor individuale, puteți utiliza data și ora pentru a identifica o anumită versiune a proiectului - apoi versiunea proiectului va consta din acele versiuni ale fișierelor incluse în el care se aflau în depozit la punctul specificat în timp. 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 modificările semnificative ale proiectului, despre cât de mult și intens au lucrat la el. Pentru a eticheta mai convenabil versiunile unui proiect (sau părți ale acestuia), sistemele de control al versiunilor acceptă conceptul de etichete .
O etichetă este o etichetă simbolică care poate fi asociată cu o anumită versiune a unui fișier și/sau director dintr-un 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 la un anumit moment în timp) pot fi atribuite o anumită etichetă. Î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 versiuni non-simultane de fișiere și directoare cu o singură etichetă. Acest lucru vă permite să construiți o „versiune a proiectului” în orice mod arbitrar. Din punctul de vedere al utilizatorului sistemului, etichetarea poate arăta diferit. În unele sisteme, este afișat exact ca un semn (o etichetă poate fi creată, aplicată anumitor versiuni de fișiere și directoare, eliminată). În alte sisteme (de exemplu, Subversion), eticheta este pur și simplu un director separat în arborele de fișiere de depozit, unde se fac copii ale versiunilor necesare ale fișierelor din trunchiul și ramurile proiectului folosind comanda copy. Deci vizual, o etichetă este doar o copie a anumitor versiuni ale fișierelor de depozit plasate într-un director separat. Prin convenție, arborele de directoare corespunzător etichetei nu are voie să comite modificări (adică versiunea proiectului reprezentată de etichetă este neschimbată).
Procedura de utilizare a sistemului de control al versiunilor în fiecare caz specific este determinată de reglementările tehnice și regulile adoptate într-o anumită companie sau organizație care dezvoltă proiectul. Cu toate acestea, principiile generale pentru utilizarea corectă a VCS sunt puține și aceleași pentru orice sistem de dezvoltare și control al versiunilor.
Cunoscut și sub numele de Sistem de control al versiunilor distribuite , DVCS. Astfel de sisteme folosesc un model distribuit în locul modelului tradițional client-server. În general, nu au nevoie de un depozit centralizat: întregul istoric al modificărilor documentelor este stocat pe fiecare computer în stocare locală și, dacă este necesar, fragmente individuale din istoricul stocării locale sunt sincronizate cu o stocare similară pe alt computer. În unele dintre aceste sisteme, stocarea locală se află direct în directoarele de copiere de lucru.
Când un utilizator al unui astfel de sistem efectuează acțiuni normale, cum ar fi verificarea unei versiuni specifice a unui document, crearea unei noi versiuni și așa mai departe, el lucrează cu copia sa locală a depozitului. Pe măsură ce se fac modificări, depozitele aparținând diferiților dezvoltatori încep să difere și devine necesară sincronizarea acestora. O astfel de sincronizare poate fi efectuată prin schimbul de corecții sau așa-numitele seturi de modificări între utilizatori .
Modelul descris este aproape logic de a crea o ramură separată pentru fiecare dezvoltator în sistemul clasic de control al versiunilor (în unele sisteme distribuite, înainte de a lucra cu stocarea locală, trebuie să creați o nouă ramură). Diferența este că până în momentul sincronizării, alți dezvoltatori ai acestei ramuri nu văd. Atâta timp cât dezvoltatorul își schimbă doar propria ramură, munca sa nu îi afectează pe alți participanți la proiect și invers. La finalizarea unei părți separate a lucrării, modificările aduse ramurilor sunt îmbinate cu ramura principală (comună). Atât la îmbinarea ramurilor, cât și la sincronizarea diferitelor depozite, sunt posibile conflicte de versiuni. În acest caz, toate sistemele oferă una sau alta metodă pentru detectarea și rezolvarea conflictelor de îmbinare.
Din punctul de vedere al utilizatorului, un sistem distribuit se distinge prin necesitatea creării unui depozit local și prezența a două comenzi suplimentare în limbajul de comandă: comanda de a primi un depozit de la un computer la distanță (pull) și de a transfera depozitul acestuia în un computer la distanță (push). Prima comandă îmbină modificările din depozitele de la distanță și cele locale și împinge rezultatul în depozitul local; al doilea, dimpotrivă, îmbină modificările celor două depozite cu rezultatul plasat într-un depozit la distanță. De regulă, comenzile de îmbinare în sistemele distribuite vă permit să alegeți ce seturi de modificări vor fi transferate sau extrase dintr-un alt depozit, să remediați conflictele de îmbinare direct în timpul operațiunii sau după ce aceasta eșuează, să încercați din nou sau să reluați o îmbinare neterminată. De obicei, trimiterea modificărilor dvs. în depozitul altcuiva (push) reușește numai dacă nu există conflicte. Dacă apar conflicte, utilizatorul trebuie mai întâi să îmbine versiunile în depozitul său (efectuează o tragere) și abia apoi să le transfere altora.
În general, este recomandat să organizați lucrul cu sistemul în așa fel încât utilizatorii să se îmbină întotdeauna sau predominant în propriul depozit. Adică, spre deosebire de sistemele centralizate, în care utilizatorii își transferă modificările pe un server central atunci când consideră de cuviință, în sistemele distribuite, este mai firesc să fuzioneze versiunile de către cel care trebuie să obțină rezultatul (de exemplu, un dezvoltator care gestionează o build). server).
Principalele avantaje ale sistemelor distribuite sunt flexibilitatea lor și autonomia mult mai mare (comparativ cu sistemele centralizate) a unui loc de muncă individual. Computerul fiecărui dezvoltator este, de fapt, un server independent și cu funcții complete, de pe astfel de computere este posibil să se construiască un sistem arbitrar ca structură și complexitate, stabilind (atât măsuri tehnice, cât și administrative) ordinea de sincronizare dorită. În același timp, fiecare dezvoltator poate lucra independent, într-un mod convenabil pentru el, schimbând și salvând versiuni intermediare ale documentelor, folosind toate caracteristicile sistemului (inclusiv accesul la istoricul modificărilor) chiar și în absența unui conexiune la rețea la server. Comunicarea cu serverul sau cu alți dezvoltatori este necesară numai pentru sincronizare, în timp ce schimbul de seturi de modificări poate fi efectuat conform diferitelor scheme.
Dezavantajele sistemelor distribuite includ o creștere a cantității necesare de memorie pe disc: fiecare computer trebuie să stocheze un istoric complet al versiunilor, în timp ce într-un sistem centralizat, doar o copie de lucru este de obicei stocată pe computerul dezvoltatorului, adică o felie de depozitul la un moment dat și modificările efectuate. Un dezavantaj mai puțin evident, dar enervant, este că este aproape imposibil să implementezi o parte din funcționalitățile oferite de sistemele centralizate într-un sistem distribuit. Aceasta:
Putem distinge următoarele situații tipice în care utilizarea unui sistem distribuit oferă avantaje notabile:
În dezvoltarea de proiecte tradiționale „de birou”, atunci când un grup de dezvoltatori este relativ mic și se află în întregime pe același teritoriu, în cadrul unei singure rețele locale de calculatoare, cu servere disponibile în mod constant, un sistem centralizat poate fi cea mai bună alegere datorită structurii sale mai rigide. și prezența unei funcționalități care lipsesc în sistemele distribuite (de exemplu, lacătul deja menționat). Capacitatea de a efectua modificări fără a le îmbina în ramura centrală în astfel de condiții este ușor de implementat prin separarea lucrărilor în curs în ramuri de dezvoltare separate.
Nu există o terminologie general acceptată; sisteme diferite pot folosi nume diferite pentru aceleași acțiuni. Mai jos sunt câteva dintre opțiunile cele mai frecvent utilizate. Sunt dați termeni englezi, în literatura rusă se folosește una sau alta traducere sau transliterație .
modifica Faceți modificări fără a crea o nouă versiune - de obicei atunci când dezvoltatorul a comis ( commit ) din greșeală versiunea, dar nu a încărcat-o (pus ) pe server. vina Aflați cine a făcut schimbarea. ramură O ramură este o direcție de dezvoltare independentă de ceilalți. O ramură este o copie a unei părți (de obicei un director) a depozitului, în care vă puteți face propriile modificări fără a afecta alte ramuri. Documentele din ramuri diferite au același istoric înainte de punctul de ramificare și istoric diferit după acesta. set de modificări, listă de modificări, activitate Set de modificări. Reprezintă un set numit de modificări făcute unei copii locale pentru un scop comun. Pe sistemele care acceptă seturi de modificări, dezvoltatorul poate organiza modificările locale în grupuri și poate efectua modificări legate logic într-o singură comandă, specificând setul de modificări necesar ca parametru. În acest caz, celelalte editări vor rămâne neremediate. Un exemplu tipic: se lucrează la adăugarea de noi funcționalități și în acel moment este descoperit un bug critic care trebuie remediat imediat. Dezvoltatorul creează un set de modificări pentru munca deja efectuată și una nouă pentru remedieri. La finalizarea corectării erorii, se dă comanda de a efectua doar al doilea set de modificări. check-in, comite, trimite Creați o versiune nouă, efectuați modificări. În unele SUV-uri ( Subversion ) - noua versiune este transferată automat în depozitul de documente. check-out, clonare Preluați un document din stocare și creați o copie de lucru. conflict Un conflict este o situație în care mai mulți utilizatori au făcut modificări aceleiași secțiuni a unui document. Un conflict este detectat atunci când un utilizator și-a comis modificările, iar al doilea încearcă să comite, iar sistemul în sine nu poate îmbina corect modificările aflate în conflict. Deoarece este posibil ca programul să nu fie suficient de inteligent pentru a determina care modificare este „corectă”, al doilea utilizator trebuie să rezolve el însuși conflictul ( rezolvare ). grefă, backport, cherry-pick, transplant Utilizați algoritmul de îmbinare încorporat în VMS pentru a împinge modificări individuale într-o altă ramură fără a le îmbina. De exemplu, am remediat o eroare în ramura experimentală - facem aceleași modificări la trunchiul stabil. cap, trunchi Versiunea majoră este cea mai recentă versiune pentru ramura/trunchiul care se află în depozit. Câte ramuri, atâtea versiuni majore. fuziune, integrare O îmbinare este o combinație de modificări independente într-o singură versiune a unui document. S-a întâmplat când două persoane au schimbat același fișier sau când se mută modificări de la o ramură la alta. trage, actualizează Obțineți versiuni noi din depozit. În unele SUV-uri ( Subversion ) - apar atât tragerea , cât și comutarea , adică modificările sunt încărcate, iar apoi copia de lucru este adusă la ultima stare. Fiți atenți , actualizarea este ambiguă și înseamnă lucruri diferite în Subversion și Mercurial . Apăsaţi Încărcați versiuni noi în depozit. Multe VCS-uri distribuite ( Git , Mercurial ) presupun că un commit trebuie dat de fiecare dată când programatorul a executat o funcție finalizată. Și completați - când există Internet și alții doresc modificările dvs. Commit de obicei nu necesită un nume de utilizator și o parolă, dar push o face. rebaza Utilizați algoritmul de îmbinare încorporat în VMS pentru a muta punctul de ramificare (versiunea de la care începe ramificația) la o versiune ulterioară a trunchiului. Cel mai des folosit în acest scenariu: Boris a făcut modificări și constată că nu le poate împinge , deoarece Anna a schimbat anterior un loc complet diferit în cod. Puteți pur și simplu să le îmbinați ( merge ). Dar arborele va fi liniar și mai ușor de citit dacă abandonați revizuirea, dar faceți aceleași modificări la revizuirea Annei - aceasta este rebase . Dacă Anna și Boris lucrează la aceeași bucată de cod, interferând unul cu celălalt și rezolvând manual conflictele, nu se recomandă rebase . depozit, depozit Depozitul de documente este locul în care sistemul de control al versiunilor stochează toate documentele împreună cu istoricul modificărilor acestora și alte informații de serviciu. revizuire Versiunea documentului. Sistemele de control al versiunilor disting versiunile prin numere, care sunt atribuite automat. raft, depozit Amânarea modificărilor. Capacitatea oferită de unele sisteme de a crea un set de modificări (set de modificări) și de a-l salva pe server fără comitere (commit'a). Un set de modificări de backlog este citit de alți membri ai proiectului, dar nu este inclus în ramura principală până la o comandă specială. Amânarea suportului permite utilizatorilor să salveze lucrările în curs de desfășurare pe server fără a crea ramuri separate pentru aceasta. suc de fructe Modul de altoit/cireș pentru toată ramura. Cu alte cuvinte, întreaga sucursală este angajată ca o singură schimbare. Util pentru modificări suficient de mari pentru a dura câteva zile pentru a fi finalizate și suficient de mici pentru a nu păstra un istoric complet al acestora. etapă Alegeți ce modificări să faceți ( commit ) și pe care să le păstrați private sau să le faceți mai târziu. bandă Ștergeți o întreagă ramură din depozit. etichetă, etichetă O etichetă care poate fi atribuită unei anumite versiuni a unui document. O etichetă este un nume simbolic pentru un grup de documente, iar eticheta descrie nu numai un set de nume de fișiere, ci și versiunea fiecărui fișier. Versiunile documentelor incluse în etichetă pot aparține unor momente diferite în timp. portbagaj, linie principală, stăpân Trunchiul este ramura principală a dezvoltării proiectului. Politica trunchiului poate diferi de la proiect la proiect, dar, în general, este după cum urmează: majoritatea modificărilor se fac trunchiului; dacă este necesară o schimbare majoră care ar putea duce la instabilitate, se creează o ramură care se contopește cu trunchiul atunci când inovația a fost suficient testată; înainte de lansarea versiunii următoare, se creează o ramură pentru lansarea ulterioară, în care se fac doar corecții. actualizați, sincronizați, comutați Sincronizarea copiei de lucru cu o anumită stare de stocare specificată. Cel mai adesea, această acțiune înseamnă actualizarea copiei de lucru la cea mai recentă stare a seifului. Cu toate acestea, dacă este necesar, puteți sincroniza copia de lucru la o stare mai veche decât cea actuală. copie de lucru Copie de lucru (locală) a documentelor.| Sisteme de control al versiunilor ( categorie ) | |
|---|---|
| Doar local | |
| Client server | |
| Distribuit | |