Dette indlæg er alene udtryk for skribentens egen holdning.
Blogindlæg

Valg af versionskontrolsystem anno 2014

26. januar 2014 kl. 19:3442
person
Peter Toft
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.
person
Peter Toft

Jeg spurgte jer sidste uge om hvilket system I bruger til versionskontrol.
Jeg er meget taknemmelig for jeres iver i at udfylde min webform om brugen af versionskontrol. Der er 413 som har udfyldt skemaet - super flot. I dette blogindlæg vil jeg vise resultaterne.

Der er et par kommentarer til min databehandling:

  • Der er som ventet 15 besvarelser med versionskontrolsystemer som ingen andre har svaret. Eksempler er "Darcs", "Egen udbygning af UNIX SCCS" og "PVCS". De er taget ud i det følgende.
  • Jeg har også slettet enkelte hvor der var to eller tre som har anvendt det. Dvs. i det følgende er kun vist besvarelser, hvor det rammer ca 1% udbredelse.
  • Der er tre besvarelser, som anførte brug af flere systemer. De er ikke taget med nedenfor. Sorry Poul-Henning Kamp :-)
  • Der er et par besvarelser, hvor jeg har rettet stavefejl såsom "Mircosoft" -> "Microsoft". De er med i det følgende.
  • Der er 11 - dvs godt 3% - som har svaret, at de "IKKE bruger et versionskontrolsystem til software, men at de burde gøre det". Det overrasker mig, at det tal er så højt. Det kunne være interessant at debattere nedenfor.

Lad mig gennemgå resultaterne af de 382 besvarelser, hvor der er mere end tre som har svaret at de bruger samme system.

Hvilket system anvender jeres firma/projekt til versionskontrol

Jeg spurgte:

Artiklen fortsætter efter annoncen

Et øjebliksbillede af brugen af versionskontrolsystemer viser stor udbredelse af Git og Subversion, og den gamle stjerne CVS er blegnet :-)

VersionskontrolsystemAntalUdbredelsesprocent
Git14638%
Subversion10628%
Team Foundation Server4812%
Mercurial359%
CVS164%
Perforce133%
IBM Rational Team Concert82%
Microsoft Visual SourceSafe (VSS)62%
Clearcase41%

(klik på billedet for at få det i større udgave)

Tilfredshed med jeres versionskontrolsystem

Jeg bad om at I vurderede jeres system på en skala mellem 0 og 5 hvor 0 er lavest og 5 er højest.

Her viser resultaterne at "The under dog" Mercurial kommer ud med den bedste middel-score, lige efterfulgt af Git og Perforce (dog ikke særlig udbredt).

Artiklen fortsætter efter annoncen

Jobs

Dine job
Vis alle

Dårlige scores er - som I kan se - givet til CVS, Clearcase og Microsoft Visual SourceSafe (VSS) (alle tre er dog ikke særlig udbredt).

VersionskontrolsystemUdbredelsesprocentMiddel tilfredshed
Mercurial9%4,5
Git38%4,3
Perforce3%3,8
Team Foundation Server12%3,6
Subversion28%3,3
IBM Rational Team Concert2%3,0
CVS4%2,1
Clearcase1%1,5
Microsoft Visual SourceSafe (VSS)2%1,3

(klik på billedet for at få det i større udgave)

Vil I skifte versionkontrolsystem?

Jeg spurgte

Resultaterne nedenfor viser:
* Brugere af "IBM Rational Team Concert" er også meget stålfaste - de skifter ikke. Er det så godt?
* Tilsvarende for Git-brugere, som reelt ikke skifter til noget andet. Mercurial og Team Foundation Server også ret sikkert.
* Interesant er det at Subversion er på trods af stor udbredelse er truet - nok af Mercurial og især Git.

VersionskontrolsystemUdbredelsesprocentUsandsynligt at vi skifterVed ikke om vi vil skifteSandsynligt at vi skifter
Git38%93%7%0%
Subversion28%48%18%34%
Team Foundation Server12%83%4%13%
Mercurial9%74%14%11%
CVS4%50%19%31%
Perforce3%85%8%8%
IBM Rational Team Concert2%100%0%0%
Microsoft Visual SourceSafe (VSS)1%50%17%33%
Clearcase1%25%25%50%

Resultaterne er sorteret efter udbredelsesprocent.

