Versjonskontroll, repositorie osv

[AnaXyd]

Leste meg opp mye om de forskjellige systemene før jeg valgte noe, og kom jo borti Linus Thorvald sin "tale" om Git på youtube. Ganske spennende video egentlig, hvor han er ganske klar på hva han mener om Subversion. Spesielt når han fortalte om hastigheten til Git vs Subversion. For jeg må jo innrømme, Git bare funker! Og det funker enormt raskt! Selv om jeg sitter på en relativt middels internettforbindelse så går alt i et ekstremt tempo.

 

Men med Git så må man ha oversikt over hvordan alt henger sammen, det måtte jeg sitte lenge med for å lære meg. Men nå som det er innlært sånn delvis, så er det jo bare genialt!

[Ernie]

Ja, i mine øyne er man ikke en seriøs utvikler før man innser at SVN ikke nødvendigvis er knallbra. Det eneste som kan være verre er vel CVS og ingen versjonskontrol i det heltatt.

Det finnes mye som er verre - ClearCase og det Microsoft hadde for 10 år siden, f.eks.

Jo takk, ClearCase er rimelig ille, men vi sammenligner da mot SVN her, og ClearCase er da ikke bare sorg og elendighet. Til litt større bruk klarer jeg ganske enkelt ikke se hvordan SVN i det heltatt kan fungere med mindre teamet er ekstremt godt samkjørte. Dessuten, ClearCase har faktisk versjoner av ting som er låst. SVN jukser det hele til med mapper og møkk som enkelt kan manipuleres i ettertid. Trunk kan likegodt være tags/1.3.2 sist jeg brukte det. Mao., ClearCase er i det minste et seriøst verktøy, om enn dårlig. SVN er et useriøst lekeverktøy som tror det er et system for versjonskontroll, rent bortsett fra at versjoner er mapper som kan redigeres i ettertid …Det er ikke hva man kan kalle versjonskontroll om du spør meg.

[tomsi42]

Der synes jeg du er noe urettferdig mot SVN; jeg har også brukt det en del, og i team spredd på flere lokasjoner. Men det krever noe disiplin å bruke det bra. Subversion tar en del ideer fra Perforce; et verktøy vi brukte i over 8 år uten problemer; før vi ble tvunget over på ClearCase. SVN har tatt mye fra Perforce; der håndteres også versjoner ved å splitte de ut i en mappe per versjon. Har aldri hatt problemer med det.

[Ernie]

Nei, for å være ærlig synes jeg det er høyst berettiget kritikk av SVN. Jeg ser revisjoner der, men «tags» og «branch» er et salig søl jeg ikke helt begriper hvordan man kan anse som noe seriøs implementasjon (seriøst, «tags» er skriverbart i ettertid). Enda verre blir det i forhold til «merge». Er det i det heltatt noen som klarer å gjøre det effektivt i SVN? Sist jeg brukte SVN var det en ikke-kommando.

 

Det er da før man begynner å ta for seg hvordan SVN f.eks. klarer å ende opp med en korrupt database innimellom. Det skal være umulig på papiret, men praksis sier det stikk motsatte. Så blir man vel også ganske sulteforet på atomiske operasjoner. Går noe galt så sitter man fort med hverken fugl eller fisk. I det heltatt, hva er bra med SVN?

Endret 12. juli 2012 av Ernie

[dahuff]

Jeg slet veldig med å holde i live en branch utenfor trunk i SVN - og da mener jeg med bare én feature branch. I Git (og de fleste andre DVCS sikkert) kan jeg ha feature brancher gående så lenge jeg ønsker uten at det forstyrrer arbeidsflyten. Kjenner til utfordringene.

 

En annen sak. Støtter Mercurial å pushe mot flere servere på samme tid slik man gjør i Git?

For eksempel kan man dytte utvikling, master og feature branch til en felles server internt, og man kan i tillegg dytte masterbranch til en server utenfor organisasjonen, over https til og med. Det er veldig nyttig å ikke være bundet til en spesiell server. (Strengt tatt er man ikke bundet til en server i det hele tatt.)

