Van egy projektünk amelyből több "major" verzió is létezik. Például gizik-1.0, gizike-2.0, stb.
Ezeket külön is fejlesztik, azaz létezik gizike-1.0.x és gizike-2.0.x.
Az világos, hogy ezeket be tudom rakni branch-ba valahogy így:
gizikeprojekt
branches
gizike-1.0
gizike-2.0
tags
gizike-1.0
gizike-1.0.x
gizike-2.0
gizike-2.0.x
trunk
A kérdésem az, hogy akkor mi kerül a trunk-ba? Az okés, hogy az aktuálisan fejlesztett kód, de melyik? Az amelyikből várható például a 3.0? Nekem ez tűnik logikusnak.
Tovább, hogy fejlesztenek akkor direkt valamelyik adott branch-ba? Onnan checkoutolnak és oda commitolnak vissza?
Ha vissza commitolnak a branchba akkor onnan is lehet közvetlenül tag-et létrehozni?
- 3073 megtekintés
Hozzászólások
akkor mi kerül a trunk-ba? ... Az amelyikből várható például a 3.0? Nekem ez tűnik logikusnak.
Jaja!
De hogy ne legyen ilyen egyszerű az élet, kicsit megkavarlak.
Először is a branches, tags, trunk könyvtárszerkezet csak ajánlás. Ha te akarsz, akkor fejleszthetsz a tag-ben is, vagy a "new folder" könyvtárban, vagy akármiben.
Másrészt tag-et fölösleges csinálni, elég, ha megjegyzitek (pl. az SVN log-ban), hogy 2009.6.3-án kiment egy release a branches/gizike-1.0@456 verzióból. De ha valaki a tag-elést szokta meg máshol, akkor azt használja SVN-ben is.
Ha vissza commitolnak a branchba akkor onnan is lehet közvetlenül tag-et létrehozni?
Persze. Egy "svn cp" parancs az egész. És az SVN log-ban látszani fog, hogy honnan jött az az "svn cp".
Tovább, hogy fejlesztenek akkor direkt valamelyik adott branch-ba?
Ez a fejlesztés legnagyobb dilemmája. Elhatározás, és önfegyelem kérdése. Mert ha gizike-1.0-ban is fejlesztünk, meg gizike-2.0-ban is, akkor előbb-utóbb eltávolodik egymástól a két ág, és külön életet fognak élni. Általában azt szokás csinálni, hogy mihelyst a gizike-2.0 elindul, a fejlesztések csak abban mennek, gizike-1.0-ban kizárólag hibajavítás folyik, és a javításokat fölmördzsölik gizike-2.0-ba. De aztán lehet ezer olyan indok, ami miatt be kell vállalni az azzal járó szívást, hogy egyszerre két ágban is megy fejlesztés.
- A hozzászóláshoz be kell jelentkezni
Ja lemaradt ...
Szóval hagyományosan - vagy az ajánlás szerint - úgy szokás dolgozni, hogy csak a trönkben dolgozunk. Aztán amikor a trunk megérett a kiadásra, akkor leágaztatjuk a branches/gizike-x.y-ba, és trunk-ben megy tovább a fejlesztés.
A trunk-ben viszont szokás rendet tartani, azaz minimum azt meg szokták követelni, hogy forduljon a cucc. Emiatt szüksége lehet a fejlesztőknek munkaágakra is, pl. branches/jozsi/... , amibe olyan szemetet tesznek, amilyet akarnak. Ha a szemét már kezd alakulni, akkor Józsi majd mördzsöli az egészet a trunk-be.
- A hozzászóláshoz be kell jelentkezni
Nagyon köszönöm a válaszokat!
--
\\-- blog --//
- A hozzászóláshoz be kell jelentkezni
A reelase-k a tags-ba kerulnek, a branches a szemetelesre valo. Legalabbis csak igy van ertelme annak amit mondasz, es ez a valos helyzet is.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Eljutottam odáig, hogy szeretném az egyik branch-et visszaolvasztani a trunk-ba.
cd /path/to/trunk
svn merge -r24:36 file:///svn/patch/to/branch
Ahol -r24 ahol a branch leágaztatása történt a trunkból, az -r36 pedig gyakorlatilag a trunk HEAD.
A gondom az, hogy gondolkodik darabig majd nem csinál semmit, illetve csak ennyit.
svn status
M .
svn diff pedig szépen kijelzi a különbséget.
Ez mitől lehet?
--
\\-- blog --//
- A hozzászóláshoz be kell jelentkezni
Varj, az svn diff az mihez kepest jelez difit? Ha csak siman kiadod? Mert akkor azt jelenti, hogy a merge sikeresen lezajlott, lehet nyomni az svn ci -t.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Ez ad kimenetet.
svn diff file:///path/to/branch file:///path/to/trunk
A gondom. Egyszer szépen sikerült letörölnöm a trunk-ot mindenestül. Újra létrehoztam, tettem vettem benne. Most pedig szeretném az adott branch tartalmával felülírni az egész trunk-ot.
--
\\-- blog --//
- A hozzászóláshoz be kell jelentkezni
az svn diff kiírja hogy "Merged" megtörtént, de semmi nem változott. legalább két tucat fájlt kellene kiírnia.
trac és webdav alól is tudom tallózni, látom, hogy a kettő különbözik
--
\\-- blog --//
- A hozzászóláshoz be kell jelentkezni
Aha, nem megfelelő szintakszis esetén ne is várjak mást :)
Szóval:
svn merge -r x:y URI # osszehasonlítás URI két revíziója közt
svn merge URI1 URI2 # osszehasonlitas URI1 és URI2 közt
Mivel nem történt változás 24:36 közt, nem véletlen nem írt ki semmit. Viszont amint megadtam, hogy "svn merge branch trunk",rögtön kiköpött ~200 fájlt :) Igaz majdnem mind conflict :D
--
\\-- blog --//
- A hozzászóláshoz be kell jelentkezni
Az SVN repo konyvtaraba nem szabad kezzel belenyulni vagy abban dolgozni! Helyette "working copy"-t tartalmazo konyvtarban operalunk. http://svnbook.red-bean.com/en/1.0/re16.html
Ezt probald meg:
mkdir /tmp/work
cd /tmp/work
svn checkout file:///svn/patch/to/trunk
svn merge -r24:HEAD file:///svn/patch/to/branch
svn commit file:///svn/patch/to/trunk
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
én a fenti parancsot a már checkout-olt könyvtárban adtam ki, alapból az a working copy nem?
amit te írtál egy az egyben ugyanazt a kimenetet adja, vagyis semmit :(
--
\\-- blog --//
- A hozzászóláshoz be kell jelentkezni
Ja, checkoutbol lesz a working copy.
De azt irtad, h "cd /path/to/trunk", es utana mintha a reposiriry konyvtaraban dolgoznal. Vagy oda checkoutoltal? (Az vegkep nem lenne jo.)
Kozben latom irod feljebb, h jo amit irtam, mert tenyleg nem volt valtozas ebben az intervallumban.
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
Mi ezt úgy oldjuk meg, hogy 4 könyvtárat használunk:
- releases: Ide kerülnek a már kiadott fő verziók (pl. 1.0, 2.0) és itt történik ezeknek a verzióknak a további fejlesztése.
- tags: Tageljük az összes kiadott fő és alverziót (pl.2.0.2, 2.0.4 stb.), így könnyen meg tudsz kapni egy-egy alverziót is.
- trunk: A még nem kiadott fő verzió tárolója (pl. 3.0)
- branches: Mi a stabil trunk stratégiát követjük, vagyis a trunkban lévő kódnak alapvetően stabilnak kell lennie, egy-egy nagyobb programrész fejlesztése külön brancheben történik, és amint a brancheben lévő kód stabil, akkor mergeljük a trunkkal.
- A hozzászóláshoz be kell jelentkezni
Köszi az infót! Ezekre voltam kíváncsi :)
Az kavart be, hogy először azt hittem ezek a könyvtárak/fogalma alapból léteznek SVN-ben, csak nem találtam őket. Aztán azóta világossá vált, hogy ezek "mezei" könyvtárak csak a felhasználó ruházza fel őket "jelentéssel", ergo nekem kell létrehoznom őket :)
--
\\-- blog --//
- A hozzászóláshoz be kell jelentkezni
A könyvtárstruktúrát teljes mértékben te alakítod ki, a trunk/tags/branches csak azért javasolt, mert a legtöbb projekt számára ez megfelelő és elégséges. Egyébként egy pontosítás (csak a félreértés elkerülése végett), nálunk a releases könyvtárban alkönyvtárakban vannak a fő verziók (tehát releases/1.0, releases/2.0 stb), így akár mindkét kiadott verziót is lehet továbbfejleszteni.
- A hozzászóláshoz be kell jelentkezni
Értem.
--
\\-- blog --//
- A hozzászóláshoz be kell jelentkezni
Ok. Egyszerű kérdés. Hogy térhetek vissza mondjuk a 16-os revisionre?
Az alábbi parancs nem csinál semmit.
svn merge --dry-run -r 16:HEAD file:///path/to/svn/repo/trunk
Míg az alábbi parancs szépen kilistázza a változásokat.
svn diff -r 16:HEAD file:///path/to/svn/repo/trunk
subversion-1.6.2 van telepítve ha számít?
--
\\-- blog --//
- A hozzászóláshoz be kell jelentkezni
-svn merge --dry-run -r 16:HEAD file:///path/to/svn/repo/trunk
+svn merge --dry-run -r HEAD:16 file:///path/to/svn/repo/trunk
--
\\-- blog --//
- A hozzászóláshoz be kell jelentkezni
Sziasztok!
Végeztem egy merge-t az egyik branch ággból, de szeretnem visszavonni még commot elött és újra megcsinálni. Ha a reverv-et használom persze visszállitja a fájlokat, de a diff azt mutatja nem maga a merge lett visszavonva, és ezért nem tudom újra megcsinálni a merge-t. Hogy lehet egész merge-t visszavonni?
- A hozzászóláshoz be kell jelentkezni
Megvan a megoldás: meg kell fordítani a merge -r-t.
- A hozzászóláshoz be kell jelentkezni