Kommenter gerne nedenfor.

/pto

Emner
42 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Køb abonnementFå prøveabonnement

Fortsæt din læsning

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
19
Jan Gundtofte-Bruun
27. januar 2014 kl. 14:20

Jeg har misset at svare, men ville have svaret ret "negativt".

Det er nu ikke mangel på vanilje, men simpelt hen fordi man i Lotus Notes-land er så underlagt et monolitisk format at versionsstyring stort set ikke er muligt. Selv efter at Notes er gået over til Eclipse, er alle forsøg endt på revene; der findes dog ét (lidt ringe) produkt fra TeamStudio som jeg ikke begriber at Lotus ikke har assimileret for 10 år siden.

Jeg ville også have svaret blankt nej til "Skifte?" fordi det ikke er en oplagt teknisk mulighed - desværre.

Da jeg havde mulighed for at lege, blev det med Hg (Mercurial) som jeg blev ret begejstret for. Overvejer alligevel at fokusere på Git, kun fordi det er det som stillingsannoncerne efterspørger (det er vel den gamle sang om popularitet over fornuft igen, suk).

  • more_vert
    • insert_linkKopier link
18
Henrik Mikael Kristensen
27. januar 2014 kl. 13:38

Jeg ser, at Fossil ikke er nævnt. Jeg bruger den ikke, bl.a. fordi der er for meget andet bagage i den (bl.a. webserver), men jeg kender nogen der dybt sværger til den.

Er der nogen der bruger Fossil?

  • more_vert
    • insert_linkKopier link
20
Adam Tulinius
27. januar 2014 kl. 14:47

Er der nogen der bruger Fossil?

Det er et godt spørgsmål. Fossil havde for et års tid siden en grim bug, der kunne gøre et helt repository korrupt, uden anden udvej end at restore fra backup, så jeg kan nemt forestille mig at folk løb skrigende væk efter den episode.

  • more_vert
    • insert_linkKopier link
12
Poul-Henning Kamp
27. januar 2014 kl. 00:51

Git er i virkeligheden ikke er et værktøj til versionskontrol, men mere noget hen i stil med et samarbejdsværktøj til kildetekst. Git kan godt bruges til versionskontrol, men det er egentlig ikke beregnet til det.

PS: Spørgsmålet om hvorvidt folk kunne finde på at skifte er ret firkantet ? Når folk skriver at de ikke planlægger at skifte, Er det fordi de ikke vil ? Ikke kan ? Ikke må ? Ikke har råd ? Ikke kan overskue det ?

  • more_vert
    • insert_linkKopier link
15
Martin Bøgelund
27. januar 2014 kl. 11:01

Git er i virkeligheden ikke er et værktøj til versionskontrol, men mere noget hen i stil med et samarbejdsværktøj til kildetekst. Git kan godt bruges til versionskontrol, men det er egentlig ikke beregnet til det.

Jeg har tygget lidt på det udsagn, og lige frisket definitionen af versionskontrol op, men jeg kan stadig ikke helt få det til at passe.

Man kan vel ikke samarbejde (ordentligt) om kildetekst, uden at have versionskontrol - og så må Git vel også et eller andet sted have tilstrækkelige muligheder for versionskontrol indbygget, når det er rettet mod samarbejde om kildetekst? Og så er Git vel også beregnet til det?

Jeg kender ikke Git i praksis, men lidt til DVCS på teoretisk plan, og har ellers kun haft fornøjelsen af CVS.

  • more_vert
    • insert_linkKopier link
16
Poul-Henning Kamp
27. januar 2014 kl. 11:31

OK, tid for en historielektion:

Alle andre VCS'er end git arbejder med en "officiel" versionssekvens, i langt de fleste tilfælde omkring et centralt "master" repos.

I midten af 1990'erne begyndte vanvittige mennesker med alt for meget diskplads (Læs: Sådan nogen som os i FreeBSD) at arbejde med decentrale repos-kopier, men der var stadig en officiel "master".

Kopieringen fra master til kopier voldte uendeligt meget besvær, bla. fordi det til at begynde med foregik over email, se f.eks den "CTM" -- Cvs Through Mail -- jeg skrev.

Senere da folk kom online blev rsync populær, men den kopierer bare filer og du kan ikke have lokale ændringer, hvilket var utroligt upraktisk for udviklere der vedligeholdte lokale versioner af FreeBSD.

Min gode ven John Polstra besluttede sig for at løse problemet og skrev "CVSUP" -- "CVS UPdate" som forstod CVS's repoformat, bedre end CVS selv og som kunne finde ud af at flytte ændringer fra master til slave repos, uden at trampe på noget og uden at smadre lokale rettelser der ikke konfliktede.

Der var dog den lille detalje at han skrev det i Modula-3 ("For at prøve et ny sprog") og det gjorde portering til nye platform til et helvede: Først threading, så Modula-3 og så kunne du lave et lokalt CVS.

Men modellen er stadig at du har et master repos, som definerer den endegyldige sandhed for alle i hele netværket.

Git gik skridtet videre: Git er (stort set kun) et værktøj der på smart vis kan flytte rettelser imellem repositories.

I Git er der er ikke noget "master" repository der har monopol på en endegyldig sandhed, hvert repos har sin egen sandhed og fordi den bruger MD5 hash frem for versionsnumre kan git holde skæg og snot adskilt, næsten uanset hvad der foregår i de enkelte repos.

Selvfølgelig kan du udnævne et repo til "master" men det eneste der er sket er at du har sat en label på det, der er ingen anden forskel.

Derfor mener jeg ikke at Git er et VCS, for folk har nogle forventninger til et VCS som Git simpelthen har kastet overbord: En central sandhed med en monotont fremadskridende tidslinje.

  • more_vert
    • insert_linkKopier link
23
Martin Geisler
27. januar 2014 kl. 17:12

Alle andre VCS'er end git arbejder med en "officiel" versionssekvens, i langt de fleste tilfælde omkring et centralt "master" repos.

Undskyld, men det er kun... en halv sandhed. Der er flere forskellige systemer der ligesom Git ikke har et centralt master repository. Jeg er enig i at Git er det dominerende system i dag, men det er langt fra det eneste.

Monotone var et af de foerste decentraliserede systemer og var delvist inspiration for i hvert fald Git. Git og Mercurial blev begge startet af Linux-kerneudviklere (Linus Torvalds startede Git, Matt Mackall startede Mercurial) i 2005 da de udviklerne mistede adgangen til BitKeeper -- et andet decentraliseret system som de havde brugt indtil da.

  • more_vert
    • insert_linkKopier link
22
Pauli Østerø
27. januar 2014 kl. 15:45

I Git er der er ikke noget "master" repository der har monopol på en endegyldig sandhed, hvert repos har sin egen sandhed og fordi den bruger MD5 hash frem for versionsnumre kan git holde skæg og snot adskilt, næsten uanset hvad der foregår i de enkelte repos.

Hvordan er det forskelligt fra hvad der foregår med Mercurial (hg)?

Jeg har ikke noget imod Git, bruger det selv fra tid til anden men er ked af ikke at have fundet et ordenlig Windows klient. Bruger til dagligt TortiseHG op imod en Kiln Harmony backend som udstiller ens repositories som både Git og Hg så hos os er al snak om religionskrig endegyldigt forbi.

Jeg hører dog ofte snak om at Git er det eneste rigtige, men spørger man ind til hvad det er folk er glade for ender snakken oftest på Github. Det er som at høre Javascript vs Jquery snakken om igen. Folk er glade for det "social coding" som Github faciliterer og så bekymrer de sig mindre om hvilket DVCS der ligger til grund for det.

  • more_vert
    • insert_linkKopier link
26
Poul-Henning Kamp
27. januar 2014 kl. 17:28

Hvordan er det forskelligt fra hvad der foregår med Mercurial (hg)?

Sidst jeg kiggede på mercurial, og det er nogle år siden, havde de taget den anden approach og brugte stærk krypto til at sikre at ting blev sidende hvor de en gang var sat.

Det var det der forhindrede FreeBSD i at adoptere Mecurial, for vi har gentagne gange haft situationer hvor vi var nødt til at fjerne noget helt fra vores repo, når folk havde committet noget der ikke var licens til.

Hg magtede simpelthen ikke den operation ("Obliterate") fordi det ville knække deres crypto-chain og dermed skære repos i to stykker.

Det er på samme tid en værdifuld ting ("vi kan bevise at der ikke er fusket med repo") men også en ulempe ("Vi har brug for at lave kirugi på repo")

