Martin Geisler

Hvilken Linux/BSD distribution anvender du i dag?

Jeg tror han mener at du kan skrive Kubuntu ind under "Other".

16. marts 2014 kl. 23:51
Hvilken Linux/BSD distribution anvender du i dag?

Hej Peter, jeg synes det vil virke bedre hvis du sortere svarmulighederne alfabetisk. Det vil også se mere neutralt ud, hvis du ikke kun bruger Ubuntu som eksempel for versionsnumrene.

16. marts 2014 kl. 23:50
Valg af versionskontrolsystem anno 2014

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.

2. februar 2014 kl. 16:09
Valg af versionskontrolsystem anno 2014

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 :)

28. januar 2014 kl. 12:25
Valg af versionskontrolsystem anno 2014

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.

27. januar 2014 kl. 17:44
Valg af versionskontrolsystem anno 2014

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.

27. januar 2014 kl. 17:38
Valg af versionskontrolsystem anno 2014

Men at kunne have flere masters, flere forks der samarbejder, er noget ekstra som kun git kan.

Nej, det er en generel egenskab ved et DVCS (distributed version control system). Mercurial, Darcs, Bazaar, Fossil kan også arbejde uden et centralt repository.

27. januar 2014 kl. 17:24
Valg af versionskontrolsystem anno 2014

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.

27. januar 2014 kl. 17:22
Valg af versionskontrolsystem anno 2014

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.

27. januar 2014 kl. 17:12
Erfaringer med Mercurial som versionskontrolsystem

Har hg det samme, eller er den ligesom de andre, der betragter hele workdir som ændringen?

Mercurial har ikke et index som standard og det fungerer altså ligesom CVS, SVN som udgangspunkt. (Man kan selvfølgelig køre hg commit foo.c bar.h for at lave et commit som ignorerer ændringer i andre filer.)

Hvis man vil have noget der ligner, så kan man bruge mq. Den extension giver dig mulighed for langsomt at bearbejde en patch (faktisk en stak af patches) og du kan tilføje ændringer til en patch lidt af gangen. Med record kan du lave partielle commits hvor du kun committer dele af ændringerne i en fil, altså i stil med git add -i.

De to extensions jeg nævner ovenfor er "standard extensions" hvilket betyder at de kommer sammen med Mercurial og får samme support som resten af Mercurial. De er blot ikke slået til som standard idet ikke alle har brug for denne funktionalitet.

På den måde er filosofien lidt anderledes i Mercurial i forhold til Git: Mercurial kommer med en lille kerne og en masse udvidelser mens Git kommer med en hel masse kommandoer fra starten.

Men hvis man kigger nærmere på implementationen af de forskellige kommandoer i Git, så vil man se at de også er bygget på den måde at de bruger Gits kerne-kommandoer -- git rebase er et shell script som bruger en håndfuld andre Git kommandoer internt. På samme måde er hg rebase et Python modul som bruger et internt API. På dem måde minder de to systemer faktisk meget om hinanden.

13. august 2012 kl. 20:43
Erfaringer med Mercurial som versionskontrolsystem

Det vil site at når noget en gang var fyldt i repository, var der absolut ingen måde at slette alle spor igen, hvis f.eks en gnaven sagfører dokumenterede at repræsentere rettighederne til Tetris.</p>
<p>Er det fixet ?

De moderne systemer (Git, Mercurial, ...) bygger alle på en model hvor indholdet i et repository bestemmer identiteten af repositoriet. Det skal forstås sådan at hvis du har et changeset med ID "41453d55b481", så er der kun én mulig historie der kan lede op til det changeset.

Med andre ord: hvis du vil slette noget fra historien, så kommer du også til at få andre changeset IDer. Det er nemt nok at gen-spille den gamle historie og udelade enkelte filer eller hele mapper: i Mercurial bruger man hg convert og i Git bruger man git filter-branch. Resultatet er i begge tilfælde et nyt repository som ikke indeholder det man har filtreret væk. Da det nye repository er anderledes vil det også have en ny identitet. Folk vil derfor blive nødt til at klone forfra.

Jeg synes ikke denne model skal fikses -- der er ganske enkelt tale om en mere striks model med langt større integritet end det de ældre systemer tilbyder.

13. august 2012 kl. 11:59
Erfaringer med Mercurial som versionskontrolsystem

Mercurials rebase fungerer på samme måde som Gits rebase og giver også mulighed for hg pull --rebase. Problemet her er at Peter vil jonglerer rundt (merge/rebase) med en dirty working copy -- noget som ikke giver mening da merge/rebase netop har brug for en working copy for at have et sted hvor man kan løse konflikter.

Det er en misforståelse at man skal merge efter at man har kørt hg pull. Man laver et merge når man har gjort sin feature færdig -- ikke når man laver en tilfældig hg pull.

Hvis man ikke er færdig med sin feature, men alligevel er helt vild i varmen for at få den nye kode integreret med det man har hevet ned, ja så kan man køre hg rebase for at flytte sin egen kode "op" efter den kode man har hentet. Her kan man eventuelt bruge hg rebase --collapse for at slå de lokale commits sammen til ét enkelt commit -- det er smart hvis man har lavet mange små commits som ikke nødvendigvis giver mening for andre og som man derfor ikke vil belemre andre med i fremtiden.

Ved at bruge hg rebase gentagne gange kan man holde sin feature branch opdateret uden at lave unødige merges. Man skal selvfølgelig stadig vente med hg rebase indtil man har en ren working copy -- man skal gøre det færdigt man er igang med før man begynder at flytte rundt på changesets.

Hvis nogen nu indvender at de har brug for de features der er i den kode der er blevet hentet og at de ikke kan køre hg commit fordi deres ting er ufærdige, ja så er det et tegn på at nogen har blandet tingene sammen på en uheldig måde. I teorien skulle du kunne lave din feature/bugfix færdig før du behøver at køre hg pull. Dermed kan du arbejde ud fra et stabilt grundlag og først bekymre dig om at merge/rebase når du er færdig med din opgave.

I praksis roder folk dog tit tingene sammen, og så kan det være rart at bruge ting som shelf til at gøre en working copy ren eller histedit til at redigere historien efter at man har lavet et "dummy" commit sådan at man kunne køre hg rebase.

13. august 2012 kl. 01:08