Vil du være med til at forme en konference om versionskontrol?

Fantatisk idé.
Jeg vil gerne høre mere fra folk, der har brugt Git sammen med Visual Studio og sammen med XCode. Hvordan har Microsoft/Apple klaret integrationen ?

Hos SuperUsers har vi i et års tid haft et Git begynder.
Modsat min forventning, så har vi oplevet meget lidt interesse for kurset.

Hvorfor kan man kun checke et VCS ?

Nogen af os bruger mange forskellige afhængig af hvad vi arbejder på...

Eller gør som jeg.. vælg other og skriv at du bruger flere...

Tjoe... måske.

Jeg må indrømme at jeg tidligere fandt det mægtigt interessant, fordi der var så store udfordringer med at få workflow til at glide med sådan noget som CVS, Subversion, Perforce...

Men efter at have skiftet til git har jeg egentlig fornemmelse af ikke at behøves lede så meget efter et bedre VCS.

Det er ikke længere versionskonktrolsystemet, der står i vejen for et gnidningløst workflow.

P.S. Sidetrack: Hvad bruger I Windows-udviklere som versions-kontrol system?

En del bruger desværre stadig TFS, men MS har set skriften på væggen med integration til Git i Visual Studio og understøttelse af Git repos på visualstudio.com. Dem der ikke drikker TFS saften bruger vel ca. den samme blanding af SVN, Git og andet som alle andre.

TFS anvendes af rigtigt mange Visual Studio udviklere. Der er både en private hosted og via Visualstudio.com.

Det kunne være godt hvis der ville være nogle indlæg om "alternative" anvendelse af VCSer. Jeg har f.eks. set at en telco-firma brugte CVS til at holde styr på configuration af 100+ routere.
Jeg har for et par år siden også seriøst overvejet at bruve Subversions WebDAV interface sammen med Windows' WebDAV filesystem. Det var forde en del dokumentationsfolk ønskede at have versionering på deres filer (som var en skøn blanding af Word-, screendump-, XML- og Framemaker filer).

jeg bytter/har benyttet cvs/svn og Clearcase. Fint og godt til kodebrug.
De største kvaler ser jeg ofte mht. dokumentation. Det er ofte en anden afdeling i huset, der står for dokumentation. Her benyttes ofte Microsoft Sharepoint eller et eller anden andet kommercielt dokumentstyringsværktøj.
Jeg manger endnu at se et af disse værktøjer der kan håndtere ikke linære udviklinger af dokumenter.

Altså et hovedprodukt med et utal af forgreninger med kundetilpasninger.
Hvordan får man dokumentationen opdateret når man baseopgraderer et kundetilpasset produkt med nyeste base fra hovedgrenen?
Her er der ofte ufatteligt lidt hjælp fra værktøjerne...
En eneklt gang kom jeg igennem med at lave denne dokumentation i Latex og håndteret sammen med kildekoden. LaTeX kan flettes i modsætning til Microsoft Word.
Men oftest er kravet sat udefra og ikke af softwareafdelingen.
Hvad gør I for at løfte dokumentationsversioneringen oppe på samme høje niveau som vi programmører har gjort med cvs, svn, clearcase eller lignende?
I erhvervslivet har jeg set kildekodehåndtering er gået fra "gemt på en netværksharddisk" til "håndteret i et versionskontrolsystem med træstruktur". De folk, der har tekstbehandlingsprogrammet som hovedarbejdsredskab er tilsyneladende ikke nået lige så langt i løbet af de sidste 20 år. De kan stadig ikke forgrene og flette.

På mit arbejde (Edlund A/S, ca. 200 udviklere) skiftede vi fra CVS til Mercurial for nogle år siden og det har fungeret ret godt. Vi måtte i den forbindelse contribute en del kode for at få den transaktionelle sikkerhed forbedret på Windows (alting er jo desværre anderledes, og ofte dårligere på Windows), og forbedre understøttelse for branches.

På daværende tidspunkt syntes Git slet ikke at være en brugbar løsning, da det performede dårligt på Windows og vi har mange, ret store, repositories. Jeg ved ikke så meget om Git på Windows i dag, men Mercurial har specialkode til Windows til fx at enumerere directories, da "stat"-metoden fra *nix performer elendigt på Windows.