Endret 12. juli 2012 av dahuff

[zotbar1234]

Der synes jeg du er noe urettferdig mot SVN; jeg har også brukt det en del, og i team spredd på flere lokasjoner. Men det krever noe disiplin å bruke det bra.

 

Bruke det bra? Gitt at du ikke trenger branching (svnmerge.py -- say no more), at du ikke har noe i mot å sitte og å tvinne tommeltottene mens svn blame spør en tjener i USA, at du ikke trenger å grep-e etter &--#60;uttrykk&--#62; i commithistorikken, gitt at du aldri gjør feil i en commit, gitt at du aldri trenger å committe (commite?) uten nett, gitt at du aldri trenger å stokke om på historikken før du eksponerer dine endringer for andre, gitt at du aldri har behov for å stykke opp en større endring i mindre steg (det er her lokale commits og branches er nyttige), gitt at du aldri trenger å legge det du holder på med til side for å hente en annen revisjon/teste en ide (git stash) -- joda, da kan SVN kanskje vurderes. SVN er brukket på mange måter. Det er bedre enn dens forgjengere, men "å bruke det bra" er en saftig overdrivelse.

 

Jeg visste ikke at livet skulle bli så mye enklere med git stash/git rebase -i, men jaggu. Selv slike trivielle ting som git commit --amend er umulige med svn uten seriøse danser med trommer i måneskinn der man påkaller sertifiseringens verdige makter (STR).

 

Man trenger ikke å velge git. Men det betyr ikke at det er verdt bryet å vurdere SVN.

 

Til OP spesifikt, forresten, http://hginit.com. Kan være verdt en titt.

Endret 12. juli 2012 av zotbar1234

[tomsi42]

Jeg hører dere. Men jeg må si at min erfaring med SVN ikke samsvarer med den dere har hatt.

 

Men jeg er enig at for nye prosjekt, så er bedre å velge Mercurial eller git.

[dahuff]

Stod litt interessant informasjon om Mercurial og Git på denne siden. Man er visst litt mer avhengig av tilleggsmoduler for å gjøre enkelte operasjoner i Mercurial som er vanlig i Git. Og så er branchene veldig annerledes i Mercurial.

Both tools have the notion of branches, but they are different. A mercurial branch is something that is added to a commit and sticks around forever. Anyone who pulls from you will see all the branches that are in your repository and which commits are in each one. There are ways to do git branches in mercurial, but we will get into that later when we talk about extensions.

 

Foretrekker egentlig Git sin måte siden det er det jeg er vant med.

Git branches are just pointers to commits. That’s it. They do nothing other than tell the git client, “when I’m in this branch, this is what my working copy looks like”. They can point to different commits, they can be deleted, they can be passed around (each one is uniquely identified by the local name of the repository it came from). There is one convenience that the git client offers you: when you make a commit, your branch pointer is automatically updated.

 

!!!

Generally when people want git branches in mercurial, they create a new clone. That’s great if all you want is to create commits that represent two concurrent development streams, but if you want to start merging between them or comparing histories, you need tools that understand these two directories are related in some ways (I’m sure extensions exist to do that, but I’m getting to that).

 

Mercurial branches serve a different purpose than git branches. Mercurial branches represent a shared place for development to happen outside the default branch. Because everyone shares branch names, they are reserved for long-living versions of your project.

 

I Git dytter man bare endringer til brancher, på felles server, som man er interesserte i å dele. Mens feature brancher som regel forblir lokale (med mindre man må involvere andre utviklere og da dytter man feature brancher til felles ressurser/servere).

 

Jeg har ikke brukt Mercurial selv, men jeg hadde sikkert ikke brydd meg om slike forskjeller om jeg hadde valgt Mercurial istedenfor for Git. Det er egentlig flisespikkeri sammenlignet med SVN. Men hvilken versjonskontroll man bruker påvirker i høy grad hvordan man arbeider.

 

