Välkommen till linuxportalen.se!

Linuxportalen.se är Sveriges största och aktivaste webbplats för användare av öppen- och fri programvara.

Du besöker Linuxportalen.se som gäst vilket begränsar din möjlighet att använda webbplatsens alla funktioner. Genom att registera dig som medlem får du inte bara möjlighet att söka bland webbplatsens innehåll, skapa nya och delta i befintliga diskussioner, skapa din egen blogg, kommunicera med andra medlemmar genom privata meddelanden och delta i omröstningar. Du får också tillgång till Veckans Kadavro - en seriestrip unikt skapad för Linuxportalen.se!

Registeringen sker snabbt och är helt kostnadsfri - tveka inte, bli medlem idag!

Hur har du gjort ditt val av Versionshantering?

Vilka faktorer har avgjort när du valt vilket versionshanteringssystem som du använder dig av. Är det bara egna projekt som avgjort vilket du valt? Eller går du enbart på vilket du tycker är bäst?

Orsaken till min fundering är att jag har gjort mitt val baserat på vilket som används mest i dom projekt som jag har intresse i eller är involverad i. Dom flesta projekt jag är i kontakt med använder sig av Subversion. OpenBSD använder sig av CVS. Tror jag träffat på nåt projekt också som använder sig av Bazaar...

GIT verkar ju vara det bästa alternativet när man tittar runt. Samtidigt så har ju Bazaar en fördel och det är att det är väldigt enkelt att lära sig och att använda. Men på nåt sätt så känns det enklast att lära sig Subversion och använda sig av det då det är det jag stöter på mest.

Att kunna alla dom jag nämnt kräver ju en del tid med att lära sig, bli van vid varje system. I alla fall till viss mån även om det ibland räcker att bara kunna vissa kommandon i en för att kunna skicka och hämta.

Skulle vara kul i alla fall att se hur andra tycker... Smile

Alternativ för kommentarvisning

Välj ditt önskade sätt att visa kommentarerna och klicka på "Spara" för att verkställa dina ändringar.

Ciphers bild

På kontoret kör vi med CVS och privat använder jag GIT. Upplever GIT som mycket enkelt och smidigt.

----------------------------------------
Archlinux.se | jlug.se | munix.se

----------------------------------------
Archlinux.se | jlug.se | munix.se

Kristians bild

Vad är det som skulle vara svårt med git? Git har tre stora nackdelar - dels finns det ännu ganska dåligt stöd för det i vanliga IDE:er, dels kan GIT inte hantera enorma projekt (det har att göra med hur snabbt SHA-1 kan arbeta över filträdet) och dels så kan man inte checka ut delar av ett träd. Det senare är gemensamt för alla distribuerade versionshanteringssystem. I övrigt är git i de flestas ögon väldigt smidigt att arbeta med och har funktioner som saknas i de flesta andra versionshanteringssystem.

---------------------------------------

Open Source - because writing software doesn't make you a "traitor"

---------------------------------------

 

leochingkwakes bild

Jag har inte sagt att git är svårt. Nackdelen med GIT är att det är få projekt som verkar använda sig av git. I alla fall bland dom jag kollat på. Min kommentar om att bazaar är väldigt enkelt betyder inte att jag tycker att git därmed blir väldigt svår.

valdermans bild

Git kan inte hantera enorma projekt? Både Linux och GNOME använder sig av git; om de inte är enorma, vad menar du då är enormt? Vilka operationer är det du menar medför problem på stora projekt?

--
valderman är i den positionen att han inte behöver "argumentera"
för vare sig det ena eller det andra. Det han gör är alltid i princip
rätt och genomtänkt.

--
あるユーモアのないアホのため、シグナチャーをカエルことにした。カエルさん

Kristians bild

"So one of the things you do have to think about with git is that you want to make sure it is in somewhat sane hierarchy. Git can easily handle largest projects, you can have 10,000 files and that's not a problem, the kernel is 22,000 files. We've done with test with 100k and it's fine. It's faster than anything else. With million files, I suspect other systems would be faster at some things. And that is the kind of situation that I do not want you to get into. But if you do the basic setup correctly, git will be basically faster at anything, pretty much everything, than anybody else would."

Vad det hänger på är hur snabbt git kan beräkna SHA-1 över trädet.
Med extremt många och stora filer så blir till exempel "git status" en
tröttsam operation.

Gnome följer linus' råd och lägger varje komponent/bibliotek i sin egen git-repo. Det har även att göra med att användare vill kunna arbeta med ett program utan att behöva ha hela gnomes framework utcheckat. Vill man synca flera repos finns "git submodules", men det är inte supersmidigt. Android-projektet har därför tagit fram ett eget verktyg för detta syfte "repo".

---------------------------------------

