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:
Lad mig gennemgå resultaterne af de 382 besvarelser, hvor der er mere end tre som har svaret at de bruger samme system.
Jeg spurgte:
Et øjebliksbillede af brugen af versionskontrolsystemer viser stor udbredelse af Git og Subversion, og den gamle stjerne CVS er blegnet :-)
| Versionskontrolsystem | Antal | Udbredelsesprocent |
|---|---|---|
| Git | 146 | 38% |
| Subversion | 106 | 28% |
| Team Foundation Server | 48 | 12% |
| Mercurial | 35 | 9% |
| CVS | 16 | 4% |
| Perforce | 13 | 3% |
| IBM Rational Team Concert | 8 | 2% |
| Microsoft Visual SourceSafe (VSS) | 6 | 2% |
| Clearcase | 4 | 1% |
(klik på billedet for at få det i større udgave)
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).
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).
| Versionskontrolsystem | Udbredelsesprocent | Middel tilfredshed |
|---|---|---|
| Mercurial | 9% | 4,5 |
| Git | 38% | 4,3 |
| Perforce | 3% | 3,8 |
| Team Foundation Server | 12% | 3,6 |
| Subversion | 28% | 3,3 |
| IBM Rational Team Concert | 2% | 3,0 |
| CVS | 4% | 2,1 |
| Clearcase | 1% | 1,5 |
| Microsoft Visual SourceSafe (VSS) | 2% | 1,3 |
(klik på billedet for at få det i større udgave)
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.
| Versionskontrolsystem | Udbredelsesprocent | Usandsynligt at vi skifter | Ved ikke om vi vil skifte | Sandsynligt at vi skifter |
|---|---|---|---|---|
| Git | 38% | 93% | 7% | 0% |
| Subversion | 28% | 48% | 18% | 34% |
| Team Foundation Server | 12% | 83% | 4% | 13% |
| Mercurial | 9% | 74% | 14% | 11% |
| CVS | 4% | 50% | 19% | 31% |
| Perforce | 3% | 85% | 8% | 8% |
| IBM Rational Team Concert | 2% | 100% | 0% | 0% |
| Microsoft Visual SourceSafe (VSS) | 1% | 50% | 17% | 33% |
| Clearcase | 1% | 25% | 25% | 50% |
Resultaterne er sorteret efter udbredelsesprocent.
Kommenter gerne nedenfor.
/pto
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.
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).
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 :)
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.
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?
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?
Tada - heraf tanken om en konference :)
Bare det ikke bliver en dyr konference, så kun folk med firma i ryggen har mulighed for at komme..
Det var ikke min tanke. Der hvor jeg vakler lidt er om vi skal snakke processer og ikke bare selve versionskontrolsystemerne. Det kan blive rigtig godt, men det kræver at folk stiller sig op og fortæller om hvad man styrer sit udviklingsflow.
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 ?
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
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
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.
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.
Det er kun fordi du blander mutabilitet på forskellige niveauer sammen.
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.
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?
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
Jeg er dog lidt overrasket over at Mercurial bruger har højere tilfredshed end git.
Jeg har det som ESR - Git har vundet og der er rent praktisk ikke andet at gøre end at overgive sig. Men med hjertet ville jeg helst have at Mercurial havde vundet i stedet. Det er et godt system. Men det er svært at slå "Torvalds effekten" af banen såeh....
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.
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.
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).
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 :)
Apropos git push -f har topDatamat lavet en lille parodi! (YouTube)
Hej Poul-Henning
Så er jeg er temmelig sikker på at den er opstået som direkte konsekvens af FreeBSD's "skønhedskonkurrence" efter et nyt VCS :-)
Jeg er ked af at være så insisterende, men det passer ikke tidsmæssigt. Hvis du søger efter "freebsd obliterate" på mailinglisterne så vil du se at det første match er i 2007. Som sagt blev MQ udviddelsen startet i begyndelsen af 2006.