[...]

 

This belies one of the main differences I’ve found between git and mercurial. When a git user runs into a problem, they look at the tools they have on hand and ask, “how can I combine these ideas to solve my problem?” When a mercurial user runs into a problem, they look at the problem and ask, “what code can I write to work around this?” They are very different approaches that may end up at the same place, but follow alternate routes.

 

Når jeg jobbet i team med SVN passet vi alltid på å jobbe i forskjellige deler av systemet siden alt blir sjekket inn sentralt og konflikter kunne oppstå. I forkant av ny versjon gikk vi i "frys" og sluttet å sjekke inn endringer, med mindre kritiske feil ble oppdaget, siden branching i SVN er så kostbart (og jeg kjente heller ikke til hvordan man gjorde det den gang). Versjonskontrollsystemet påvirker i høy grad måten man tenker på.

 

Siden versjonskontrollsystem er så koblet til utviklerens arbeidsvaner, er det mange (etter min erfaring) som ikke ser hensikten med å bytte løsningen med mindre de kan beholde de gamle arbeidsvanene. Oppdater, sjekk inn, oppdater, sjekk inn, oppdater, sjekk inn, oppdater, sjekk inn..

Endret 15. juli 2012 av dahuff

[tomsi42]

Måten mercurial håndterer branches passer godt for oss siden vi må vedlikeholde flere versjoner samtidig.Det er på main branchen vi utvikler det meste; på eldre versjoner så gjøres det stort sett kun bugfiksing. Disse kan fint utvikles på main, trekkes ut som en patch og importeres i de andre versjonene når det er behov for det.

[dahuff]

Akkurat det blir vel det samme om du bruker Mercurial eller Git. På felles git-ressurs (server) kan jeg både ha feature brancher med lang levetid som vedlikeholdes med "merge master" og lignende. Og så har jeg alltid de vanlige utvikler og master branchene, hvor master branch skyves fram så snart endringene i utviklerbranch er modne for produksjon.

 

Disse kan fint utvikles på main, trekkes ut som en patch og importeres i de andre versjonene når det er behov for det.

En måte å gjøre dette på er å bruke git rebase. Da lager man en feature branch av master, legger til endringene. Og så legger man endringene på toppen av master, og så spiller man om igjen alle endringene på toppen slik at endringene kommer med i utviklingsversjonen. Deretter flytter man master branch'en ett steg fram slik at endringene er med her også.

 

Forskjellen, slik jeg forstår det, er at lokale brancher ikke er synlige for alle med mindre jeg eksplisitt dytter de ut på serveren som de andre utviklerne kan sjekke ut endringene fra. (Eller de kjenner sha1 verdien for commit.) I Git er en branch en lokal eller delt merkelapp på en commit, i Mercurial er en branch en del av historikken og alltid tilgjengelig uavhengig om den heter "test123-ole-larsen" eller "production"..

Endret 15. juli 2012 av dahuff

[tomsi42]

Nettopp. Og det er faktisk historikken som er viktig for oss. Når vi gikk over fra Perforce til Clearcase, så måtte vi beholde Perforce serveren for å beholde hisotrikken. Når vi to år senere gikk over til Mercurial, så klarte å få få overført både Perforce og Clearcase historikken, og kan nå kun bruke Mercurial. Tipper det samme er mulig i git.

 

Hva er status på Windows GUI verktøy for git? Vi bruker TortoiseHg; finnes det noe like godt for Windows/git enda?

[dahuff]

Nettopp. Og det er faktisk historikken som er viktig for oss. Når vi gikk over fra Perforce til Clearcase, så måtte vi beholde Perforce serveren for å beholde hisotrikken. Når vi to år senere gikk over til Mercurial, så klarte å få få overført både Perforce og Clearcase historikken, og kan nå kun bruke Mercurial. Tipper det samme er mulig i git.

