CVS acceptă istoricul arborelui directorului sursă, care lucrează cu o serie de modificări. CVS marchează fiecare modificare în momentul în care a fost făcută și numele utilizatorului care a efectuat modificarea. De obicei, persoana care a făcut schimbarea oferă și o descriere textuală a motivului schimbării. Înarmat cu toate aceste informații, CVS poate răspunde la întrebări, cum ar fi
- Cine a făcut schimbarea?
- Când au făcut-o?
- De ce au făcut asta?
- Ce alte schimbări au avut loc în același timp?
Înainte de a discuta o mulțime de termeni și idei diferite, să aruncăm o privire asupra principalelor comenzi CVS.
CVS stochează toate modificările din acest proiect în arborele de directoare, numite repository. Înainte de a începe să utilizați CVS, trebuie să configurați variabila de mediu CVSROOT pentru a indica directorul repozitoriu. Persoana responsabilă cu gestionarea configurației proiectului dvs. știe probabil exact ce ar trebui să conțină această variabilă; este posibil ca variabila CVSROOT să fie deja instalată la nivel global.
În orice caz, în sistemul nostru depozitul este situat în `/ usr / src / master '. În acest caz, trebuie să introduceți comenzi
`setenv CVSROOT / usr / src / master '
dacă cochilia dvs. este csh sau este provocată de ea, sau
`CVSROOT = / usr / src / master export CVSROOT '
dacă e Bash sau altă variantă a cochiliei Bourne.
Dacă uitați să faceți acest lucru, CVS se va plânge dacă încercați să o porniți:
CVS nu poate funcționa într-un arbore de directoare obișnuit; dimpotrivă, trebuie să lucrați în directorul pe care CVS îl va crea pentru dvs. Așa cum scrieți o carte din bibliotecă înainte să o luați cu dvs., ar trebui să utilizați comanda `cvs checkout '. pentru a obține arborele de directoare de lucru din CVS. Să presupunem, de exemplu, că lucrați la un proiect numit `httpc '. client HTV trivial:
Comanda "cvs checkout httpc" înseamnă "Extrage arborele sursă cu numele" httpc "din depozitul specificat în variabila de mediu" CVSROOT "".
CVS pune copacul în subdirectorul `httpc '.
Majoritatea acestor fișiere lucrează la copii ale codului sursă "httpc". Cu toate acestea, subdirectorul numit "CVS" (primul) are un scop diferit. CVS îl folosește pentru a stoca informații suplimentare despre fiecare fișier din acest director pentru a determina ce modificări le-ați făcut de când au fost extrase din depozit.
Odată ce CVS a creat un copac director de lucru, puteți edita în mod obișnuit, compila și testați fișierele în ea - este doar un fișier.
De exemplu, să presupunem că dorim să compilam un proiect pe care tocmai l-am extras:
Se pare că "httpc.c" nu a fost încă transferat în acest sistem de operare. Trebuie să aruncăm tipuri pentru unul dintre argumentele funcției de conectare. Pentru a face acest lucru, trebuie să schimbați linia 48, înlocuind-o
Compilația trebuie să reușească:
. Iată textul paginii de pornire a Software-ului Cyclic.
Deoarece fiecare dezvoltator utilizează propriul director de lucru, modificările pe care le faceți în directoarele dvs. nu devin automat vizibile pentru toți ceilalți membri ai echipei dvs. CVS nu publică modificări până când nu sunt finalizate. Când testați modificările, trebuie să le angajați în depozit și să le puneți la dispoziția celorlalți. Vom descrie comanda cvs commit mai departe.
Cu toate acestea, dacă un alt dezvoltator a schimbat același fișier ca și dvs. și poate chiar a schimbat aceleași rânduri? Care alegeri vor fi folosite? De obicei este imposibil să răspundem la această întrebare, iar CVS este absolut incompetent să ia astfel de decizii.
Prin urmare, înainte de a vă înregistra modificările, CVS cere ca codul sursă să fie sincronizat cu toate modificările efectuate de ceilalți membri ai grupului. Comanda de actualizare cvs se va ocupa de aceasta:
Deoarece CVS a combinat modificările altcuiva cu codul dvs. sursă, trebuie să vă asigurați că aceștia încă lucrează:
Acum că ați sincronizat sursele cu colegii și le-ați testat, sunteți gata să vă aduceți modificările în depozit și să le faceți vizibile celorlalți dezvoltatori. Singurul fișier pe care l-ați modificat este `httpc.c '. dar, în orice caz, puteți rula în condiții de siguranță cvs actualizare. pentru a obține o listă de fișiere modificate din CVS:
După cum era de așteptat, singurul fișier care menționează CVS este "httpc.c"; CVS spune că acest fișier conține modificări care nu au fost încă angajate. Le puteți rezolva astfel:
Rețineți că acum v-ați înregistrat modificările și că acestea sunt vizibile pentru toți ceilalți membri ai grupului. Când un alt dezvoltator execută actualizarea CV-ului. CVS va face modificările fișierelor în directorul său de lucru.
Acum, poate doriți să știți ce modificări a făcut celălalt dezvoltator în fișierul `httpc.c '. Pentru a vedea intrările de jurnal pentru acest fișier, puteți folosi comanda jurnal cvs.
Majoritatea textului pe care îl puteți ignora; Ar trebui să acordați atenție numai unei serii de intrări în jurnal după prima linie de liniuțe. Fișele de înregistrări sunt afișate în ordine inversă cronologică, pe baza presupunerii că modificările recente sunt de obicei mai interesante. Fiecare intrare descrie o modificare a fișierului și poate fi analizată în părțile componente după cum urmează:
Înainte de a analiza ce ne-a oferit această echipă, vom descrie ceea ce înseamnă fiecare parte.
-c Specifică utilizarea unui format lizibil pentru emiterea modificărilor. (Mă întreb de ce acest lucru nu este implicit) (1). -r 1.6 -r 1.7 Specifică CVS că este necesară emiterea modificărilor necesare pentru a transforma revizuirea 1.6 în revizuirea 1.7. Puteți solicita o gamă mai largă de modificări; de exemplu, -r 1.6-r 1.8 afișează modificările făcute de Fred și modificările pe care le-ai făcut mai târziu. (De asemenea, puteți comanda modificări în ordine inversă, ca și cum ar fi fost anulate - indicând numerele de revizie în ordine inversă: -r 1.7 -r 1.6. Sună ciudat, dar uneori util.) Httpc.c Numele fișierului care urmează a fi procesat . Dacă nu specificați, CVS va raporta întregul director.
Iată ce se va întoarce această comandă:
Este nevoie de ceva efort pentru a vă obișnuiți cu o astfel de prezentare, dar merită cu siguranță (2).
O informație interesantă începe cu primele două linii care încep cu *** și ---; descriu vechile și cele noi fișiere care trebuie comparate. Restul constă din două felii (bucată), fiecare dintre acestea începând cu un șir de asteriscuri. Aici este primul "hunk":
Aici este al doilea "hunk":
Aici descriem adăugarea a două linii, care este indicată de simbolurile "+". CVS nu emite textul vechi - ar fi redundant. Un format similar este folosit pentru a descrie rândurile șterse.
Ca și ieșirea comenzii diff. ieșirea comenzii cvs diff este denumită de obicei un patch, deoarece dezvoltatorii au folosit în mod tradițional acest format pentru a distribui patch-uri și caracteristici noi. Patch-ul este suficient de citit și conține suficiente informații pentru a aplica modificările pe care le conține în fișierul text. De fapt, comanda de patch-uri într-un mediu UNIX face doar cu patch-uri.
CVS tratează adăugarea și ștergerea fișierelor în același mod ca și cu alte modificări, înregistrând astfel de evenimente în istoricul fișierelor. Puteți să vă uitați la ea ca și când CVS stochează istoricul directorului împreună cu istoricul fișierelor.
CVS nu consideră că fișierele create ar trebui să fie sub controlul său; nu este așa în multe cazuri. De exemplu, nu este necesar să înregistrați istoricul modificărilor în fișierele obiect și executabile, deoarece conținutul lor poate fi întotdeauna recreat din fișierele sursă (sperăm). În schimb, atunci când creați un fișier nou, actualizarea cvs marchează acest fișier cu `. ", până când îi spui CVS exact ce intenționezi să faci cu acest dosar.
Pentru a adăuga un fișier la proiect, trebuie mai întâi să îl creați, apoi să utilizați comanda cvs add. pentru al marca ca adăugat. Apoi, data viitoare când executați comanda cvs commit, CVS va adăuga acel fișier în depozit. De exemplu, iată cum puteți adăuga un fișier README la proiectul httpc:
CVS tratează fișierele la distanță aproape în același mod. Dacă ștergeți fișierul și executați `update cvs '. CVS nu consideră că intenționați să ștergeți un fișier din proiect. În schimb, acționează mai multă milă - restabilește ultima versiune a fișierului stocat în depozit și o marchează cu steagul U., la fel ca orice altă actualizare. (Aceasta înseamnă că, dacă doriți să anulați modificările la un director de lucru, puteți să îl ștergeți pur și să permiteți comanda `cvs update 'să îl creați din nou.)
Pentru a șterge un fișier din proiect, trebuie mai întâi să îl ștergeți și apoi să utilizați comanda `cvs rm '. pentru ao marca pentru ștergere. La următorul start, comanda `cvs commit 'va șterge fișierul din depozit.
Fixarea unui fișier marcat cu `cvs rm 'nu distruge istoricul acestui fișier - pur și simplu adaugă încă o revizie ---" nu există ". Depozitul stochează încă toate înregistrările despre acest fișier și poate fi accesat la alegere - de exemplu, utilizând "cvs diff" sau "cvs log".
Există mai multe strategii pentru redenumirea unui fișier; Cea mai ușoară cale este să redenumiți fișierul în directorul de lucru, apoi să executați `cvs rm 'cu numele vechi și` cvs add' cu cel nou. Dezavantajul acestei abordări este faptul că înregistrările din jurnal despre conținutul fișierului vechi nu sunt transferate într-un fișier nou. Alte strategii pot evita acest lucru, dar pot produce alte probleme mai bizare.
Puteți adăuga directoare ca fișierele obișnuite.
Așa cum am menționat, comanda `cvs update 'combină modificările făcute de alți dezvoltatori cu codul sursă în directorul dvs. de lucru. Dacă ați editat fișierul în același timp cu altcineva, CVS va fuziona modificările.
Destul de ușor de imaginat cum funcționează atunci când au fost efectuate modificări în diferite părți ale fișierului, dar ce se întâmplă dacă amândoi s-au schimbat aceeași linie? CVS numește această situație un conflict și vă permite să vă ocupați singur de ea.
În acest caz, un alt dezvoltator a schimbat aceeași secțiune a fișierului ca și dvs., deci CVS se plânge de conflict. În loc să tastați M httpc.c. așa cum se întâmplă de obicei, CVS imprimă C httpc.c. ceea ce înseamnă că există un conflict în acest dosar.
Când decideți cum să rezolvați conflictul, eliminați marcatorii din cod și editați-l. În acest caz, deoarece manipularea erorilor este cu siguranță mai bună, atunci abandonați opțiunea celuilalt, lăsând următorul cod:
Acum, testați modificările și remediați-le:
Este important să înțelegeți ce CVS consideră un conflict. CVS nu înțelege semantica programului dvs., tratează codul sursă doar ca un arbore al fișierelor text. În cazul în care un dezvoltator adaugă un nou argument pentru o funcție și stabilește apelanții sale, în timp ce un alt dezvoltator adaugă în același timp un nou apel la această funcție, și nu trece noul argument, care este cu siguranță un conflict - cele două modificări sunt incompatibile - dar CVS nu va raporta. Înțelegerea lui despre conflicte este strict textuală.
În practică, însă, conflictele sunt rare. Ele apar, de obicei, pentru că doi oameni încearcă să facă față cu aceeași problemă a lipsei de interacțiune între dezvoltatori, sau dezacordul cu privire la proiectarea programului. Distribuirea corectă a sarcinilor între dezvoltatori reduce probabilitatea conflictelor.
Multe sisteme de control al versiunilor permit unui dezvoltator să blocheze un fișier, împiedicând modificările fișierului până când propriile modificări sunt reparate. În ciuda faptului că încuietori sunt adecvate în anumite situații, aceasta nu este întotdeauna o abordare mai bună decât abordarea CVS. Modificările sunt de obicei combinate fără probleme, iar dezvoltatorii uită uneori să elimine blocarea, în ambele cazuri blocarea explicită conduce la întârzieri inutile. Mai mult decât atât, încuietori împiedică doar conflictele textuale - ei nu pot face nimic cu conflicte semantice de tipul celor descrise mai sus - atunci când doi dezvoltatori edita fișiere diferite.
Mă întreb de ce nu-i deloc. Aproximativ Trans.
Este mai bine să utilizați -u. Aproximativ Trans.
Articole similare
Trimiteți-le prietenilor: