Hogyan működik a svn, blog web programozás

Hogyan működik a svn, blog web programozás
A cél az írás -, hogy fontolja meg néhány lehetséges stratégiákat az SVN használata adattár létrehozásakor web-projekt. Az adattár kell felelniük az alapvető követelmény - a stabil verzió a projekt nem szabad kitenni a destabilizáló változásokat. Más esetben, amikor a tároló egy Execu egyszerű fájl tárolására, nem veszik figyelembe, mert a puszta egyszerűség. Sőt, nem felel meg az alapvető követelményeket a tárolóból.
Ha megjegyzése vagy javaslata van ezzel a dokumentummal, akkor írj nekik a megjegyzéseket.

Startegiya 1

Ez a stratégia az egyszerűsített és lehet alkalmazni a kis csapat a fejlesztők. Azonban célszerű használni a stratégia 2, mennyibe teljesen megfelel az a követelmény, hogy a stabil verzió a projekt nem szabad kitenni a destabilizáló változásokat. SVN segítségével könnyedén vándorolnak egyik stratégia a másikra, akkor jóvá kell hagyni egy sor új követelmények módosítását a tárolóba.

A szerkezet a lerakat

Directory / trunk - a fő ága a projekt fejlesztése. Ez tette minden változás és hibajavítások.
Directory / címkéi kiadások a projekt. Ez azért van, mert az alkönyvtárak könyvtár / címkék forráskód lefektetett éles kiszolgálón.
Directory / ágak szükséges egyszerűsíteni a bevezetése jelentős változások a projekt kódot. Ez tárolja a fejlesztési ág. Ha az ember fejlődik egy nagyszerű funkció, akkor létre kell hozni egy brunch és időről időre szinkronizálja a csomagtartóba. Végén ez a fejlődés jellemzői villásreggeli összeolvad a törzsön és eltávolítjuk.

Tehát / trunk - a fő ága a rendszer fejlesztése. Kibocsátások alapján létrehozott a könyvtár tartalmát / trunk. Készítsen kibocsátások alapján egy brunch ebben az esetben nem ajánlott.

Megállapodás a kibocsátások és a fejlesztési ágak

kibocsátási szám három számjegy ponttal elválasztva. A leírás egyszerűsítése érdekében jelöljük, mint X.Y.Z.

Az első számjegy X felelős a globális változások a projektben. Ez növeli a projekt megy egy új szintre, például egy teljes változást a tervezés vagy a rendszer a motor (ha található ugyanabban adattár).

A szám Y felelős új funkciókat és kijavítani a hibákat, ez a szám Y oly módon növeljük az új funkciókat, észrevehető, hogy a végfelhasználó szintjén. Hadd magyarázzam egy hibajavítást - első pillantásra úgy tűnhet, hogy a hibák kijavítását meg kell felelnie a Z szám, de ez nem az. Például a felszabadulás 1.2.3 fix néhány hibát, öntötte őket / trunk. És egy idő után megjelent az új verzió 1.3.0 funkciók történik, és ezek a hibajavításokat, azaz hibajavítások „automatikus” fuzionált Y, ha egy új kiadás / trunk.

Z - kijavítani a hibákat, így kisebb korrekciók (pl kis design változás).

1. példa
Aktuális kiadás: 1.2.4.
Feladat: Meg kell orvosolni számos kis hiba, láttam, mivel a kibocsátás.
Hozzászólások: Making változások / trunk. Hozzon létre egy stabilizáló kiadás /tags/1.2.5/. Kenjük.

2. példa
Aktuális kiadás: 1.2.4
Feladat: Meg kell fejleszteni egy további jellemzője, a feladat végrehajtását vesz néhány naptól néhány hétig.
Művelet: Hozzon brunch /branches/1.3.0/. Dolgozunk a villásreggeli. Hetente többször szinkronizál / trunk fenntartani a jelentősége a brunch és büféebéd egyszerűsítése későbbi egyesülés a csomagtartóba. A végén a fejlesztési Brunch szinkronban a csomagtartóban. Tesztelt. Ha minden rendben van, a változások vannak öntve a csomagtartóban. Brunch eltávolítjuk. Alapján a törzs kiadás készül /tags/1.3.0/.

3. példa
Aktuális kiadás: 1.2.4
Feladat: Meg kell fejleszteni több (akár kettő) kiegészítő funkciók, a feladat végrehajtását vesz néhány naptól néhány hétig.
Művelet: létrehozása és brunch /branches/1.3.0 /branches/1.3.1. Önállóan működő különböző brunch. Hetente többször brunches szinkronban vannak a törzs fenntartása érdekében relevanciájának brunches és egyszerűsíti a későbbi egyesülés Brunch a csomagtartóban. A végén a fejlesztési brunches viszont szinkronban van a csomagtartóban. Eredmény vizsgáljuk. Ha minden rendben van, a változások elöntött / trunk. Brunch eltávolítjuk. Alapján a törzs kiadás készül /tags/1.3.0/.