Open Source - because writing software doesn't make you a "traitor"

---------------------------------------

 

valdermans bild

På så vis. Dock tror jag att ett projekt som sitter med miljontals olika filer i samma repo har betydligt större problem än att deras SCM går sakta.

--
valderman är i den positionen att han inte behöver "argumentera"
för vare sig det ena eller det andra. Det han gör är alltid i princip
rätt och genomtänkt.

--
あるユーモアのないアホのため、シグナチャーをカエルことにした。カエルさん

Kristians bild

Jovisst är det så.

---------------------------------------

Open Source - because writing software doesn't make you a "traitor"

---------------------------------------

 

valdermans bild

Jag använder git för egen del; det är trevligt med distribuerade system, och jag har (sannolikt ogrundade) fördomar mot Canonical som gör att jag hellre kör med git. Dessutom är det snabbt som satan, och så finns ju github.

Som Haskelljunkie kanske jag borde vara lite mer fanboy och köra darcs, men nu har jag vant mig vid git, så git får det förbli.

--
valderman är i den positionen att han inte behöver "argumentera"
för vare sig det ena eller det andra. Det han gör är alltid i princip
rätt och genomtänkt.

--
あるユーモアのないアホのため、シグナチャーをカエルことにした。カエルさん

Kristians bild

Ja bzr är hopplöst långsamt på stora projekt. Prova att tanka ner emacs' bzr-repo, kör en "bzr status" och gå på kafferast. Med git tar det möjligen någon sekund.

---------------------------------------

Open Source - because writing software doesn't make you a "traitor"

---------------------------------------

 

leochingkwakes bild

Det enda jag egentligen vet om Bazaar är att deras guide fick allt att se så enkelt ut. Typ lär dig massor på bara 5 minuter Wink

Har bara använt SVN och CVS plus testat GIT lite grann... CVS gillar jag inte.

Pardus använder sig av svn så det blev min första kontakt med versionhanteringssystem i samband med att jag började översätta. När jag sedan skapade egna projekt på SF var valet enkelt, att fortsätta med svn. Jag kan väl även tillägga att jag bara kan några få extremt grundläggande kommandon, så det kanske fortfarande är enkelt att byta om jag skulle vilja.

Byter Pardus byter jag.

leochingkwakes bild

Btw... nån som har koll på hur sånt som git-svn fungerar. Har sett att dom olika systemen har funktioner likt git-svn. Betyder det att jag kan fokusera på git och använda git även mot subversion (mer än bara hämta)?

tufftuffs bild

Det går även åt andra hållet.

Ska själv köra git på det sättet. Detta eftersom jag normalt inte har tillgång till svn-arkivet. Men koll har jag inte ännu, men man lär sig väl med tiden.

ein.anderssons bild

Kom kör subversion
Då när jag provade git, svn, CVS och Mercurial. Fann att subversion är det system som fungerade bäst med mig.

--
(Alla stavfel nu ser mig skriva är antagligen oavsiktliga eller avsiktliga, oavsätt så är dom där)

Denna text får användas enligt CCommons BY-ND 2.5 med undantag från att den inte får kopieras, sändas eller distribueras utan att informera mig

rickards bild

För mig var det en faktor att medarbetare skulle ha lätt att använda sig av det oavsett plattform. CVS och Subversion är mig veterligen de som har flest gränssnitt att välja bland och man kan vara säker på att hitta plugins till de flesta utvecklingsmiljöer. Därav använder vi Subversion.

Jag har flera gånger varit igång och vägt för och nackdelar för att byta till något annat eftersom branching och merging är ganska knöligt i svn. Oftast har det dock fallit på ovansstående.

En nackdel med den logiken är att om för många tänker som jag så kommer utvecklingen av stöd för andra system stå still. Ibland bör man nog offra lite bekvämlighet för att driva utvecklingen.

kattassens bild

Git är min melodi, jag har förstått att subversion skulle funka bra för mig också men jag har inte provat det.

På mitt jobb sitter jag i ClearCase och jämför man med det så är de flesta versionshanteringsverktyg lätthanterliga.

ein.anderssons bild

Vad är då fördelen med ClearCase . Alltså varför togs beslutet att använda det?

--
(Alla stavfel nu ser mig skriva är antagligen oavsiktliga eller avsiktliga, oavsätt så är dom där)

Denna text får användas enligt CCommons BY-ND 2.5 med undantag från att den inte får kopieras, sändas eller distribueras utan att informera mig

mcnilss bild

jag ser tre fördelar med clearcase.

dynamiska vyer, tyvär försvinner den nyttan direkt när man kör windows eller annat *nix som ibm inte stöder.
bra mergeverktyg. har använt git för lite för att kunna relatera.
det går att hålla koll på vilka filer som andra jobbar med.