Jeg tror nok vores forklaring var en øjenåbner for dem dengang, men jeg ved i hvilket omfang de har gjort noget ved det.

  • more_vert
    • insert_linkKopier link
29
Sune Marcher
27. januar 2014 kl. 17:54

Sidst jeg kiggede på mercurial, og det er nogle år siden, havde de taget den anden approach og brugte stærk krypto til at sikre at ting blev sidende hvor de en gang var sat.</p>
<p>Det var det der forhindrede FreeBSD i at adoptere Mecurial, for vi har gentagne gange haft situationer hvor vi var nødt til at fjerne noget helt fra vores repo, når folk havde committet noget der ikke var licens til.

Du har vel det samme problem i Git - det er muligt at lave kirurgi på Git repos, men det ændrer (naturligvis) på alle SHA-1 hashes efter det kirurgiske indgreb, og eftersom et Git commit refereres til netop via dens hash, har det... interessante... følger for kollaboration når du pusher kirurgiske indgreb.

Hvad mener du med at Hg bruger "stærk krypto", i modsætning til Git? At Mercurial ikke er så glad for history rewriting er vist mere en filosofisk beslutning, end noget der har med "stærk krypto" at gøre - begge bruger SHA-1, og giver mulighed for at GPG-signe commits. Eller er der noget jeg har overset?

  • more_vert
    • insert_linkKopier link
30
Poul-Henning Kamp
27. januar 2014 kl. 18:14

Hvad mener du med at Hg bruger "stærk krypto", i modsætning til Git? At Mercurial ikke er så glad for history rewriting er vist mere en filosofisk beslutning,

Det var helt klart en filosofisk blokering for dem dengang men jeg fik også indtrykket at det ikke kun far filosofisk, at det ville bryde antagelser over det hele hvis der blev lavet om på noget nede i historien.

Hvis de har skiftet filosofi er det en god ting: Det sidste man har brug for er at skulle slette hele sit repos fordi en sagfører har en dommerkendelse om Tetris.

Og ja, git har fundamentalt set samme problem, men tydeligvis ikke den samme ortodokse holdning som Hg udviste.

Jeg kender ikke nutidig Hg godt nok til at afgøre om det også bør klassificeres som "group-ware" på lige fod med Git.

  • more_vert
    • insert_linkKopier link
38
Martin Geisler
28. januar 2014 kl. 12:25

Det var helt klart en filosofisk blokering for dem dengang men jeg fik også indtrykket at det ikke kun far filosofisk, at det ville bryde antagelser over det hele hvis der blev lavet om på noget nede i historien.

Nej, det er altså ikke rigtigt. Mercurial har haft en fuldt supporteret standard-extension (MQ) siden 2006 som man kunne bruge hvis man ville lave om på historien. Der er ikke noget hokus-pokus ved det: når man ændrer på historien, så opbygger MQ en ny historie og smider den gamle væk.

Det som du måske blander det sammen med er at Mercurial kun lader dig akkumulere historie på en central server. Sagt anderledes, "hg push" er ikke destruktiv, den kan kun tilføje historie på den server man skubber til.

Det vil sige at det er lidt besværligt for mig "ændre" noget som jeg allerede har skubbet ud til en server -- jeg skal først slette den gamle kopi af mine commits fra serveren (køre "hg strip" på serveren). En side som Bitbucket understøtter det: jeg kan gå ind i deres webinterface og sige at jeg gerne vil have slettet visse commits. Men det er bestemt ikke noget man gider gøre hver dag. Her er det nemmere med Git: "git push -f" kan bruges til at "overskrive" ting man allerede har pushet. I virkeligheden bliver det ikke overskrevet, men ens branch pointer kommer til at pege på den nye version.

Det er stadig noget rod i Git at lave "git push -f" hvis folk kan have brugt de gamle commits som basis for deres arbejde. I Mercurial arbejder vi faktisk på at løse dette problem: http://mercurial.selenic.com/wiki/ChangesetEvolution

Kort fortalt vil Mercurial ligesom Git også begynde at akkumulere commits på serveren naar man pusher efter "hg commit -amend" eller "hg rebase". Men de nye commits vil have tilknyttet metadata som fortæller Mercurial at de er en nyere version af de gamle commits. Denne feature er stadig eksperimentel, men jeg har brugt den i mere end et år det meste fungerer som det skal :)

  • more_vert
    • insert_linkKopier link
