Kérdezd a HUP-ot: leghatékonyabb verziókezelő-rendszer Visual Studio 2010-hez?

Kérdés

Kezdő Visual Studio 2010 fejlesztőkként felmerült bennünk a kérdés: Melyik az a verziókezelő-rendszer, amellyel most indulva 0-ról a jövőben a leghatékonyabban tudnánk dolgozni? Mivel a csapaton belül a vélemények nem egyeznek, arra gondoltunk, hogy a kérdést vitára bocsátjuk. Arra szeretnénk kérni a HUP programozással foglalkozó olvasótáborát, hogy segítsenek véleményükkel a döntésben.

( RaptorBlood | 2011. 08. 26., p – 08:09 )

Mi ClearCaset hasznalunk, vegul is legacy mert mar 2008-asal is azt hasznaltuk. Most valtunk 2010esre es eddig nem volt gond vele.

Alig több, mint egy hónapja van közöm TFS-hez, szóval még nem értek hozzá, de egyelőre nem győzött meg. Szintén VS 2010-ből használva hogy oldjátok azt meg, hogy ha egy fájlt átteszel máshova, akkor megmaradjon a history-ja? (van tfs move, de az olyan mintha del,add-ot használna a háttérbe). Fájlok/mappák/projektek átnevezése is szívás egyelőre, több lépésben lehet megcsinálni "normálisan". Illetve amit még tapasztaltam ,hogy "Get latest version" olykor nem tud mindent leszedni és ilyenkor a "Get specific version" és mindent felírunk kombóval lehet érvényesülni.

rename move helyett megtartja a historyt, fajlok/mappak/projektek atnevezesevel nem volt kulonosebb gondom 1 ev alatt (ettol meg lehet), a get latest gondolom conflict miatt nem szed le mindent, amit a get specific version/overwrite local files 'megold'.

nekunk bevallt, es a legtobb esetben eszrevetlen es megbizhato a hasznalata (ami a legnagyobb elony). ugy altalaban kenyelmes es nagyon jol beepul a vs2010-be. persze ettol meg valoszinuleg vannak hianyossagok.

rename - ezt megnézem holnap. kösz!
conflict miatt? ez érdekes, mert ha van conflict azt jelzi és megkérdezi, hogy a saját verzió maradjon meg, vagy a szerveren lévő vagy kézi merge. Viszont amire én gondolok az abból áll, hogy azt mondja, hogy legfrissebb verzió van nálad, közben ez nem igaz.

( Jason v | 2011. 08. 26., p – 08:51 )

Amit tudsz VS-be illeszteni, az szinte mind jo, a perforce egy nagy hanyadek, azt erosen ellenjavallom, a tobbi viszont vallasi vita jellegu szerintem.

Ezzel vitatkoznék.

A perforce VS integrációja tényleg nem a legjobb, de mint verziókezelő rendszer nagyon is jó az én véleményem szerint. Mi több gigabájt adatot kezelünk vele több száz ágon bármilyen fennakadás nélkül - az Atlanti óceán 2 oldalán. Mondjuk összehasonlítási alapom csak az SVN-nel és a CVS-sel van, de azoknál fényévekkel jobb.

Hat amit irsz abbol meg az is lehet hogy egy cegnel hasznaljuka perforce-ot (andrássy, paulay, káldy mond valamit?), de meg ha igy is van, teljesen eltero a velemenyunk rola. Az hogy checkoutolni kell a fajlt szerkesztes elott es ez a read-only flaggel bohockodas a 21 szazadban szerintem elfogadhatatlan. Kicsit regebben elagazott brencsek ujramerge-elese gyakorlatilag lehetetlen, es a masodik generacios vcs-ek "az egesz vilagot (ceget) egyetlen repoba" felfogasa is totalisan agyament. Meg amitol meg a falnak megyek az a "workspace"-ek hasznalata ami a kicsekkolt fajlok nyilvantartasa miatt kell a perforsznak. Nonszensz. Ja es mindemellett lassu is, mint allat.

http://gpsforum.hu - Navigációról szájkosár nélkül

Mi meg tobb szerveren keresztul hasznaljuk (usa, irorszag, meg talan meg japan, de turul tudja ezt jobban).
Sebesség: 9k6-os modemen torrentezni.
Használhatóság: Keresés egy vicc. Az meg, hogy ha valamibol leszedem a legfrissebb verziot, azt egy speci konyvtarszerkezetbe teszi a workspace-ben es nem oda ahova en akartam, az rohej.
Ékezetes könyvtárneveket nem mindig hiszi el, pedig elvileg utf8.
(Tobbek kozott) VS2k8-ban kezzel kell konyvtarakat atneveznem, mert eloszor a solutionban atnevezem, majd megkerdezi h az scm-ben is akarom-e, mondom igen, erre az uj nevu konyvtar megjelenik, mint scm-ben _nem_ levo elem, de hozzadaskor conflict, majd a p4v kliensbol kell a regit megint atnevezni, majd mint letezo konyvtarat hozzaadni a projecthez.
Vagy mi vagyunk ilyen luzerek, vagy vmi komoly baj van.
Arrol nem is beszelve, hogy ha checkin-elem az egesz solutiont, 2x kerdezni meg a commentet minden fajlhoz.

