( Aadaam | 2011. 06. 25., szo – 18:59 )

Van tervbe hogy a kov. projektem githubon fog menni nem a jol megszokott code.google.com -on, de vallalati kornyezetben en minden elosztott megoldastol fraszt kapok; tetszoleges ismert nagyvallalatban a kaosz szintje mindig a mukodeskeptelenseg hataran billeg, mindig minden hiba arra vezetheto vissza, hogy ja azt valaki nem mondta el senki masnak, csak az o gepen volt, stb; sz'al ne akarjuk elosztani :)

Eddig csak 2-3 commit volt egy mercurial alapu borzalomba, meg par sima git clone, git push, meg olvastam posztokat hogy emberek hogy gondoljak ott a branchinget, en meg... jujj... sok projektet lattam en mar bedolni es nagyon halas vagyok az svn-nek hogy segitette a munkamat, ami arrol szolt, hogy a ram bizottakat ne hagyjam.

Sz'al nekem ilyen alapszolgaltatasok kellenenek, mint:
- Csak a kommitolatlan fajloknak nincs szerveroldali masolata
- Nincs demozhato allapotu fejlesztes szerveroldali masolat nelkul
- Featurebranchek is szerveroldalon
Okok:
- A munkaallomasok nem megbizhatoak (ellophatjak, elfustolhet)
- A munkatarsak nem megbizhatoak (lustak)
- A kod nem megbizhato (lehet vacak)
- A hibaknak joval hatarido elott kell kiderulnie (elvaras a napi commit)
- A hibaknak integracio elott mar ismerteknek kell lennie, es nem az integracio elotti feloraban szabad kiderulniuk
- Az integracios problemakat mar a fejlesztes folyamataban fel kell tudni ismerni (siman commit-atnezessel)
- Kell lenni legalabb egy embernek aki pontosan tudja, mi tortenik az EGESZ projektben, es ez az informacio folyamatos (ez en lennek)

Ja, es projektutemet is figyelni kell ugye (az egy gyonyoru elkepzeles, hogy oszd fel apro reszekre, ez papiron qrva jol mukodik, az eletben nagyon nem), sz'al tudni kell, melyik feature hogy halad, es ezt csak koztes kodallapot ismereteben tudod megmondani.

Sz'al erre az SVN egy alomeszkoz; nem tudom, es nem hiszem igazan, hogy a git-et erdemes beidomitani ilyenre.