31
Peter Mogensen
27. januar 2014 kl. 19:08

Jeg kender ikke nutidig Hg godt nok til at afgøre om det også bør klassificeres som "group-ware" på lige fod med Git.

Jeg må indrømme at jeg finder din skelnen mellem VCS'er og "group-ware" ret akademisk. Man kan også lave om på SVN's historie hvis man lyster. Det er bare ikke nemt.

Jeg har svært ved at se at det gør nogen praktisk forskel. Hvis Git ikke er et VCS, men "et samarbejdsværktøj til kildetekst", så må jeg indrømme at det jeg i praksis ønkser mig at mit VCS er at det er et "samarbejdsværktøj til kildetekst".

Hvis man ønsker en kanonisk version, så udnævner man en reference i et enkelt repo til det. (ala "Linus' tree"). Der findes i øvrigt SVK, der er distribueret SVN.

  • more_vert
    • insert_linkKopier link
35
Peter Mogensen
27. januar 2014 kl. 19:47

SVN er helt klart den klassiske "central repo med den ophøjede sandhed" model og derfor slet ikke sammenlignlig med git IMO.

Det er vi helt enige om ... men derfra og til at konkludere at kun ting, der gør det besværligt ikke at have "central repo med den ophøjede sandhed" er VCS'er ...

Det er jo ikke fordi Git forhindrer dig i at have et centralt repo med ophøjet sandhed... faktisk så bliver det svært at pege på et Open Source projekt hvor der er ikke er et git-repo, der er lidt mere ophøjet end de andre.

  • more_vert
    • insert_linkKopier link
37
Peter Mogensen
27. januar 2014 kl. 21:08

Hvis datamodellen ikke kræver et centralt master-repos, er det meget mere end et VCS

Vi er skam helt enige om at ting som Git er "meget mere end (f.eks.) SVN" ... forstået på den måde at man kan opfatte det man kan med Git som et superset af SVN's funktionalitet.

Men så er min pointe vist blot at efter at have stiftet bekendtskab med Git, så er det det superset jeg ønsker mig af et VCS. (og er nok ikke personligt længere særligt interesseret i subset'et).

  • more_vert
    • insert_linkKopier link
28
Martin Geisler
27. januar 2014 kl. 17:44

Sidst jeg kiggede på mercurial, og det er nogle år siden, havde de taget den anden approach og brugte stærk krypto til at sikre at ting blev sidende hvor de en gang var sat.</p>
<p>Det var det der forhindrede FreeBSD i at adoptere Mecurial, for vi har gentagne gange haft situationer hvor vi var nødt til at fjerne noget helt fra vores repo, når folk havde committet noget der ikke var licens til.</p>
<p>Hg magtede simpelthen ikke den operation ("Obliterate") fordi det ville knække deres crypto-chain og dermed skære repos i to stykker.

Måske snakker du om noget andet, men Git opfører sig på samme måde her. Med det mener jeg at man heller ikke kan ændre på forhistorien i Git uden at skulle gen-beregne alle efterfølgende commit hashes og dermed faar man et "nyt" repository.

I Mercurial kan man bruge "hg convert" med et "file map" hvis man vil omskrive historien så visse filer bliver fuldstændigt udeladt. I Git bruger man "git filter-branch" for at opnå det samme.

  • more_vert
    • insert_linkKopier link
24
Martin Geisler
27. januar 2014 kl. 17:22

Hvordan er det forskelligt fra hvad der foregår med Mercurial (hg)?

Det er ikke anderledes — Mercurial, Bazaar og andre DVCS'er fungerer på sammen måde. De bruger i øvrigt ikke MD5 men SHA-1 når de skal identificere et commit.

Jeg er Mercurial-udvikler og kan selvfølgelig godt lide den måde Mercurial fremstiller tingene på. Jeg er fornylig begyndt at bruge Git på mit arbejde og det er... anderledes :) Ting som jeg synes er nemme i Mercurial er pludselig besværlige og anderledes — og folk som er vant til Git vil sige det samme om Mercurial.