Desuden er det nemt at lave extensions og hele overbygningen til Mercurial i Python, hvilket vi har brugt til at lave en slags forest-system til at håndtere vores lidt specielle workflows omkring samlinger af repositories. Der har været en del arbejde i det, alt i alt, men vi vurderer at det ikke havde været mindre ved brug af alternativer; til gengæld kunne det nemt have været sværere at tilpasse.

Det kunne være en god ide med en konference, men hvad skulle temaet være og hvilke slags speaks havde du forestillet dig, skal vi snakke vcs'er eller processor?

Jeg er meget enig med de ovenstående kommentarer om at de nye vsc systemer ikke mere er problemet, det jeg ser i hverdagen (som tool konsulent) er mere folk ikke har set de nye værktøjers kunne, eller har misforstået processer, som fx. CI, branching, etc. Så jeg ville mene at det måske nok er mere disse ting man burde havde fokus på, alternativt skulle man kort lægge de vigtigste problemstillinger i vcs'er i dag og hvordan de håndteres i de forskellige værktøjer. Det kunne fx. komponenter eller dokument styring, jeg har endnu ikke set en god løsning på dette problem. dog påstås det at Mercurial kan med hjælp af plugin'et ZipDOc men jeg har dog aldrig selv set det.

Hej,

dejligt at se, at der også er interesse for versionskontrol (og hvordan det kan understøtte samarbejdet i et team?) i Danmark.

Jeg har i en del år her i Lund (Sverige) organiseret den skandinaviske SCM-dag som har et lidt bredere konfigurationsstyringsfokus, men også har haft versionskontrolting med:

http://snescm.cs.lth.se/Common/SCM-day/index.html

Jeg kører også et 7.5 ECTS universitetskursus i konfigurationsstyring, hvor der er nogle tool labs og en del sager som er relaterede til versionskontrol:

http://fileadmin.cs.lth.se/cs/Education/EDAN10/

Jeg kommer meget gerne og fortæller noget om:
- arbejdsmodeller
- branchingstrategier
- Wayne Babich tre problemer

I er selvfølgelig også hjerteligt velkomne på denne side af Sundet.

Med venlig hilsen
Lars Bendix

Under Multimedia Design uddannelsen startede jeg med at dykke ned i git, faktisk før jeg skulle røre SVN til publishing af WordPress plugins.

Jeg havde også æren af at skrive en lille håndbog om GitLab for en tech forlag (PACKT) i det sidste år.

Det er lidt underligt at forestille sig hvordan versionsstyring var før git, men jeg er meget glad for det og tracker min udvikling og en gang imellem eksamensopgaver med det.

Siden jeg er stor open source fan ville jeg være super glad for en konference og måske få et par nye udviklere til at sende pull requests til deres favoritprojekter på github eller lignende.

Continuous Intergration ville også være et super supplement på emnelisten! (Travis, Jenkins, etc)

Vi er nok der henne i dag, at der er mange gode værktøjer at vælge i mellem. Udfordringen som jeg ser den, er at når man arbejder i en større gruppe, så vil kun et fåtal forstå de finere detaljer i versionsstyringen og de snubler nemt, hvis de forsøger at lave noget advanceret. Så Clearcase og git kan helt sikkert være superbrugernes favoritter, men ikke nødvendigvis den store gruppe af medarbejdere, der 98% af tiden laver simpel linær programudvikling. Et simplere versionkontrlværktøj, der understøtter de fleste medarbejderes arbejde perfekt, men kræver lidt mere af superbrugerne kan være at foretrække.

Det kunne være interessant med indlæg omkring, hvordan man arbejder med eksisterende git/Mercurial repos ifbm kode, der ligger i non-git TFS repos.

Der er mange af os, der arbejder i organisationer, hvor IT har defineret for os, at TFS er værktøjet vi skal bruge. Men hvis man gerne vil bruge ens egen git-installation ... sammen med koden i TFS, hvordan gør man så det?

Jeg kan kun nikke genkendende til problemet.
Processerne skal være på plads - ellers kan verdens bedste versionsstyringssystem ikke hjælpe. Så det er processerne som sætter kravene til VCSet. Det er det, som mange git/bitkeeper/mercurial/perforce/tfs/subversion/cvs-fortalere overser.

F.eks. hvis man arbejder med produkter fra Progress så er deres Roundtable produkt måske det bedste valg. Eller hvis man har een (1) enhed/gruppe som tagger/tester/releaser så er evt. multi-master support i VCSet og dets tilhørende cognitive overhead spildt.

Det kunne være interessant med indlæg omkring, hvordan man arbejder med eksisterende git/Mercurial repos ifbm kode, der ligger i non-git TFS repos.

Der er mange af os, der arbejder i organisationer, hvor IT har defineret for os, at TFS er værktøjet vi skal bruge. Men hvis man gerne vil bruge ens egen git-installation ... sammen med koden i TFS, hvordan gør man så det?

Kan du ikke bruge https://github.com/spraints/git-tfs

Et simplere versionkontrlværktøj, der understøtter de fleste medarbejderes arbejde perfekt, men kræver lidt mere af superbrugerne kan være at foretrække.

Hmm... det afhænger sandelig af den kontekst du udvikler i.
Nogen steder tror jeg det betragtes som en selvfølge at alle er det du kalder "superbrugere".
Jeg er helt med på at mange steder (hvor det f.eks. ikke er software, der er produktet, men f.eks. litteratur) vil være en fordel ikke at belemre tekst-forfattere med git's kompleksistet... men i mange IT-firmaer tror jeg det forventes at alle kan bruge versionskontrol-systemet - også når det er git.

Jeg skrev tidligere at jeg (efter git) ikke længere anså versionskontrol systemet for at være det der spændte ben. Faktisk så har jeg en kraftig følelse af at git er VCS "done right" - sammenlignet med mine tidligere erfaringer med CVS, SVN, Perforce.
(I en sådan grad at det ikke længere rigtig interesserer mig hvad der måtte være af problemet med de "gamle systemer".)

Men det betyder selvfølgelig ikke at der ikke længere er policies for work-flow, der er værd at blive klogere på. Det er bare rimelig givet at git sætter præmisserne helt anderledes for det end de gamle systemer.
Det betyder heller ikke at der ikke dagligt er ting, man slås med. Men det er sjældent gits skyld.
I dag har jeg f.eks. endnu engang haft bøvl med et evigt tilbagevendende problem når Debians pakke-format, GNU autotools og git skal forsøge at arbejde sammen om patches. (jeg hader når patch-filer modificerer autogenerede filer).
... Og jeg er ret sikker på at jeg kan frikende git fra at gøre noget forkert.

Det undrer mig lidt, at der tilsyneladende ingen reaktion er på Lars Bendix' tilbud om deltagelse. Har folk forstået hvem han er, og hvad han beskæftiger sig med? Hvis der er nogen der er relevant for sådan en konference, er det ham...

Hej Mogens,

tak for de venlige ord. Det er såmænd let at finde ud af hvem Lars Bendix er. Google fortæller at han er konservativ byrådspolitiker i Odense og/eller importerer kaffe fra Uganda ;-)

Jeg havde egentlig ikke forventet anden reaktion på mit indlæg end at når/hvis det bliver til en "konference", så var der nogen som måske tog fat i mig hvis de mente jeg havde interessante ting at berette om.

Lige nu ser det ud til at folk stadig diskuterer versionskontrol og værktøjer. Set fra mit (akademiske) synspunkt, så er selve værktøjerne ikke så interessante. Efter min erfaring så vil et simpelt værktøj som CVS være tilstrækkeligt for op imod 80% af dem der har behov for versionering. Det er straks mere interessant hvordan man anvender sit værktøj. Derfor vil jeg hellere snakke processer og (sam)arbejdsmodeller end git og svn. Men sådan er vi jo så forskellige.

Trevlig helg!

---lars

Lige nu ser det ud til at folk stadig diskuterer versionskontrol og værktøjer. Set fra mit (akademiske) synspunkt, så er selve værktøjerne ikke så interessante. Efter min erfaring så vil et simpelt værktøj som CVS være tilstrækkeligt for op imod 80% af dem der har behov for versionering. Det er straks mere interessant hvordan man anvender sit værktøj. Derfor vil jeg hellere snakke processer og (sam)arbejdsmodeller end git og svn. Men sådan er vi jo så forskellige.

Jeg har lurepasset lidt i denne debat, netop fordi jeg fandt det lidt for værktøjsorienteret og programmeringsfikseret.
Den bredere konfigurationsstyringstilgang, kunne godt gøre sådan en konference en hel del mere interessant for mig.

Det er straks mere interessant hvordan man anvender sit værktøj. Derfor vil jeg hellere snakke processer og (sam)arbejdsmodeller end git og svn. Men sådan er vi jo så forskellige.