Na, osszatok.

( naszta v | 2011. 08. 26., p – 09:14 )

Én eddig használtam:

SVN - open source cuccok közül ennek a legjobb a Visual Studio-s támogatottsága. Ha a fejlesztő csapat vegyes, akkor ez a legjobb választás, mert az ablak őrültek és a parancssoros srácok is jól elboldogulnak itt. Linkek: 1 2 3

Git - van beépülő modul, de igazából az egésznek béta feeling-je van. Valószínűleg azért, mert az, szóval felejtős. Ha nem feltétlenül kell integrálódni a VS-be, akkor én ezt szeretem a legjobban, kis csapathoz és multiplatform projekthez messze ez a legjobb. A branch-ing fényévekkel jobb, mint a másik két versenyzőnél. Az egyetlen hátránya, hogy csak parancssorosan vehető komolyan, főleg Windows-on. Linkek: 1 2

TFS - jelenleg a cégnél ezt használjuk. Korrekt rendszer, bug tracker-rel, emberekhez kiosztható feladatokkal stb. A körítés miatt nagy projektekhez biztosan ezt használnám, ha Windows a kizárólagos platform. Link: 1

Ez is szerepeljen! :)
--
http://www.naszta.hu

Nekem VS+[Tortoise]SVN-nel csak annyi volt a problemam, hogy refactoringgal, konyvtaratnevezesekkel csak szopni lehet vele, mint a torkosborz.

Refactoring meg csak-csak, mert ott meg meg lehet oldai, hogy a "missing" statuszu fajlokat torlom, a "non-versioned" statuszuakat meg hozzaadom, de nyilvan gany. Ha meg SVN-bol nevezgetem at, akkor meg a VS-ben kell szopkodni vele, szoval mindket modszer fajdalmas.

Az meg kulon fincsi, ha egesz konyvtarakat helyezgetek at, mert akkor a VS atpakolja vele egyutt a .svn konyvtarakat is (igaz, ez az 1.7-tol elvileg nem lesz problema), ami az almoskonyv szerint sem jo omen.

Es az a gond, hogy ezek foleg C#/.NET fejlesztes valamint refactoring eseten jonnek elo, amiben a VS kulonosen jo.

Egyebkent szeretem az SVN-t, egyszeru, mint a faek (a hozza keszult toolok is), barkinek megtanithato 5-10 perc alatt, csak VS-l fajdalom. De ha valaki tud valami jo megoldast a fenti problemakra, szivesen fogadnam.

Egyebkent meg mar Apache projekt: http://subversion.apache.org

Ui: tapasztalataim a VS+Tortoise/CLI SVN-re szoritkoznak, VisualSVN-t egyszer lattam talan, de nem hasznaltam hosszu ideig. Masreszt otthonra magamnak egy picit sokalltam az $50 USD-t "csak" egy SVN klienssert, melohelyen meg nem kellett annyit VS-sezni, hogy belemenjunk reszletesen a temaba.

----------------
Lvl86 Troll

Na a problema az, hogy C++-ra a TortoiseSVN is boven jo mindenfele integracio nelkul, mert viszonylag ritka, hogy ossze-vissza elkezdjek atnevezni/athelyezni konyvtarokat/fajlokat, ami az egesznek a halala, mert maga a nyelv raneveli az embert arra, hogy gondolja vegig, hogy mit csinal.

C#/.NET fejleszteskor - foleg, ha csak kiserletezik az ember - konnyen elmegy a prototipizalasba, es refactorizalasba a dolog, ahol mar problemasabb, foleg, ha az ember tartja magat ahhoz, hogy a konyvtar/fajlstruktura igazodjon a nevter/osztaly strukturahoz.

----------------
Lvl86 Troll

Git-hez a GitExtensions nekem bevált, egyáltalán nincs béta feelingje, igaz van egy-két dolog amihez a parancssor, a gitk, vagy a git GUI kell, de ezek száma minden verzióval egyre csökken...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

( joco01 v | 2011. 08. 26., p – 09:05 )

Nekem érzésre a TFS lassú és a diff viewer ablaka egy hányadék. Egyébként nagyon jó lenne a beépített feature-jeivel. Kizárásos alapon marad az SVN, jól beépül, mindent tud. Nálunk bevált.

--
joco voltam szevasz

( uid_558 | 2011. 08. 26., p – 09:06 )

