Aký je Váš obľubený version control nástroj ... a aký Vám je predpísany? :-)

Mna by celkom potesilo, keby tfs podobne ako codeplex podporoval mercurial.

vlko ma predbehol... chcel som tiez napisat, ze by ma potesilo, keby TFS podporoval mercurial ako codeplex... ;)

--s.

SVN oblubeny, TFS a Git predpisane
Mercurial nepoznam, z DVCS pouzivam len Git a aj ked som si uz zvykol nebojovat s totalnou neefektivitou, ktoru predstavuje Git BASH konzola (Git Extensions a TortoiseGit su IMHO v alpha verziach), akosi som stale nepochopil ake realne vyhody plynu z DVCS
z tych proklamovanych hned skrtam moznost pracovat bez siete, obavu z toho, ze by odisiel serverovy disk a aj rychlejsie vykonavanie operacii

ako to vidite vy?

to cruster: vyhodou dvcs je moznost pracovat voci viacerym repository (v zaklade vlastne len lokalny, co ty vydavas sa moznost offline prace:) a lubovolny pocet vzdialenych) a prepracovany system branchovania a mergovania, pretoze vlastne kazdy commit je merge lokalej commit historie do vzdialenej repository.

Tiez logika prace je casty local commit aj ked je breaknuty a commit na vzdialeny repozitory az je vsetko ako ma byt.

Teda aspon ja to tak chapem, mozno niekto da viac teorie.

Mne osobne by vyhovovala moznost jednodudcho mat DCVS.

Preco? Obvykle nie som 4 z 5 dni v tyzdni na LAN-ke kde je nas TFS, a tak robim cez VPN, co sice ide dobre, no ovela viac by mi vyhovovalo robit voci lokalnej repository a dat von push, ked by mi to vyhovovalo.

To by tiez pomohlo v tom, ze by som nemusel davat do TFS veci ktore nechcem (a aj tak by som ich mal v repository, ak by som potreboval)

No a samozrejme moznost robit voci viacerym repositories - ako pise vlko.

Celkovo styl prace s DVCS mi vyhovuje viac, je akoby volnejsi, i ked vsetko ma vyhody aj nevyhody. Aj ked ak si clovek aspon trochu zvykne na DVCS a potom skusi ist nazad na SVN ci TFS, tak je to IMHO o dost neprijemnejsie ze ist opacne.

git je cool, no Mercurial ma zasa ovela lepsiu integraciu s Windows (TortoiseHG) a VisualStudiom.

Inak prakticky vsetci velki hraci co sa tyka SourceControl deklarovali snahu pridat do svojich systemov moznost pracovat v style DVCS (napr. pri Microsofte to pisal Brian Harry tu - http://blogs.msdn.com/bharry/archive/2010/01/27/codeplex-now-supports-mercurial.aspx - samozrejme oficialne nic nebolo oznamovane).

Inak pekne clanky o DVCS su:

http://www.ytechie.com/2009/11/introduction-to-distributed-source-control.html

http://www.ericsink.com/entries/dvcs_dag_1.html

http://www.ericsink.com/entries/dvcs_dag_2.html

Porovnanie source controls:

http://www.ericsink.com/entries/hg_denzel.html

http://versioncontrolblog.com/comparison/Git/Mercurial/Subversion/Team%20Foundation%20Server/index.html

-- s.

Volakedy davno to bol SourceSafe. Takze logicka evolucia bola na TFS. A pri nom som zatial aj zostal. Kedze stale robim na LAN, tak zatial som nemal dovod pozerat po inom VCS. Teda nie len ja, ale hlavne company policy :)

Len si osobne myslim, ze je skoda, ze TFS vyuzivame len ako source control, ked ponuka ovela viac moznosti.

mam podobny nazor/otazku ako cruster

@vlko,@slavof: TFS 2010 budes moct instalnut aj lokalne.

Ak mam pristup ku replikacii z ineho prostredia, tak mozem mat pristup aj priamo na centralny source control resp. editovat offline a potom mergeovat, ked bude online.

VPN je z hladiska security priechodnejsia zvacsa ako priamy access na source control.

TFS ... moznost shelvnutia, az potom commit

VSS ---> TFS ...> SVN+Ank+DiffMerge a momentalne snaha o ---> TFS

co prakticky znamena ta "moznost pracovat voci viacerym repository"?
jediny scenar, s ktorym som sa stretol a podobal by sa tomu je, ze koren aplikacie je tahany z git.gnome.org a jeden specificky podadresar z gitorious.org
co ale realne znamena, ze zmeny zo servera dotahujem cez "git pull" v koreni, no nasledne "cd podadresar" a opat "git pull"
a v tom nevidim nic nevidane - ked vhodne zeditujem .svn/entries nejkeho podadresara, tak dosiahnem rovnaky efekt

