Jeg kan ikke huske hvornår jeg sidst har lavet et programmeringsprojekt uden versionsstyring. Først brugte jeg CVS og siden er jeg skiftet til Subversion (svn). Det har altid fungeret godt for mig... indtil for nyligt da jeg stod midt i et projekt hvor 40+ udviklere bidrog til kodebasen hver dag og der blev indført ting som commit-pauser varende hele dage og generel forvirring var regel mere end undtagelsen. Suk!
Derfor blev jeg også en smule interesseret, da jeg så at nogle folk fra GitHub kommer til JAOO og taler om det distribuerede versionsstyringssystem Git. Normalt finder jeg ikke versionsstyringssystemer særligt interessante, men som professionel udvikler kommer man ikke uden om at skulle holde sin værktøjskasse opdateret, og her ser jeg potentiale i Git - i hvert fald ved første øjekast.
Første råd jeg fik fra mine twitter-venner var, at glemme alt jeg ved om versionsstyringssystemer i forvejen, og det er da en lidt skræmmende tanke, at man skal til at lære emnet helt forfra. Samtidig er det naturligvis også det der gør Git interessant at se på - og at stille spørgsmålet, "kan en ny tilgang til versionsstyring løse nogle af mine hverdagsproblemer?"
Forskellene på Git og Subversion er mange, men den mest markante er nok tilgangen til branching. I Git er det helt naturligt at du arbejder i din egen branch og så merger ind i hovedbranchen, når du er klar med en feature og netop det kunne løse mit problem med interferens fra mange andre, der arbejder i samme kodebase. Hvis det altså er så let som Git-tilhængere får det til at lyde. Når man er vant til at arbejde med Subversion lugter tanken om at skulle merge mange forskellige branches langt væk af lange arbejdsaftner, så det er en meget forskellig tankegang, der ligger bag de to versioneringssystemer.
Min introduktion til Git startede med Linus Thorvalds' Tech Talk:
Efter denne filosofiske og interessante introduktion til emnet, så jeg mig om efter noget mere konkret at kigge til og en twitter-ven anbefalede en bog af Scott Chacon (fra GitHub) kaldet Pro Git. Den ligger så vidt jeg kan se online i en fuld version, og da Scott kommer forbi JAOO og snakker lidt om Git, kunne det passende være mit mål at få læst den inden jeg skal møde ham face-to-face. Under JAOO kommer en af GitHubs grundlæggere Tom Preston-Werner også og snakker om "Mastering Git Basics", så hvis jeg ikke når igennem bogen er det planen at tage til den præsentation.
Jeg har ikke sat mig ned og fået praktisk erfaring med Git endnu, fordi alle mine eksisterende projekter allerede er i Subversion og jeg har på fornemmelsen at det nok ikke er helt nemt at migrere. Det må blive det næste projekt. Det er dog befriende at se at der også eksisterer en udgave af Tortoise til Git kaldet TortoiseGit - så er der da noget der lugter lidt bekendt.
Har du ellers nogle gode kilder til information om Git' Hvilket versioneringssystem er din favorit' Hvad bruger I på arbejdet og kunne I finde på at skifte' Hvilket hverdagsproblem skulle dit ønske-versioneringssystem løse'
jeg har på fornemmelsen at det nok ikke er helt nemt at migrere
mener du her den tekniske migrering eller at du som bruger skal omstille dig til at bruge git frem for svn?
Den tekniske del er ganske simpel http://www.ultrasaurus.com/sarahblog/2009/02/moving-from-svn-to-git/ kan anbefales som en god fremgangsmåde for at gå fra SVN til Git
Et godt sted at starte med at forstå nogle forskelle er http://git.or.cz/course/svn.html
Har du ellers nogle gode kilder til information om Git? Hvilket versioneringssystem er din favorit?
Perforce - først og fremmest fordi det i en situation hvor sandsynligheden er stor for at folk kan finde på at rette i samme fil på samme tidspunkt rent faktisk virker - i modsætning til eksempelvis CVS og Subversion. Desuden er det hurtigt (deraf navnet).
Mercurial er også et distribueret versionsstyringssystem.
Joel Spolsky har skrevet en god introduktion til Mercurial, der hedder HgInit:
http://hginit.com
Første afsnit er for "immigranter" fra bl.a. Subversion. Her får frygten for branching også et par ord med på vejen:
“The trouble with distributed version control is that it makes it too easy to branch,” I said, “and branching always causes problems.” Turns out this was wrong, too. I was on a streak. Branching causes problems in Subversion because Subversion doesn’t store enough information to make merging work. In Mercurial, merging is painless and easy, and so branching is commonplace and harmless.
Jeg bruger selv CVS, men synes de distribuerede tilgange er interessante.
Kommer helt sikkert an på hvem der skal bruge det og på hvilke systemer.
Det svære er at finde ud af hvilken arbejdsgang man reelt vil ha' og derefter vælge sit revisions kontrol system / setup.
His du ikke kender distribuerede revisions systemer på forhånd er det svært at vide de hvilke arbejdsgange der er ;). Det er lidt historien med hønen og ægget.
Men har jeg i forskellig grad brugt,
Git (C) ,Mercurial/Hg og Bazaar (python) og darcs (Haskell), men på ingen måde nok til at bedømme dem.
Du kommer rigtig langt med en person på holdet der kender værktøjet i forvejen i tilfælde af problemer og generel brug. Du lærer det hurtigere hvis en viser dig hvordan det kan gøres i stedet for at bruge google.
Git er mere tricky at bruge end andre distribuerede systemer, også selvom de idag har et flot screenshot af deres 'git --help', så er min erfaring at det kræver en del ekstra --options for diverse kommandoer for at gøre lige præcis det man vil. Desværre også for de mest hyppige handlinger, som jo netop børe være de mest simple.
Men det virker og er meget hurtigt, men der er sq ikke tænkt over brugsvenlighed. (Og det er ikke en man side eller --help)
Jeg mente mest den daglige brug, men skønt med nogle gode links. Tak!
Jeg har aldrig haft æren af Perforce, men kender smerten ved at mange retter i den samme fil på en gang i Subversion - ikke kønt!
Mercurial er også på min liste over ting jeg burde vide mere om :-). Flere af mine venner har præsenteret Mercurial værende lige så stærkt som Git, men med brugervenlighed - og det skal man ikke kimse af.
Desværre er jeg ikke så heldig at have et teammedlem, der kunne vise mig genvejen til distribuerede versionsstyringsværktøjer... - det tætteste jeg kommer er præsentationerne på JAOO.
Og ja, motivationen for at lære mere om Git kommer fra et hønen og ægget problem - jeg har ikke vidst om Git var værd at sætte sig ind for at løse nogle af mine problemer, fordi jeg ikke vidste mere om Git ;-)
Martin Fowler har lavet en survey, som jeg med risiko for at gentage mig selv fra en anden artikel her angiver men har god relevans for dit spørgsmål:
Min favorit er git, det skal der ikke herske nogen tvivl om. Jeg er glad for at man kan behandle repositoriet som man vil, inklusive at omskrive historik (Ja, det er en feature og det bliver benyttet jævnligt). Desuden er jeg glad for at branching/merging fungerer og er hurtigt. Det er ikke ualmindeligt at jeg har en 20-30 personlige branches og mindst lige så mange fra andre udviklere. Og det kan git nemt jonglere med.
Mercurial forekommer mig ikke at være mærkbart nemmere at forstå. Det handler om øjet der ser, tror jeg. Jeg tror mest det er en skrøne fra tidligere tider hvor der var stor forskel på værktøjernes UI. Man skal bare være opmærksom på, at hvor en git-bruger vil have en tilgang, så har en mercurial-bruger en anden -- men det sluttelige resultat er det samme.
Perforce har et par use cases hvor det klarer sig langt bedre end git. Den mest oplagte er hvis dit repository er et par hundrede gigabyte i størrelse og du kun vil lave partielle checkouts, har mange binære filer, etc. Til gengæld tvivler jeg på at perforce har en chance når vi snakker branching-hastighed. Git er millisekunder om det (og P4 skal have et roundtrip til serveren). Perforce er bestemt heller ikke gratis. Standardlicensreglerne siger at et 40-mand team skal slippe med 160000 danske kroner for at få lov at være med :)
Efter at have læst Pro Git og brugt github til at par små projekter... Er jeg helt solgt...
En ting er alle de fede features som git har... og det nye koncept, hvilket alene er nok...
Men når man f.eks. bruger github er det betydeligt nemmere for andre udviklere at lave en fork og gemme deres ændringer der...
Og det er rigtigt nemt for den oprindelige udvikler at hive ting fra trejdeparts udviklere ind...
Ingen grund til at sende patches med e-mail eller hvad man nu ellers kunne finde på. Som iøvrigt gør hele processen mere besværligt.
- Bare fork, commit og prik udvikleren på skulderen...
Man skal ikke undervurdere det sociale aspect af github.
Om dit IDE understøtter dit versionsstyrringsværktøj er lige så vigtigt som versionsstyringsværktøjet selv. Tag f.eks. hvis du bruger Eclipse og det plugin som man kan anvende til den valgte version af versionsstyrringsværktøjet ikke hænger sammen, eller at man anvender Maven (til Java) og det valgte versionsstyrringsværktøj ikke er understøttet til at lave releases med Maven - se:
http://maven.apache.org/scm/scms-overview.html
Her er et vaerktoej til at goere git nemmere ved at bruge et bestemt workflow: http://nvie.com/posts/gitflow-01-released/
Det kan maaske goere det nemmere at begynde.
Jeg har lige brugt et par uger på at migrere forskellige dele af virksomheden SCM fra svn til mercurial/hg.
Der skulle laves nye servere, kodes lidt ldap auth og laves en plugin til hudson. Alt sammen for at leve op til vores ret så specifikke krav...
Vi har nu flyttet en del projekter over, og jeg har benyttet mig at hg i et pa måneder...
Jg er blevet ret gald for det. I starten kiggede jeg også på git, som funktionelt er ret lidt hg. Git er bare lidt kryptisk, og ikke så humant som hg.
Der findes ugså en udemærket hg eclipse plugin. Det er gør der ikke til git...
Når man tænker tilbage p cvs, svn og vss(!) virker den distribuerede løsning så naturlig at det er underligt at det først er nu den vinder indpas...
Perforce har et par use cases hvor det klarer sig langt bedre end git. Den mest oplagte er hvis dit repository er et par hundrede gigabyte i størrelse og du kun vil lave partielle checkouts, har mange binære filer, etc.
http://www.kernel.org/pub/software/scm/git/docs/RelNotes/1.7.0.txt siger:
[code=text]
* "sparse checkout" feature allows only part
of the work tree to be checked out.
[/code]
Er det ikke det samme du mener?
Tag også et kik på Vesta:
http://www.vestasys.org/
Vesta er spændende fordi revisionskontrol og oversættelse er integreret i samme system. Der anvendes et funktionelt sprog til at beskrive oversættelsen med og der er et stort fokus på oversættelsen kan reproduceres med høj nøjagtighed.
[qoute]Er det ikke det samme du mener?[/quote]
Det er noget af pointen. Der er også submodules i git som gør noget i samme stil. Det du gerne vil undgå når du sidder med et repository på 500 gigabyte er at du skal have de 500 gigabyte (godt nok pakket) lokalt på din disk. Det har, traditionelt, været Perforce's styrke at man ikke behøvede dette. Bemærk at de 500G er en enkelt revision og ikke hele repo'ets historik.
Du sidder typisk med et repository på 500G+ når du laver computerspil. Selve koden er en bagatel, men det er textures, concept art, videomastering og andet i den retning ikke :)
På den anden side, så er det en use-case som andre værktøjer godt vil forsøge at gøre efter. Git er voldsomt fleksibelt, så det kan sagtens tænkes at det er blevet løst.
Vesta er spændende fordi revisionskontrol og oversættelse er integreret i samme system.
Tillad mig at provokere lidt: Kan dit foretrukne RC system garantere at de data du har på disken er konsistente? Kan du garantere der ikke er silent corruption i dine data? Git kan i begge tilfælde. Rigtigt mange systemer kan ikke.
Jeg har prøvet at undersøger markedet for versionsstyring til mainframe, men det virker ikke som om der er særligt mange versionsstyringsværktøjer til mainframe, eller også har jeg ikke kunnet finde dem. Jeg har fundet ud af at rigtigt mange mainframe huse har deres egenudviklede versionsstyring. Er der nogen har nogle goder erfaringe med off-the-shelf versionsstyring til mainframe (Cobol, copybooks, JCL, DB2 stored procs osv.)?
Helst noget der supporterer branching og parallel udvikling.
Jeg bruger git til mange forskellige projekter, og der er to ting ved det jeg især er glad for:
1) man committer i en klump. Det er et fantastisk hit fordi en ændring gerne berører flere filer, så det er mere logisk at have med at gøre
2) push-pull mekanismen er rigtigt nem at bruge.
Jeg flytter tit kode rundt mellem computere, og det er nærmest trivielt at sætte op og bruge over netværk og ssh.
Derudover er der understøttelse for git alle mulige mærkelige steder. Ikke kun som værktøj i konsollen, men også som plugin til forskellige IDE'er.
Den eneste ting jeg har fundet uhensigtsmæssigt ved git er at der ikke er forkortelser som for cvs og subversion (f.eks. ci for commit), men siden jeg ikke har brug for at skrive lige så mange kommandoer går det vel op et eller andet sted.
Min erfaring siger mig ret klart at det værktøj som giver færrest problemer er det som har den bedste værktøjsintegration.
Det er utroligt vigtigt at alle på et team kan klare alle opgaver i versionsstyringssystemet, uden at ryste på hånden. Det være sig konflikthåndtering når flere har rettet i samme fil eller merging af store og små features mellem branches.
Jeg bruger subversion med eclipse og Subclipse-plugin, og det fungerer glimrende.
Et par gode fif som gør at ingen behøver at frygte SVN:
Brug altid "Team Synchronize" view:
Klar konflikter først, herefter updates. Det er lidt mere besværligt end bare at update, men hvis der er konflikter bliver man glad for det og samtidigt har man et godt overblik over hvilke rettelser andre på projektet laver.
Vær ikke bange for at branche. Hvis man har brug for en lang commit pause, så er det nok et tegn på at man ikke har haft modet til at lave en branch.
Merging klares nu om dage som en leg med CollabNet's merge wizard.
Man kan stadig bruge kommandolinjen, hvis man har lyst. Min erfaring er bare at de fleste er mere bange for den metode og dermed er de mere bange for at lave fejl og de har sværere ved at korrekt gennemføre f.eks. konflikthåndtering og det sænker produktiviteten markant.
Git lyder interessant, men jeg gider ikke rigtigt at bruge det før det er mere produktivt end SVN eller til nød CVS (som jo tidligere havde den bedste eclipse integration).
Tillad mig at provokere lidt: Kan dit foretrukne RC system garantere at de data du har på disken er konsistente? Kan du garantere der ikke er silent corruption i dine data? Git kan i begge tilfælde. Rigtigt mange systemer kan ikke.
Jeg har lige set Linus Thorvalds git foredrag. Der er mange stærke meninger og mange gode ideer. En af de gode ideer er brugen af SHA1 checksummer til at verificere repositoriets indhold. Bestemt prisværdig feature!
Vesta er en anden historie. Der anvendes et centralt repositorie og integreret byggemiljø baseret på et funktionelt sprog. Styrken ved Vesta er dels et byg af en pakke kan reproduceres med høj præcision og dels at man kan kopiere en pakke til et andet repositorie og stadigvæk reproducere et byg af pakken med meget høj præcision.
Skal man forsimple problemstillingen man kan sige at git løser samme problemer som cvs mens vesta løser sammen problemer som cvs og make tilsammen.
Jeg ser din "provokation" mere som at fokusere på et bestemt argument fra en særdeles underholdende youtube video. Fint nok. Jeg ville nu foreslå en mere nuanceret tilgangsvinkel til sagerne. Uanset hvor godt eller dårligt et system er, vil der altid være fordele og ulemper ved det sæt af designbeslutninger som systemet repræsenterer.
Ville jeg selv bruge git? Efter at have set Linus Thorvalds præsentation vil jeg sige at jeg føler mig stærkt fristet til at se nærmere på git. Det ser spændende ud! Faktisk er den ide jeg bedst kan lide måden som man kan samarbejde på i et flerpersoners projekt. Samt at man ikke er afhængig af adgang til en central server for at arbejde.
Begyndte ligeledes med CVS, der fungerede ganske fint. Men efter en årelang pause, kom skiftet til SVN, som jeg dog aldrig blev helt dus med, men det basale virkede fint med Netbeans.
Det endte dog med at jeg kiggede lidt rundt, Bazaar, Perforce og ikke mindst Git - men der var ikke rigtigt noget der rykkede, især Git og jeg var uvenner - opgav at få skidtet til at fungere efter timers kamp.
Så kiggede jeg lidt på Mercurial og efter omkring 5 min havde jeg fået det til at køre, oprette local og remote repository og udført den første remote push i en openSSH-tunnel. Integrationen med Qt-Creator ser ud til at fungere.
Jeg vil gerne give min stemme til Mercurial, jeg synes det virker relativt simpelt og lige til (så simpelt som DVCS nu kan være)
Vi har brugt det i et par år nu, både til .NET/C# og Python projekter, works like a charm...
Desuden vil jeg anbefale bitbucket.org fra Jesper Nøhr og co.
Den eneste ting jeg har fundet uhensigtsmæssigt ved git er at der ikke er forkortelser som for cvs og subversion (f.eks. ci for commit), men siden jeg ikke har brug for at skrive lige så mange kommandoer går det vel op et eller andet sted.
man git-config eller http://www.kernel.org/pub/software/scm/git/docs/git-config.html
Søg efter alias... :-)
Den eneste ting jeg har fundet uhensigtsmæssigt ved git er at der ikke er forkortelser som for cvs og subversion (f.eks. ci for commit), men siden jeg ikke har brug for at skrive lige så mange kommandoer går det vel op et eller andet sted.
Min ~/.gitconfig indeholder bl.a.:
[alias]
co = checkout
ci = commit
st = status
Alex Holst
Jeg har har kigget på Git lige for nyligt i forbindelse med at jeg har gang i et Open Source software projekt til Ubuntu sammen med en makker fra det danske Ubuntu LoCo team.
Jeg synes at Git ser lovende ud: Jeg har læst i denne bog:
"Pragmatic Version Control Using Git" af Travis Swicegood
Bogen beskriver blandt andet et værktøj der hedder TicGit, som jeres team måske ville finde interessant.
Web siden for programmet http://github.com/shacon/ticgit/wikis fortæller:
TicGit is a simple ticketing system, roughly similar to the Lighthouse model, that is based in git. ...
The idea is that it keeps your tickets in the same repository, but without mucking up your working tree. It keeps no files in any of your working tree – it is a completely different branch in your repo.
Git-gui - som er et platform uafhængigt program, lader en udvikler gøre de mest almindelige ting i en grafisk brugergrænseflade.
Til sidst er der lige en lille historie om gits tilblivelse på h-online.com
"The saga of Git: Lightning does strike twice": http://www.h-online.com/open/features/The-saga-of-Git-Lightning-does-str...
En måde at blive venner med git på selvom i bruger svn, er at bruge git lokalt med svn som repository. http://www.kernel.org/pub/software/scm/git/docs/git-svn.html.
Man får ikke alle fordelene ved git, men det er en god måde at komme i gang på.
Ellers kan jeg kun anbefale github, hvis man kan acceptere at ens kode ligge ude af huset.
Jeg bruger selv git-svn på arbejdet. Det er ok; men man skal virkelig passe på.
Eksempel: Git er rigtig god til at flette grene. Det er svn ikke. Godt, så bruger jeg git-svn til det. Problemet er nu, at merge informationen ikke bliver overført til svn serveren. Hvis en person som nu vil lave et flet enten direkte i svn eller i en ny git-svn klon hentet direkte fra svn serveren, skal begynde forfra: Der er ingen informationer om, hvilke filer og ændringer, som allerede er flettet.
Derfor skal man vælge, om man vel flette i svn eller med git. Man må ikke blande :-(
Og så har jeg set mange problemer med filer, som er flyttet på en gren. Når jeg så fletter denne gren over i en anden med git-svn, genopstår de gamle kopier på svn serveren.
Jeg kan ikke anbefale git-svn til at evaluere git: Det vil sætte git i et alt for dårligt lys. Det er godt til lige at komme igang og få data ud af svn serveren; men så skal man tage beslutningen fuldt ud og flytte alle i projektet over på git.
git er et rigtigt godt værktøj! Den decentrale model er dog ikke uproblematisk i en organisation, hvor folk flytter mellem projekter, og det er nødvendig med en officiel udgave af et repository.
Hvis man har behov for et center i det decentrale miljø, er Gitosis et praktisk værktøj. Gitosis gør det muligt at have flere, der kan commit'e til et centralt repository, og der kan være flere administratorer til at styre gitosis.
Ellers er kombinationen af git og Subversion ikke dårligt. Man kan commit'e alt det man vil i git, men kun det, der klarer integrationstestene, bliver commit'et i SVN.
Thomas
git er et rigtigt godt værktøj! Den decentrale model er dog ikke uproblematisk i en organisation, hvor folk flytter mellem projekter, og det er nødvendig med en officiel udgave af et repository.
Helt enig. Det er en fordel at have et "blessed" repository som alle andre baserer deres arbejde rundt omkring. Hvis projektet har mange udviklere, så har du typisk et antal repositories lige under det som er "blessed" hvor hver delkomponent udvikles og stabiliseres.
Min erfaring er at man ikke bare blindt skal hive andres arbejde ind fra højre og venstre. Man skal tværtimod hive det ind som kan påvirke, eller forventes at påvirke det, som du sidder og arbejder på.
Problemet med det er så at nogen gange påvirker to ting hinanden uden at det var forventet. For at fixe dette skal man have en branch hvor man laver "cooking": samler alle ændringer som er klar til produktion og tester dem. Jo mere impact en ændring forventes at have, des mere skal den cookes :)
Ellers er kombinationen af git og Subversion ikke dårligt. Man kan commit'e alt det man vil i git, men kun det, der klarer integrationstestene, bliver commit'et i SVN.
Af ren nysgerrighed:
Hvad er årsagen til/argumentet for ikke bare at lade det centrale repository hvortil alt der klarer integrationstestene bliver pushet også være git?
Hvad giver SVN dig specielt i den sammenhæng?
Jeg mener absolut kun man skal bruge git+svn hvis man i forvejen har sine projekter i svn.
Skal man starte forfra vil jeg klart foreslå git som centralt repo.
Jeg er bare i den situation at min organisation kun lige er gået fra cvs til svn, så den er ikke moden til git. Derfor git+svn
Jeg anbefaler git frem for Subversion.
Men problemet med git alene er, at i en organisation er det tit nødvendigt med et kanonisk repository. Det er det, der bliver lavet backup af, og det er typisk administreret af en eller flere, der har ansvar for det.
Gitosis er derfor rigtig smart at bruge som det kanoniske reposistory.
Hvis organisationen ikke har helt tillid til git endnu, så kan man som udvikler stadig have gavn af git.
Thomas
Men problemet med git alene er, at i en organisation er det tit nødvendigt med et kanonisk repository. Det er det, der bliver lavet backup af, og det er typisk administreret af en eller flere, der har ansvar for det.
Det besvarer ikke mit spørgsmål.
Hvad er grunden til at det kanoniske repository ikke kan være Git?
Det besvarer ikke mit spørgsmål.
Hvad er grunden til at det kanoniske repository ikke kan være Git?
Hvis man bruger gitosis, så er det kanoniske repository et git-repository. Gitosis er et værktøj til at administrere repositories. Det er en måde at få alle fordele ved et centralt repository uden at miste det decentrale.
Thomas
Ahh... ok. beklager. Jeg fik det indtryk at du talte for en løsning med SVN som kanonisk repository fremfor git.
En cooking pot til stabilisering er en rigtig god idé til at fange bugs og udforudsete komplikationer.
Hvis man lige løfter sig lidt op over den tekniske suppe, så er der især en ting, som er glimrende ved git (eller distriburet SCM generelt). Med SVN o. lign. bruger jeg så få features, som jeg kan komme afsted med. SVN kan meget, men jeg tør ikke bruge det af frygt for, at jeg "ødelægger" noget på serveren, som så skal revertes. Med Git kan jeg tage en kopi af repo og lege lige så tosset jeg vil.
Det er killer featuren.
Ach so. Tjah, jeg må indrømme at jeg har meget at lære når det kommer til Git. Næste skridt kunne vel passende være at lave min egen dot-fil for det :)
Lige præcis..... Efter at have skiftet til at køre GIT på mit arbejde (ganske vist op mod et subversion repo) kan jeg ikke forstå at folk overhovedet tør committe.
Efter at have arbejdet med Git i halvandet års tid kommer jeg godt nok aldrig til at gå tilbage til Subversion. Ikke på vilkår. Gevinsten i brugervenlighed, hastighed og produktivitet(du kan jonglere vægtløst med branches og repositories, implementere features sømløst og uden at skulle spørge om lov at putte ting i pipeline, og generelt få arbejde fra hånden meget hurtigere og nemmere) er så stor, at jeg slet ikke kan komme med et eneste argument for at SVN skulle have en stærk side Git ikke har.
Eksistensen af Github er så bare flødebollen på toppen af isvaflen, for det er da godt nok et dejligt, intuitivt værktøj.
Det er selvfølgelig et partsindlæg lavet af en GitHubber, men http://whygitisbetterthanx.com/ er en god opsamling på alle Gits fordele.
Og som andre har nævnt, så er GitHub en fantastisk overbygning på Gits grundlæggende arkitektur.
Der er en god introduktion til Git på http://gitcasts.com/
Desværre ser det ud til at alle gitcast videoerne er nede.
Mercurial er et meget stærkt system. Startet samtidigt med Git, for at løse det samme problem, langt hen ad vejen på samme måde. Men Git blev fra starten tilpasset hardcore kerneudvikleres behov (og mentalitet) hvor Mercurial har et mere "menneskeligt ansigt". Lettere at gå til, og så er det ægte cross-platform. Hvis du kun lever på Linux og er hardcore tech, er Git sikkert glimrende. For alle andre: Mercurial. I den talk du viser siger Linux bla. at det eneste andet system han ville overveje, eller anbefale til andre, er Mercurual. Og Linus har som bekendt god smag ;-)
Merging klares nu om dage som en leg med CollabNet's merge wizard.
En ulempe jeg har fundet ifm subversion merge i eclipse's er at man merger underprojekterne en for en og ikke top directoriet.
Du kan bare vælge flere projekter ad gangen, ved at ctrl+klikke dem i package explorer.
Siden flere andre nævner Mercurial, så vil jeg da bare nævne, at Martin Geisler, som jeg er helt sikker på, at du kender fra DAIMI, er dybt involveret i det projekt, så siden du eksperimenterer med interviews, så ville han sikkert være glad for at stille op til et, og så er han samtidigt rigtigt god til at forklare - også hvis du bare spørger ham af personlig interesse :-)