Nu ved jeg jo ikke om det er bl.a. mine indlæg du tænker på men i så fald, så tror jeg du har misforstået dem.
Jeg er (som jeg også mener at have skrevet) helt enig i at det ikke er værktøjerne, men processer og workflows, der er interessante.

Jeg har bare også den pointe at nogen værktøjer sætter helt andre præmisser for workflows end andre.
(og navnlig mener jeg at git har ændret landskabet så meget at det for mig personligt ikke er så interessant at se på hvad man gør ellers).

Som eksempel kan nævnes hele modellen omkring github og "Fork me on github". Jeg har meget svært ved at se hvordan den samarbejdsmodel, der lægges op til der er praktisk med f.eks. CVS.

Lige nu ser det ud til at folk stadig diskuterer versionskontrol og værktøjer. Set fra mit (akademiske) synspunkt, så er selve værktøjerne ikke så interessante. Efter min erfaring så vil et simpelt værktøj som CVS være tilstrækkeligt for op imod 80% af dem der har behov for versionering. Det er straks mere interessant hvordan man anvender sit værktøj. Derfor vil jeg hellere snakke processer og (sam)arbejdsmodeller end git og svn. Men sådan er vi jo så forskellige.

Jeg er dybt uenig i at værktøjerne ikke er interessante. Distribueret versionsstyring har jo netop åbnet op for en masse nye måder at arbejde sammen på. Processer som ikke var mulige i praksis med systemer som CVS og Subversion.

Mange ældre systemer gør det f.eks. ubekvemt eller direkte vanskeligt at finde ud af hvem der ændrede en given klump kode, hvornår og hvad de skrev i deres commit-besked om ændringerne. Det gør så at folk ikke gider at kigge i commit-loggen, som så igen gør at de beskriver en ændring af 500 linjer kode på tværs af 7 klasser med "bugfix", fordi de godt ved at ingen læser commit-beskeden alligevel.

Branching er et andet åbenlyst eksempel. Vores brug af Subversion er nok typisk; vi har en release branch og så trunk som sønderbomber med nye features, bugfixes og alt mulig andet skrammel. Vi ved godt bedre. Vi burde nok have mindst 10 feature branches men det er for svært i SVN, så vi hamrer bare alting ind i trunk og håber på det bedste. I Git eller Mercurial derimod er branching og merging nemt og derfor er man meget mere tilbøjelig til at bruge en fornuftig branching-strategi. Værktøjet gør forskellen.

Prøv at spørge Peter Toft om han bruger Git på samme måde som han brugte Telelogic Synergy...

Dit valg af processer påvirker dit valg af værktøj, men dit valg af værktøj og især tilgængeligheden af værktøjer påvirker såsandeligt også dit valg af processer. Det giver ikke meget mening at kigge på det ene uden det andet. Slet ikke i lyset af det kvantespring som DVCSer har faciliteret.

Ja sgu! Jeg vil også være med til at tale om versionsstyring (og CI, tests og alt det andet gøjl).

Jeg har det nok lidt lige som det agile folk når de i deres manifesto siger "we value people and interactions over processes and tools" - og det så viser sig at de er helt forelskede i anvendelsen af værktøjer ;-)

Selvfølgelig er værktøjer vigtige, men at bruge dem på den rigtige måde er endnu vigtigere - og så er vi jo inde på processer. Dejligt. Det er også klart at de (gode) processer man måtte have i en virksomhed påvirker valget af f. eks. versioneringsværktøj - som dernæst påvirker de processer som man nu opdager er blevet mulige med det nye værktøj. I den sammenhæng er jeg mere interesseret i "typer af værktøjer" end specifikke værktøjer. I den anden tråd kører nogle dybe diskussioner om "stærk krypto" og "kirurgiske indgreb" som jeg læser med interesse og akademisk nysgerrighed - men de kan nu ikke rigtig tænde en ild i mig.

Med hensyn til en eventuel konference så kunne man gøre sig en tanke eller to omkring hvem den skulle være rettet imod. Folk som har anvendt adskillige versioneringsværktøjer i umindelige tider og som er interesserede i at vide hvordan man omskriver historikken i git. Eller folk (fra virksomheder) som ikke er så erfarne udi anvendelsen af versionering, ikke har mulighed for at skifte til et andet værktøj og som bare er interesserede i at vide hvordan de får styr på lidt af det kaos der er i deres projekt.