specifikom Gitu tiez je, ze akonahle mate nejaku lokalnu zmenu v subore, v ktorom je zmena aj na serveri, tak "git pull" namietne, ze bola zadetekovana zmena a ani len sa nepokusi to zmergovat, hoci ide o nekolizny merge
zatial sa mi nepodarilo prist na lepsi sposob ako to vyriesit ako taky, ze si tie lokalne zmeny niekam odkopirujem, zmenene subory znovu checkoutnem a po pulle svoje zmeny znovu nakopirujem na spravne miesta

a takychto roznych problemov je kopec - o spolahlivosti implementacie msysgitu na windowse ani nehovorim
na konci dna clovek zisti, ze zabil takmer tolko casu ako na vyvoj bojom s Gitom

viem, ze sa o nom strasne vela pise, bloguje a vela projektov nan prechadza, ale mne sa aj tak nezda byt cool

to cruster: dokial nie je zmeneny riadok, tak urobi automerge, testoval som to teraz takto:
1. prvy local repository - vytvorit subor, commit a push to remote
2. druhy local repository - pull, pridat riadok, commit a push to remote
3. prvy local repository - pridat riadok, commit a pull urobi automerge (subor obsahuje ako riadok z remote, tak lokalnu change)

to T: nejde o lokalnu instalaciu, ide o historiu zmien, ked lokalna historia z local repository sa pri pull stane sucastou remote repository a to uz blame (annotate) dava iny zmysel a najma, mozes si verzionovat lokalnu neskompilovatelny zdrojak, len kvoli trackingu zmien a do remote repository postnes az funkcnu verziu aj s celou historiou

@vlko: = vyuzitie v realite marginalne(ale mozno mi chyba predstavivost) ... ked dorobia historiu nad shelvami v TFS tak je to +- to iste a sme len pri tom crusterovom offline.

to T: nemas celkom pravdu, zakladom pouzivania source safe systemov je mat commit co najcastejsie, co ale v poslednej dobe ako sa rozbiehaju CI riesenia, tlaci developerov bud nejak tagovat commit, ktory vyvola build, alebo riesit build manualne/casovo, ale stale moze padnut, ak nepouzijes tag. A to este nehovorim o checkin policy, ktoru obcas nejde preskocit a checkin sa ti vrati. Vo vysledku teda programator checkinuje menej castejsie az dokonci celu robotu, co pri nejakych code reviews alebo zlozitejsich zmenach dost nap.t.
Riesenim je bud shelvovat, ale pri shelvoch nemas previazanost medzi jednotlivymi shelvami, nemozes shelve branchovat. Alebo pouzijes distribuovany source system. Programator si commituje zmeny lokalne, moze sa medzi nimi vracat az nieco domrvi, ale hlavne kazdy commit moze mat tag a ma popis a ked je s riesenim spokojny, pushne zmenu na server, aj s celou historiou zmien a tak blame/annotate ti da skutocne dobry vysledok.

Mozno nehovorim, len sam za seba, ale zacinam byt v poslednej doby s verzionovanim tfs frustrovany. Casove rozostupy medzi commitmi sa pomaly predlzuju a potreboval by som zdielat medzi projektami urcite podadresare v projektoch, nieco presne na sposob modulov v git.

Uz to tu popisal dost dobre vlko...

Z mojho pohladu je skor primarny sposob prace, konkretny nastroj (konkretny source control system je az potom).

Iste sa nejak da dosiahnut popisane scenare aj pomocou TFS so shelvami, offline pracou, nejakym systemom branchov a mergovania, ... no osobne mam pocit, ze to co chcem sa da jednoduchsie a prirodzenejsie (z mojho pohladu, ktory iste nemusi byt jediny a najlepsi, kazdy nech robi tak ako mu to vyhovuje) dosiahnut pomocou DVCS.

Hlavne argumenty ako pisal vlko su: chcem mat (idealne lokalne) vlastnu repository, prip. viac repositories, kde vyvijam kod, robim pokusy, nechcem aby to videli okamzite ostatni (resp. aby sa mi nad kazdym check-in-om spustali vsetky standardne procesy), a nechcem aby tieto nestabilne veci zbytocne naveky zostali v source-control systeme, mozem repository okamzite zahodit ak je nieco uplne mimo, a nakoniec mozem dat von (zdielat) len to co chcem... akoby som chcel mat jednoducho vyhody source control systemu, bez toho, aby som urobil plnohodnotny check-in do TFS, ... no a samozrejme chcem, aby to fungovalo spolu - t.j. aby som nemusel pouzivat dva systemy (ci uz rozne alebo rovnake).

To co hovorim teda je, ze niektore(!) veci co by som chcel mat vo svojej "pracovnej workflow" nastavene a co najviac zautomatizovane sa jednoduchsie daju realizovat pomocou distribuovanych source control systemov.

Z toho pohladu by mi asi najviac vyhovovala nejaka kombinacia TFS s distribuovanym source controlom- napr. ten Mercurial-TFS, alebo TFS s DVCS featurami.