Der er skrevet meget om forskellene mellem de to systemer. Det er min mening at de er meget mere ens end de fleste tror. Jeg skrev lidt om det i en anden diskution.

  • more_vert
    • insert_linkKopier link
21
Allan Jensen
27. januar 2014 kl. 15:06

Det er vel fordi at GIT er lavet generelt nok til at udviklerne kan lave deres egne regler. At kunne udnævne en master er vel ikke noget problem, det er kun en simpel beslutning. Men at kunne have flere masters, flere forks der samarbejder, er noget ekstra som kun git kan.

  • more_vert
    • insert_linkKopier link
6
Lars Dybdahl
26. januar 2014 kl. 22:01

Det ville have været interessant at se mere om anvendelsen. Hos os er der fx nok 20% ikke-programmører blandt brugerne. Det kunne også være interessant at se noget om hvordan brug af versionsstyring interfacer til QA. Hvem brancher? Hvorfor brancher de? Er sourcekoden i syntesefasen eller vedligeholdsfasen? Hvad er teamstørrelsen? Er det Open Source eller company secret kode?

  • more_vert
    • insert_linkKopier link
13
Kim Henriksen
27. januar 2014 kl. 09:26

Faktisk med dyr mener jeg symbolsk beløb eller ligefrem gratis, jeg er fattig mand pt., men jeg er utrolig interesseret i at lære mere om emnet, og især i forhold til team samarbejde

  • more_vert
    • insert_linkKopier link
5
Slettet bruger
26. januar 2014 kl. 21:47

Lidt interessant undersøgelse.

Må indrømme, jeg er lidt overrasket over at se, at subversion stadig er så udbredt, og mere end Mercurial, men med den nye version 1.8.5 er der også fikset mange af de ting, som folk har kritiseret, om end jeg ikke selv har prøvet den endnu: merge skulle være blevet temmelig problemfrit, og der er hastighedsforbedringer. Hvis det også bliver nemt at synkronisere mellem 2 repositories, så er der for mange brugere mindre grund til at skifte til et distribueret system.

Vel, til mindre projekter må jeg indrømme, at patches stadig er nemmere at bruge end nogen af systemerne. Til de fleste andre projekter, bruger jeg Darcs som hemmeligt våben, dvs. alt lokalt arbejde laves i Darcs, og først til sidst committes i Git eller hvad der nu bruges, og en bro til Git kan også bruges, hvis det er nødvendigt med mere end et par commit.

  • more_vert
    • insert_linkKopier link
14
Sune Vuorela
27. januar 2014 kl. 10:58

Må indrømme, jeg er lidt overrasket over at se, at subversion stadig er så udbredt

Der hvor jeg er bruger vi primært et mix af subversion og git. Ting i git er generelt kildetekst og lignende, hvor "dataklodser" ryger i subversion.

Til det sidste er der ingen planer om at skifte til et distribueret versionsstyringssystem - simpelt hen fordi der for den type data ikke i samme grad er behov for branching/merging eller for at have historikken lokalt. F.eks. excel-filer, databasedumps og binære klodser er ret dårlige til at blive sammenflettet af f.eks. git.

Jeg mener bestemt at til nogen ting har centraliserede versionsstyringssystemer stadig deres force. Men ikke til min kildetekst.

/Sune

  • more_vert
    • insert_linkKopier link
1
Peter Mogensen
26. januar 2014 kl. 20:19

Jeg er dog lidt overrasket over at Mercurial bruger har højere tilfredshed end git. Måske pga. "learning-curve" ???

Til gengæld er det klart at der er bare generelt større tilfredshed med de "distribuerede" VCS.

PS: Personligt har jeg praktisk erfaring med CVS, SVN, Perforce, Mercurial og Git. Til daglig er det i dag dog kun SVN, Mercurial og git jeg er i kontakt med.

  • more_vert
    • insert_linkKopier link
34
Pauli Østerø
27. januar 2014 kl. 19:47

Jeg har det som ESR - Git har vundet og der er rent praktisk ikke andet at gøre end at overgive sig.

IMO så er det Github der har vundet over Bitbucket. Der skal heller ikke så meget til, det site har desværre ikke udviklet sig meget i den sociale retning.

Det havde dog været dejligt om Github understøttede Hg repositories, på samme måde som Kiln Harmony ikke skelner mellem de to. Som firma ligger vores repositories slet ikke offentligt så at skulle overveje Git på grund af Github giver ikke mening.