Startegiya 2

A szerkezet a lerakat

Directory / trunk - a fő ága a projekt fejlesztése. Ez tette minden változás és hibajavítások.
Directory / címkéi kiadások a projekt. Ez azért van, mert az alkönyvtárak könyvtár / címkék forráskód lefektetett éles kiszolgálón.
Directory / ágak szükséges egyszerűsíteni a bevezetése jelentős változások a projekt kódja, valamint javításokat a jelenlegi verzió a projekt.

A Release megállapodás

kibocsátási szám három számjegy ponttal elválasztva. A leírás egyszerűsítése érdekében jelöljük, mint X.Y.Z.

Az első számjegy X felelős a globális változások a projektben. Ez növeli a projekt megy egy új szintre, például egy teljes változást a tervezés vagy a rendszer a motor (ha található ugyanabban adattár).

A szám Y felelős új funkciókat és kijavítani a hibákat, ez a szám Y oly módon növeljük az új funkciókat, észrevehető, hogy a végfelhasználó szintjén. Hadd magyarázzam egy hibajavítást - első pillantásra úgy tűnhet, hogy a hibák kijavítását meg kell felelnie a Z szám, de ez nem az. Például a felszabadulás 1.2.3 (valójában változások történtek a villásreggeli /branches/1.2-stable) rögzített néhány hibát, öntötte őket / trunk. És egy idő után megjelent az új verzió 1.3.0 funkciók történik, és ezek a hibajavításokat, azaz hibajavítások „automatikus” fuzionált Y, ha egy új kiadás / trunk.

Z - kijavítani a hibákat, így kisebb korrekciók (pl kis design változás).

Megállapodás fejlesztési ágak

A fejlesztési ág lehet a két típus a rendeltetési helytől függően ág.
Első kiviteli - ága jelentős változás (típusszám 0.1.0, 0.2.0, stb.) Ha az ember fejlődik egy nagyszerű funkció, akkor létre kell hozni egy brunch és időről időre szinkronizálni / trunk. Végén ez a fejlődés jellemzői brunch összeolvad / trunk és eltávolítjuk. Ezután meg kell hívni az ilyen fióktelepek átmeneti.
Ha az ág csak átmeneti, a neve áll három számjegy - X.Y.Z. Y szám legyen az egyik nagyobb, mint a jelenlegi kiadás számát. Azaz, ha a jelenlegi verzió a 1.2.4, akkor létre kell hozni egy ágat száma 1.3.0.

A második lehetőség - az ágak megfelelő kibocsátások, elterjedt egy működő szerver (számok képeznek 0,1-stabil, 0,2-stabil). Ezek az ágak szükséges kijavítani a hibákat a jelenlegi kiadás. Alapján ezen ágazatok által létrehozott stabilizációs kiadások. Ez a kiadás ága. Nem felszabaduló ágak eltérő struktúrája - nem kezelt kontrollra vonatkoztatott-stabil.

3. példa
Háttér: A jelenlegi kiadás az 1.0.1.
A feladat: hogy dolgozzon ki egy új funkció a projekt végrehajtása során többször egy héten.
tevékenységek:
Készítsen brunch /branches/1.2.0
Minden változás az új funkciók bevezetése ebben az ágazatban.
Branch rendszeresen szinkronizált / trunk fenntartani a jelentősége az ágak.
Miután befejezte a munkát egy jellemző ág egyesül / trunk.
/ Trunk vizsgáljuk.
Ha minden rendben van, akkor brunch /branches/1.2.0 eltávolítjuk.
Alapján / trunk létrehoz egy új kiadás /tags/1.2.0
Alapján létrehozott /tags/1.2.0 Brunch /branches/1.2-stable kiadás
/tags/1.2.0 fektetve a termelési kiszolgálóval

/ Trunk - a fő ága a rendszer fejlesztése.
Kibocsátások alapulnak /branches/x.x-stable ágak.
Meg kell jegyezni, hogy amikor a kimenet a kibocsátás 1.2.0 nem szükséges, hogy támogassa a brunch /branches/0.1-stable. Ez az ág lehet távolítani.

A második stratégia sokkal megbízhatóbb, de használata jár derazht mindig kéznél két munkapéldányból a projekt - Brunch és a törzs kiadás. Szintén ez némi erőfeszítést, hogy támogassa ezen verziók szinkronizált (az hibajavítás). Az első stratégia egyszerűbb és nem igényel különleges képességek adattár kezelése, és talán jobban megfelel a kezdeti szakaszában a svn vagy kis fejlesztő csapat.

Kapcsolódó cikkek