Inak TFS pokladam ze velmi dobry source control system a nechcel by som sa celkom vzdat jeho infrastruktury - work items, previazanie na office, projektove sablony, a mozno aj build system, su celkom fajn.

-- s.

vlko, tak potom asi robime s roznymi verziami gitu, pretoze u mna to skonci na:
"Entry ‘foo’ not uptodate. Cannot merge."

Aky vyznam ma vlastne komitovat lokalne? To je akoby si nekomitol vobec. Vecer si na notebook vylejes pohar vina a disk a s nim aj tyzdnova praca je v haji.
Ake racio je za tym, ze by mal ist do repository vzdy len najfinalnejsi stav akejkolvek novej funkcionality, ci zmeny? Nikdy ste do repository nekomitli ziadny kod, v ktorom by bolo "// TODO"?

to cruster: to uz trosku vyvadzas do extremu. Ako som uz hovoril, zober si priklad, ze na server commit (teda v git pripade push) mas zaviazane nejake integracne, unit testy, pripadne v pripade aktivneho teamu, pre zmenu pripad, ze si niekto stiahne nekompilovatelnu verziu len preto, ze si si ty commitol verziu, ktora nie je kompilovatelna.

V pripade standardnych vcs ta to vedie k tomu commitovat iba funkcnu verziu, co moze byt 2,4,8, niekedy aj viac hodinova zalezitost. Preco by si ale mal prist o historiu postupnych krokov a moznost sa k nej vratit? A ano, bezne to riesime pomocou undo, ale co ked padne visual studio, alebo je zmena cez viacero suborov? Shelve je len ciastocnym riesenim, shelve neumoznuje dalsie kontinuum, ale co shelve to osobitna verzia.

Ale mozno ide len styl o programovania. Ja hlasam teoriu, ze task by namal trvat viac ako 16 hodin, maximalne 24 (3 dni), bezna velkost od tych 4-8 hodin (kratsie tasky len zvysuju administrativnu pracu, preto ich mergujem do vacsich celkov s min 4 hodinami). A samozrejme v mojom kode byva aj todo aj neimplementovany interface (todo komentare moc nepouzivam, to si radsej hned spravim task v tfs, mam skusenost, ze o todo sa aj tak nikto nestara:).

@vlko,@slavof:"zakladom pouzivania source safe systemov je mat commit co najcastejsie, co ale v poslednej dobe ako sa rozbiehaju CI riesenia, tlaci developerov bud nejak tagovat commit, ktory vyvola build, alebo riesit build manualne/casovo"

toto nie je o DVCS...ale o moznostia toolu...@vlko vymyslas pseudoproblemy :-)
TFS = Shelving + Branching -> o com pisete obaja, v com je specifikum DVCS v tomto smere okrem toho "offline"? "Commituj" si kolko chces(napr. do shelvu)...

a fakt chcete mat "offline"?
+(since 2010) TFS mozte mat TFS aj lokalne a ked s apotrebujem hrat ako pise slavof a nechem aby niekto videl moje pokusy(paranoja?)...tak si to supnem tam. Ak chcem commit na ostre TFS, co mi brani priamo pouzit moju (nejaku)working copy?

@vlko: aj ten dalsi...len pseudoproblemy zatial, sorry.
Commit do shelvu (nemam vec ready to build, ale nechcem prist o zmeny ked mi odide ntb), potrebujem robit nejaku zmenu teamovo a izolovat sa od hlavnej vetvy? (branch)

Historia zmien? Ved ju mas v branchy a dokonca branche vies manageovat a viazat na nejke projektove milniky -> fixnutie bugu 100, 101, 102

kde vidis stale problem?

@T:

paranoja?

no vies... par rokov som bol sys admin na velkej sieti... uz sa toho asi nezbavim... ROTFL :))

-- s.

@slavof: ;-)

a sorry chlapi za ten zase asi na prvy pohlad "arogratny" ton...mam na to dar :-)

to T: ja som si na tvoj styl uz zvykol:) Proti argumentu prepojenia vcs s taskami, bugmi, sa neda moc namietat, prave preto tfs vsetci pouzivame, nie?:) Ale spat k teme, tazko ta presviedcat o niecom, co si neskusil, skus si git/mercurial sam a uvidis ci ti koncept branchov ala tfs vcs nepride zastarany. Doba sa meni a keby nie, mozno este teraz kodime v vb6 alebo delphi a o par rokov sa dvcs urcite dockame aj v tfs, chce to len cas:)

@vlko:
ano, moze to byt aj o tom (ze som neskusil), ale zatial som necital jeden argument, ktory by ma naozaj presvedcil, aby som tam ucinil ;-)
...nuz ale zase nie vsetko nove je nutne aj posunom vpred, niekedy dva kroku vpred mozu znamat aj tri dozadu zaroven ;-) vid ASP.NET MVC(ked uz kontrapriklad) :-D aj ked to zase nie je nic nove :-)