SVN-ben, hogyan kezelitek az éppen fejlesztés alatt és éles verziót?

Java

Az alábbi gonddal szembesültünk:

- Élesben fut egy régebbi verzió.
- Kb. tavaly augusztusban készítettünk a felhasználók kérésére egy új verziót. Ebben több igény volt megvalósítva. A több igény közül 1 igény nincs az igénylő által letesztelve, pontosabban nála áll a feladat (elég bonyolult volt komplett wf átírással).
- közben jönnek az új igények másoktól csőstül amelyeket be kellene rakni élesbe.
- Gondoltam svn branchben szétválasztjuk, de vagy a komplett rendszert duplikálom szét minden ilyen esetben, vagy a külön könyvtárakat (template, javascript, java források...). A külön könyvtárak úgy látom nem működnek az SVN-ben. Amikor merge-lem, akkor nem kerülnek vissza a helyükre a fájlok.

Tehát Ti, hogy kezelitek az új fejlesztés vs. éles ilyen kezelését?

  • 1887 megtekintés

( sz332 v | 2011. 01. 11., k – 11:09 )

Szia,

nálunk most úgy van, hogy:

- 1 main branch, ami stabil, letesztelt, ebből mindig tudunk release-elni.
- Minden új feature-nél külön branch, abban kódolunk, tesztelünk, és ha megvan, akkor mergelésre kerül a fő branch-be
- Minden egyes release tag-gelve van, ha javítani kell, abba javítunk, amíg el nem érünk a következő release-ig, ekkor a felhasználó már az új verziót kapja.
- Minden feature-t be-ki tudjuk kapcsolni egy licensz fájlból, tehát a felhasználó csak azt kapja, amiért fizetett.

( Exit | 2011. 01. 11., k – 12:38 )

Ha nincs sok fejlesztő és/vagy jó a munkafegyelem akkor elég az is, hogy
- trunk-ra megy minden új fejlesztés
- időnként levonul branchbe az aktuális verzió (pl.: 1.x) és arról mennek a tagelt releasek (1.1, 1.2,...)

Ez egyszerűbb, mint az állandó branchelés, mergelés, de persze ez csak egy határig működik (10 emberrel még működhet). Több java opensource projekt is így működik.

( yoursoft | 2011. 01. 11., k – 13:59 )

Köszönöm a válaszokat. Még egyeztetek a többiekkel, viszont az alábbi lehetőség lesz valószínűleg:
Fő ág mindig az élessel megegyező, és egy dev branch, ahonnan amikor az élesbe mennek a devből a dolgok, akkor visszakerülnek a fő ágba. Időnként nagyobb módosításoknál tagelünk.

( naszta v | 2011. 01. 11., k – 15:10 )

Mi a teljes fát szoktuk branch-elni. Egyébként mi áttértünk git-re, mert sokkal kulturáltabban kezeli ezeket a kérdéseket.
--
http://www.naszta.hu

6.7-ig mukodott a http://github.com/myabc/nbgit , illetve a 7.1-ben valoszinuleg lesz igazi git support, most a main-golden agban mar van ( http://hg.netbeans.org/main-golden ). Errol az agrol azt kell tudni, hogy ez tesztelve is van, es talan a nightly-k is innet mennek...
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Szia!
Git-ben hogyan lehet olyat csinálni, hogy a mainline-ban van(nak) a termék(ek), project branch-ekben megy a fejlesztés, de nem feltétlenül abban a forrásfában, mint ami a mainline-ban van. Aztán ha kész 1-1 project, akkor a változtatásokat, vagy azok egy részét visszatenni a mainline-ba.
Köszi!

Egyszeruen: felveszed remote-nak a development fat, es git pull devel merge-branch. Ez fogja es a devel branch (feltetelezve hogy a remote-nak a devel nevet adtad) merge-branch agat rahuzza a mainlinera. merge-branchba kivalogatjatok azokat a fejleszteseket, amik mainlinere kell menjenek, es done.

Ennek persze feltetele, hogy legyen kozos os. Meg van meg par approbb dolog, amire figyelni kell, de arra valo a tomenytelen dokumentacio gitrol.

(Egyebkent git rulez. Korabban mar akartam javasolni, hogy hasznaljatok megfelelobb eszkozt a feladatra, de visszafogtam magam :P)

--
|8]