Det er ikke noe problem å ta med historikken fra SVN til Git i alle fall. Git tar vare på historikken, men du får ikke hentet fram historiske endringer som bare eksisterer i lokale brancher (selv om de teknisk sett finnes). Du kan skrive om historikken, men det skjer ikke umerket hen om du forsøker dette på commits som er sjekket inn og sjekket ut av andre fordi dette i praksis splitter treet i to. Git rebase er best utført på endringer som ikke er sjekket inn av denne grunn blant annet.

 

Usikker på hva som er fordelen med å ha tilgang til komplett historikk, utenom at det er noe som er kjent fra sentrale versjonskontrollsystemer. Samt at det kanskje kan være ett organisatorisk, framfor teknisk, krav for å få innført ett distribuerte systemer i en organisasjon at all historikk lagres?

Hva er status på Windows GUI verktøy for git? Vi bruker TortoiseHg; finnes det noe like godt for Windows/git enda?

Jeg bruker bare msysgit på Windows siden jeg bruker Git fra terminalen i Linux (msysgit er omtrent identisk). Så jeg er ikke sikker på status for Windows GUI verktøy. Tilbakemeldingene jeg har fått er at verktøyene og MS Visual Studio integrasjonen fortsatt er litt enkle i forhold til det Windowsbrukere er vant med dessverre (SVN). Det er naturligvis en utfordring.

 

Edit: Gosh, her var det mange skrivefeil.

Endret 15. juli 2012 av dahuff

[tomsi42]

Fordelen med å ha historikken er at det er lettere å finne ut hva som har skjedd med en fil igjennom tidene. Gjerne når det er obskure bugs man skal prøve å fikse. Er ikke mange månedene siden en av våre utviklere måte grave seg nærmere 10 år tilbake i tid.

[dahuff]

Du har dette i Git også.

[torbjørn marø]

Hva er status på Windows GUI verktøy for git? Vi bruker TortoiseHg; finnes det noe like godt for Windows/git enda?

 

Sjekk ut Github for Windows. Det er den enkleste måten å få et velfungerende Git-miljø installert på Windows, og fungerer fint for Git generelt, ikke bare Github repos. Bra GUI for dem som ikke allerede er Git Gurus, men mangler støtte for de mere avanserte tingene.

[tomsi42]

Sjekk ut Github for Windows. Det er den enkleste måten å få et velfungerende Git-miljø installert på Windows, og fungerer fint for Git generelt, ikke bare Github repos. Bra GUI for dem som ikke allerede er Git Gurus, men mangler støtte for de mere avanserte tingene.

Kan man sette opp en egne github server inhouse? For mange er det ikke et tema å ha koden utenomhus. Og hvertfall ikke i skyen.

Endret 15. juli 2012 av tomsi42

[dahuff]

Ja, men det er koster endel.

 

Bruker gitolite og gitweb. Kanskje gitlabhq er ett bedre alternativ.

[dahuff]

Glemte å nevne Norske Gitorious. De er rimeligere enn github enterprise.

 

Det kommer litt an på størrelse på teamet om dere behøver så avanserte løsninger. Git behøver ikke dedikert server strengt tatt. Den enkleste måten er å sette opp en git bruker på en Linux maskin med git-shell. En fattigmannsløsning er å bruke det man har, som fellesområde med begrenset tilgang. Kanskje det allerede eksisterer infrastruktur som tilbyr backup og AD styring. Fleksibiliteten er stor.

[torbjørn marø]

Kan man sette opp en egne github server inhouse? For mange er det ikke et tema å ha koden utenomhus. Og hvertfall ikke i skyen.

Github lokalt koster, men git-server lokalt koster ingen ting, og det er mange måter å gjøre det på. Vi ser nå på å sette opp en open source IIS-basert git-server (for Windows altså), men jeg er usikker på linken akkurat nå .., det finnes flere...

[tomsi42]

Det der var Enterprise priser, ja. Tror jeg holder meg til mercurial, jeg.