Dacă aveți comentarii sau sugestii despre acest document, le puteți scrie în comentarii.
Startegiya 1
Această strategie este simplificată și poate fi aplicată în echipe mici de dezvoltatori. Cu toate acestea, este preferabil să se utilizeze strategia 2, pe cât de mult acesta satisface pe deplin cerința ca versiunea stabilă a proiectului nu ar trebui să fie expus la destabilizarea modificărilor. SVN vă permite să migreze cu ușurință de la o strategie la alta, va fi necesar pentru a aproba o serie de noi cerințe de modificare a magaziei.
Structura depozitului
Director / trunchi - ramura principală de dezvoltare a proiectului. Ea a făcut toate modificările și remedieri de erori.
Director / tag-uri conțin de presă ale proiectului. Este din cauza subdirectoare cod director / tag-uri sursă este pus pe un server de producție.
Director / sucursale necesare pentru a simplifica introducerea unor schimbări majore în codul proiectului. Acesta stochează ramura de dezvoltare. În cazul în care o persoană care dezvoltă o caracteristică de mare, acesta trebuie să creeze un brunch și din când în când sincronizarea cu trunchiul. La sfârșitul acestei dezvoltări are brunch fuzionează cu trunchiul și îndepărtate.
Deci, / trunchi - ramura principală a dezvoltării sistemului. Lansări sunt create pe baza conținutului de directorul / trunchi. Crearea de presă bazate pe un brunch în acest caz, nu este recomandată.
Acordul privind emisiile și ramuri de dezvoltare
Numărul de eliberare este format din trei cifre separate printr-un punct. Pentru comoditatea descrierii Denotă ca X.Y.Z.
Prima cifră X este responsabil pentru schimbările globale în cadrul proiectului. Aceasta crește atunci când proiectul se duce la un nou nivel, de exemplu, o schimbare completă a sistemului de proiectare sau a motorului (în cazul în care se află în același depozit).
Numărul Y este responsabil pentru adăugarea de noi caracteristici și bug-uri de fixare, adică, numărul Y este mărit prin adăugarea de noi caracteristici, vizibile la nivelul utilizatorului final. Permiteți-mi să explic cu o corectare a erorilor de - la prima vedere poate părea că pentru corectarea erorilor trebuie să le îndeplinească numărul Z, dar nu este. De exemplu, în presă 1.2.3 mai multe bug-uri fixe, le-a turnat în / portbagaj. Și după un timp a lansat o nouă versiune 1.3.0, cu caracteristici de făcut, iar aceste remedieri de erori, și anume remedieri de erori „automate“ fuzionat la Y, atunci când o nouă versiune a / trunchi.
Z - fixarea bug-uri, ceea ce face corecturi minore (de exemplu, modificări de design mici).
EXEMPLUL 1
Versiunea curentă: 1.2.4.
Sarcina: Este necesar pentru a rectifica o serie de mici erori, văzut de la lansare.
Acțiuni: Efectuarea de modificări în / portbagaj. Crearea unei /tags/1.2.5/ de eliberare de stabilizare. Am răspândit.
EXEMPLUL 2
versiunea curentă: 1.2.4
Sarcina: Este necesar să se dezvolte o caracteristică suplimentară, executarea sarcinii va dura de la câteva zile la câteva săptămâni.
Acțiune: Crearea brunch /branches/1.3.0/. Noi lucrăm în brunch. De mai multe ori pe saptamana sincronizarea cu / trunchi pentru a menține relevanța brunch și brunch simplifică fuziune ulterioară cu trunchiul. La sfârșitul dezvoltării Brunch sincronizate cu trunchiul. Testat. Dacă totul este în regulă, modificările sunt exprimate în portbagaj. Brunch este eliminat. Pe baza eliberării trunchiului se face /tags/1.3.0/.
EXEMPLUL 3
versiunea curentă: 1.2.4
Sarcina: Este necesar să se dezvolte mai multe (chiar și două) de caracteristici suplimentare, executarea sarcinii va dura de la câteva zile la câteva săptămâni.
Acțiune: Crearea și /branches/1.3.1 brunch /branches/1.3.0. Lucrând în mod independent în diferite brunch. De mai multe ori pe săptămână brunch sunt sincronizate cu trunchiul, în scopul de a menține relevanța brunch și pentru a simplifica Brunch fuziune ulterioară cu trunchiul. La sfârșitul Gustările de dezvoltare la rândul său, este sincronizat cu trunchiul. Rezultatul este testat. Dacă totul este în regulă, modificările sunt inundate în / portbagaj. Brunch eliminate. Pe baza eliberării trunchiului se face /tags/1.3.0/.
Startegiya 2
Structura depozitului
Director / trunchi - ramura principală de dezvoltare a proiectului. Ea a făcut toate modificările și remedieri de erori.
Director / tag-uri conțin de presă ale proiectului. Este din cauza subdirectoare cod director / tag-uri sursă este pus pe un server de producție.
Director / sucursale necesare pentru a simplifica introducerea unor schimbări majore în codul proiectului, precum și corecții la versiunea curentă a proiectului.
Acordul de lansare
Numărul de eliberare este format din trei cifre separate printr-un punct. Pentru comoditatea descrierii Denotă ca X.Y.Z.
Prima cifră X este responsabil pentru schimbările globale în cadrul proiectului. Aceasta crește atunci când proiectul se duce la un nou nivel, de exemplu, o schimbare completă a sistemului de proiectare sau a motorului (în cazul în care se află în același depozit).
Numărul Y este responsabil pentru adăugarea de noi caracteristici și bug-uri de fixare, adică, numărul Y este mărit prin adăugarea de noi caracteristici, vizibile la nivelul utilizatorului final. Permiteți-mi să explic cu o corectare a erorilor de - la prima vedere poate părea că pentru corectarea erorilor trebuie să le îndeplinească numărul Z, dar nu este. De exemplu, în eliberarea 1.2.3 (de fapt, sunt aduse modificări la brunch /branches/1.2-stable) fixat câteva bug-uri, le-a turnat în / portbagaj. Și după un timp a lansat o nouă versiune 1.3.0, cu caracteristici de făcut, iar aceste remedieri de erori, și anume remedieri de erori „automate“ fuzionat la Y, atunci când o nouă versiune a / trunchi.
Z - fixarea bug-uri, ceea ce face corecturi minore (de exemplu, modificări de design mici).
Acordul privind ramurile de dezvoltare
ramura de dezvoltare poate fi de două tipuri în funcție de ramura de destinație.
Primul Variantei - ramura pentru modificări semnificative (de tip număr 0.1.0, 0.2.0, etc). În cazul în care o persoană care dezvoltă o caracteristică de mare, acesta trebuie să creeze un brunch și din când în când sincroniza cu / trunchi. La sfârșitul acestei dezvoltări are brunch fuzionează cu / trunchi și îndepărtate. În continuare, vom numi aceste ramuri sunt temporare.
În cazul în care filiala este temporară, numele său va fi format din trei cifre - X.Y.Z. Numărul Y ar trebui să fie una mai mare decât numărul de lansări. Aceasta este, în cazul în care versiunea curentă este versiunea 1.2.4, este necesar să se creeze o sucursală cu numărul 1.3.0.
A doua opțiune - ramurile de presă, răspândite pe un server de lucru corespunzătoare (numere de forma 0.1-stabil, 0,2-stabil). Aceste ramuri sunt necesare pentru a corecta erorile în versiunea curentă. Pe baza acestor ramuri sunt create de presă de stabilizare. Această ramură de presă. ramuri non-eliberare au o structură diferită --X.Y stabil.
EXEMPLUL 3
Context: versiunea curentă este 1.0.1.
Sarcina: de a dezvolta o nouă caracteristică pentru timpii de implementare a proiectului pe parcursul unei săptămâni.
acţiuni:
Crearea brunch /branches/1.2.0
Toate modificările privind noile caracteristici introduse în această ramură.
Filiala sincronizate sistematic / trunchi pentru a menține relevanța ramurilor.
După finalizarea lucrărilor pe o ramură caracteristică fuzionează cu / trunchi.
/ Trunk este testată.
Dacă totul este în ordine, apoi brunch /branches/1.2.0 îndepărtat.
Pe baza / trunchi creează un nou /tags/1.2.0 de presă
Pe baza /tags/1.2.0 create cu eliberare /branches/1.2-stable Brunch
/tags/1.2.0 pus pe serverul de producție
/ Trunk - ramura principală a dezvoltării sistemului.
Lansări se bazează pe ramuri /branches/x.x-stable.
Trebuie remarcat faptul că, atunci când ieșirea 1.2.0 de eliberare nu este necesară pentru a sprijini /branches/0.1-stable brunch. Această ramură poate fi îndepărtată.
A doua strategie este mai sigură, dar utilizarea sa atrage după sine derazht întotdeauna la îndemână două copii de lucru ale proiectului - lansarea Brunch si portbagaj. De asemenea, este nevoie de un efort pentru a menține aceste versiuni sincronizate (în termeni de corectare a erorilor). Prima strategie este mai simplă și nu necesită abilități speciale de management depozit, și, probabil, mai potrivite în etapa inițială de a utiliza echipe SVN sau dezvoltare mică.