Eller også skal TortoiseGit bare op på niveau med TortoiseHg. Nu hvor de to systemer er så ens, burde det også være muligt at lave en god Windows klient til Git.

  • more_vert
    • insert_linkKopier link
2
Casper Bang
26. januar 2014 kl. 20:43

Jeg er dog lidt overrasket over at Mercurial bruger har højere tilfredshed end git. Måske pga. "learning-curve" ???

Læste engang hvordan Git er MacGyver imens HG er James Bond. Det uheldige ved Git er vel det ikke har den mest konsistente eller simple bruger-grænseflade. F.eks. ser Git ved første øjekast ud til, modsat så mange andre, at omfavne mutability (Git's commit amend, reset, rebase osv. ændrer på historikken) og det kan forvirre en del når nu man ved at inderst inde, er Git immutable (SHA-1 hashes).

  • more_vert
    • insert_linkKopier link
3
Peter Mogensen
26. januar 2014 kl. 21:13

Det uheldige ved Git er vel det ikke har den mest konsistente eller simple bruger-grænseflade.

Well... ja. Men af alle mulige andre grunde end det du angiver nedenfor.

F.eks. ser Git ved første øjekast ud til, modsat så mange andre, at omfavne mutability (Git's commit amend, reset, rebase osv. ændrer på historikken) og det kan forvirre en del når nu man ved at inderst inde, er Git immutable (SHA-1 hashes).

Det er kun fordi du blander mutabilitet på forskellige niveauer sammen. Du kan ikke få andre SHA1'er ud af den historie dit git repo har, men det står dig frit for at lave historien om inden du forsøger at dele den med andre. (og efter, hvis du elsker kaos)

Jeg har hørt et par github ansatte undervisere sige at det er nødvendigt at have en smule forståelse for gits interne virkemåde for at forstå det og jeg er tilbøjlig til at give dem ret. Men når man har det, så står det hele også pludselig meget klart.(*)

Nu skel det siges at min erfaring med Mercurial begrænser sig til at være "klient" til nogle Open Source projekter, der bruger det som repo. Men mit indtryk fra dem er at de (forhåbentlig) ikke bruger det som det var tænkt.

*: Nu vil mine kollegaer, som jeg plejer at plage om git-hjælp sikkert smile i skægget, men en ting er at vide hvordan man ønsker at manipulere git-DAC'en ... en anden ting er vide hvordan man gør det uden magiske kommandoer :)

  • more_vert
    • insert_linkKopier link
27
Martin Geisler
27. januar 2014 kl. 17:38

Ja og det har ikke i samme grad været muligt med HG, hvilket var min pointe. Dog har jeg efterfølgende min oprindelig kommentar set, at HG 2.2 tilføjer --amend funktionalitet lige som Git.

Ja og nej... :)

Mercurial fungerer grundlæggende på samme måde som Git: commits får en identitet ud fra en SHA-1 hashværdi som beregnes ud fra indholdet af det commit (aendringerne, dato, brugernavn, og commit-hash for working copy parent revision). Det giver et fint rekursivt træ hvor hvert commit hash fastlægger hele historikken tilbage til roden. Man kan altså ikke ændre noget uden at faa en ny hashværdi — præcis som i Git. For at "ændre" noget må man skabe en ny historie og så slette den gamle (i begge systemer).

I modsætning til Git har Mercurial indtil version 2.2 delegeret kommandoer som "ændrer" historie til ekstensions. Mercurial kommer med mere end 30 extensions/plugins som man kan slaa til hvis man vil. De er fuldt supporteret ligesom resten af Mercurial, men de indeholder funktionalitet som ikke alle har brug for (såsom integration med Bugzilla) eller gider bruge (farver i terminalen).

Vi har siden 2006 haft support for at "ændre" i historien med den såkaldte MQ extension. Det er en avanceret udvidelse som giver folk rig mulighed for at skyde sig selv i foden :) Men den giver et kraftfuldt interface til at lave om på historien.

Vi har siden fået bedre interfaces: "hg rebase", "hg commit --amend", "hg record", og endelig "hg histedit". Disse mere moderne kommandoer gør det nemmere at rydde op foer man sender sine commits ud til andre.

  • more_vert
    • insert_linkKopier link