Og så ville jeg da også gerne have lidt kommentarer til min (udokumenterede og uakademiske) påstand om at 80% af dem der har behov for versionering (eller samarbejdsværktøj) kunne klare sig med den funktionalitet der er i CVS. De sidste 20% er nok ovre i "den anden tråd" ;-)

---lars

Vi ved godt bedre. Vi burde nok have mindst 10 feature branches men det er for svært i SVN, så vi hamrer bare alting ind i trunk og håber på det bedste.

Jeg kan sagtens genkende situationen. Vi forsøgte godtnok at holde disciplin og jævnligt foretage en procedure meget ala "git rebase" for feature-branches for at undgå kaostiske merges senere. Det var dog ret besværligt.
Det er simpelthen et non-issue med git. Og det ændre arbejdsgange og workflow markant.

Eller folk (fra virksomheder) som ikke er så erfarne udi anvendelsen af versionering, ikke har mulighed for at skifte til et andet værktøj og som bare er interesserede i at vide hvordan de får styr på lidt af det kaos der er i deres projekt.

Ellers deres chefer, så man kunne hjælpe de stakkels folk, der hænger på et tungt forældet system med at få dem overtalt til at migrere.
Jeg kender ihvertfald folk, der med ville ønske de kunne komme væk fra CVS, hvis de da bare kunne overtale ledelsen til at få lov.

Og så ville jeg da også gerne have lidt kommentarer til min (udokumenterede og uakademiske) påstand om at 80% af dem der har behov for versionering (eller samarbejdsværktøj) kunne klare sig med den funktionalitet der er i CVS. De sidste 20% er nok ovre i "den anden tråd" ;-)

Det kommer nok an på hvem du definerer som "havende brug for versionering".
Der er sikkert ganske mange uden for "kildetekst-verdenen", der kunne bruge versionering af deres tekst-dokumenter (istedet for at have 117. versioner af den samme fil på et netværksdrev).
Og for folk, der skriver alm. tekst (ikke "kilde-") så tror jeg såmænd du har ret i at sådan noget som SVN eller Perforce ville være ganske glimrende.
Jeg ville nok ikke anbefale nogen at slås med at forstå CVS's særheder der.
Men det er da også mit indtryk at SVN er nogenlunde kendt også hos folk, der ikke nødvendigvis er programmører. Jeg har ihvertfald mødt folk, der skrev noder sammen, der puttede deres ting i SVN.

Ellers deres chefer, så man kunne hjælpe de stakkels folk, der hænger på et tungt forældet system med at få dem overtalt til at migrere.
Jeg kender ihvertfald folk, der med ville ønske de kunne komme væk fra CVS, hvis de da bare kunne overtale ledelsen til at få lov.

Med det kendskab jeg har til chefer, så har jeg ikke de store forhåbninger til at de skulle møde op. Måske kender jeg de forkerte typer. Jeg tror det ville give større gevinst at forsøge at klæde de "stakkels folk" på til at gå hjem og overbevise hver deres chef i den kontekst de nu måtte befinde sig i.

Jeg ville nok ikke anbefale nogen at slås med at forstå CVS's særheder der.

Jeg vil nu heller ikke anbefale nogen at begynde på at anvende CVS - der er så mange andre gode værktøjer at starte med. Det der smerter mit hjerte lidt er at se folk som hopper på git fordi det er et fantastisk værktøj som kan 1000 smarte ting - og så anvender de det på en måde og til ting, hvor CVS/svn ville have været udemærket - og kun udnytter 3% af hvad git/Mercurial/... virkelig kan.

I en undervisningssammenhæng er jeg dog vildt forelsket i CVS. Det findes overalt (også på andre "eksotiske" universiteter hvor jeg har undervist lidt) og hvis det ikke findes kan det installeres på få minutter. Det har en meget simpel og intuitiv model som de studerende hurtigt samler op og de kan hurtigt komme videre i deres eksperimenter af hvad versionering er og hvor de rammer begrænsningerne (eller "særhederne") i CVS. Når de således har fået de basale begreber og principper for versionering på plads er de rede til at fortsætte med rigtige versioneringsværktøjer.

---lars

Peter Toft,

er der noget nyt om en eventuel konference? Min nysgerrighed ville have det dårligt med at misse et sådant event. Jeg holder jo selv en konference i Lund næste måned:

http://snescm.cs.lth.se/Common/SCM-day-14/index.html

og hvis der var interesse for det kunne det jo være at der var nogle af oplægsholderne som kunne overtales til at tage en tur over Sundet.

---lars