Elso korben azt kell eldontened hogy masodik (central repository) vagy harmadik (distributed) SCM-et szeretnetek. Alapveto kerdes, mert a workflow-t is jelentosen befolyasolhatja annak ellenere, hogy egy distributed SCM is hasznalhato kozponti repositorys felallasban, a gen2-es cuccok viszont csak es kizarolag ezt a workflow-t teszik lehetove.

Ha a masodik generacio mellett dontetek, akkor visual studiohoz en a subversiont ajanlanam AKNHSVN-nel. (Bingyozexploderhez is van kituno plugin TortoiseSVN neven.) Evekig hasznaltam a hobbyprojecteim forraskodjatol a dokumentumaimig mindefele cucc kozponti tarolasara es verziokezelesere, nagyon kezes joszag.

Mivel azonban lassan mar a csapbol is a distributed version control folyik, en ugy egy honapja hataroztam el hogy raszanok par hetnyi szabadidot es kicsit jobban megismerkedek veluk. Repo konverzio utan kiprobaltam a gitet es a Mercurialt. Mindkettonel eleg szopas volt kozpont https-en authentikacioval elerheto repo letrehozasa (svn-nel ez eleg jol dokumentalt es relative egyszeru folyamat) de igy utolag ezeknel sem kene bonyolultabb legyen ha letezne hozza jo dokumentacio, no meg en jobban atlattam volna az apacs lelki vilagat.

a vegen git vs Mercurial (hg) -re redukalodott a problema, amibol a Mercurial kerult ki gyoztesen a kovetkezok miatt:
- git eseten a windows tamogatas hat hogy is mondjam: hagy meg kivanni valokat maga utan, mig mercurialnal a windows is teljes jogu polgar a platformok kozott. Tortoisehg (tortoisesvn-nel kb megegyezo szinvonalon), Visualhg (AKNHSVN helyettesitesere Mercurialhoz )
- a git ugyan tobb lehetoseget biztosit mindenfele repo buzeralasra, de egyreszt ez nem feltetlenul elony minden workflow eseten, masreszt a legtobb valoban szukseges ficsor hg-vel is elocsalogathato pluginekkel.
- hg-hez van perforce plugin - perfarce neven keresd - (lokalisan hg-ben dolgozol, de utana/kozben tudsz push/pull-olni perforce-ba/bol) - melohelyen perforce van sajnos, hullik is tole a hajam rendesen.
- rename: hg szigoruan a sajat velemenyem es izlesem szerint sokkal elegansabban kezeli a rename-eket.
- learning curve: Mercurial konnyebben tanulhatonak bizonyult. A bonyolultabb, kevesbe mindennapos funkcinalitast pluginekkel valositja meg, az alap mukodes gyors elsajatitasa utan raer az ember elszoszmotolni ezekkel, amikor mar tudja hasznalni a rendszer fo funkcioit.
- es a vegen egy nagyon szubjektiv szempont: a git nekem nagyon buhera rendszernek tunt, mig a mercurial sokkal professzionalisabb, letisztultabb erzest keltett.

Es akkor nehany link a sajat dontesed meghozatalanak segitesere:

http://better-scm.berlios.de/comparison/comparison.html
http://www.ericsink.com/entries/hg_denzel.html
http://www.infoq.com/articles/dvcs-guide
http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-…

http://gpsforum.hu - Navigációról szájkosár nélkül

Szerintem manapság a Git is nagyon könnyen tanulható, mivel megvannak a szükséges magas-szintű parancsok. Ha pedig valaki jobban bele akar mélyedni, az is lehetséges.
Hasznos link még: http://icanscale.com/whygitisbetter/

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

( akoscomp | 2011. 08. 26., p – 10:11 )

Mi a cégnél használunk svn-t és tfs-t is. Régen csak svn volt, minden projekt függetlenül a platformtól, nyelvtől úgy programkódokat, mint a doksik egy részét abban tárolja. Pár éve egy projekthez elkezdtük használni a tfs-t is, de ezt csak kizárólag visual studio-hoz.
A tfs-nek megvan az az előnye, hogy mint a microsoft termékekben általában integrálva van benne minden csili-vili, ami sokszor hasznos sőt van hogy nélkülözhetetlen is, de ennek megvan az a hátránya is, hogy egy külön embert ajánlott kiképezni a szerverhez, aki tudja kezelni ezeket, illetve finomhangolni tudja a rendszert, és persze a megfelelő erőforrásokat is biztosítani kell a szerver alá. Ezekhez az integrált előnyökhöz társul elég sok hátrány, ilyen a sokkal-sokkal nagyobb erőforrásigény, amit már említettem, hiba esetén elég jelentős munka visszaállítani a rendszert, mi jelenleg még nem tudtuk megnyugtató szinten megoldani a szerver backupját, és a mai napig nincs kitesztelt adatmentés-visszaállítás doksink hozzá, mivel ennek a teszteléséhez egy kisebb adatparkot kellene kiépítsünk, nem beszélve az időről.
Az svn az egy verziókezelő rendszer, semmi más. Ez lehet hátrány is, de én inkább előnynek veszem. A rendszernek szinte nulla az erőforrásigénye (a tárterület kivételével ami projektfüggő), jól integrálódik fejlesztői környezettől és platformtól függetlenül, gyerekjáték a kezelése, beleértve az új repók létrehozását, a mentéseket, visszaállítást, jogosultságkezelést, stb.
A GIT-et nem ismerem.

( bervi | 2011. 08. 26., p – 10:23 )

nekem a mercurial (visualhg) nagyon faszán működött, viszont a git extensions-t nem tudtam rávenni, hogy megjelenjen a vs2010 source control részében, de igazából nem is nagyon volt rá szükségem, úgyhogy nem nagyon foglalkoztam vele. biztos megoldható valahogy...

én mindenesetre ezt a kettőt javaslom, innentől pedig valóban vallási vita, én már inkább a git felé húzok, de ha a visual studio szempont lenne, akkor talán hg, a compi által írt okok miatt is (windows port is teljesen összecsiszolt).

svn, cvs, egyéb cvcs-t én önként már soha nem használnék, dvcs-ből pedig meglátásom szerint a hg és a git a 2 legelterjedtebb, ami fontos szempont "támogatás" és fejlődés szempontjából (idézőjel, mivel nem fizetős supportra gondolok, hanem a közösségre).

a tfs számomra nem tűnik életképes jelöltnek, kivéve ha tényleg szükség van a fícsöreire, mert ugyebár a tfs egyáltalán nem csak verziókezelésről szól ám, és nem is két forintba kerül.

( 2Geza | 2011. 08. 26., p – 10:15 )

Projekt méret függő.

<20 fő: SVN
>100 fő: ClearCase, TFS.

A kettő között kicsit szenvedés van.

( sz | 2011. 08. 26., p – 11:15 )

Define "hatékony", mert ez attól függ, hogy mik az igényeitek az SCM-mel szemben, illetve hogy mit értetek "leghatékonyabban dolgozni" alatt.
Ha csak annyi kell, hogy N darab fejlesztő egyszerre tudja ugyanazt a kódbázist buzerálni, és a változtatásaikat egy repositoryba belehányhassák, amikor kedvük tartja, és a history-ra soha senki nem nézne rá, mert hát miért is tenné, amikor mindenféle, egymástól független változtatások áttekinthetetlenül egybe vannak ömlesztve (pl. "minor fixes" commit message egy 100+ soros változtatáshoz), akkor tulajdonképpen teljesen mindegy. Válasszátok azt, amelyiknek a legszebb a gui-ja.
Ha viszont a cél az, hogy egy olyan áttekinthető history-t hozzatok létre, ahol egy commit nem több független változtatásból, hanem egyetlen kis logikai egységből áll, amiből majd később profitálhattok, mert utána lehet nézni, hogy melyik változtatások tartoznak egybe, vagy bisect-tel meg lehet keresni, hogy egy bug melyik committal került be, stb., akkor a git-nek jelenleg nincs párja. Viszont a VS integráció hagy kivánnivalókat maga után.

Na mondjuk a "barmelyik jo" && fentebbi szivasok a TortoiseSVN-el, amit irtam az szerintem nem teljesiti a hatekony kifejezestol JPE modszerrel elvalrhato szintet :)

"Viszont a VS integráció hagy kivánnivalókat maga után."

Ugyan a kerdezo nem irta, de gyanitom itt jo VS integraciot varnak el. VS egyik elonye, hogy viszonylag keves dolog miatt kell kimaszni a programbol.

----------------
Lvl86 Troll

( srrrgei | 2011. 08. 26., p – 11:58 )

Nekem a hatékony, ha nem épül be az IDE-be, és parancssorból tudom használni. Úgyhogy nálam cygwin+git a nyerő.

git mv filename

Én személy szerint használom a git-et és TFS-t is. A git sokkal jobb branchingben, TFS-nél, szerintem. Mind a kettővel jól lehet dolgozni. Hozzám a git picivel közelebb áll, de látom, hogy sok fejlesztős projektnél sokkal jobb lehet a TFS, mert nem kell a verziókövetés mellé bugtracker, projekt manager, dokumentáció stb., mert minden egy helyen van TFS, SharePoint és Exchange-ben.
--
http://www.naszta.hu

( b | 2011. 08. 27., szo – 21:25 )

Én mindenhez gittet használok.

Viszont ha van pénzetek Visual Studióra akkor használjátok azt, amit a Microsoft ad vele.

--
GPLv3-as hozzászólás.