SVN vs GIT - Vil gerne havde min egen kender i god guides
Hey jeg har efter hånden en ordelig røvfuld workspace og dets lige til forskellig programmerings projekter lokalt på mine laptops, dem vil jeg gerne havde over på en personlig Subversion eller GIT sever.
Så kan I hjælpe med at give mig nogle guides, til at sætte sådan en sven op?
1. Jeg er lige glad med om det bliver GIT eller SVN - har dog selv mest erfaring med SVN
2. Jeg kører for nuværende Arch men er klar på at skifte distro hvis det er - kan dog ikke trækker 64bit versioner.
Så nogen som kan hjælpe, har søgt lidt på google, men de fleste guides jeg har kunne finde er fra 2001 og regner ikke med de er helt up2date
- Log in to post comments
Kommentarer8
Umiddelbart ser jeg ingen
Umiddelbart ser jeg ingen grund til at du skulle skifte distro på nogen måde.. Git og SVN er pænt supporteret på stortset alle Linux Distributioner.. :-)
Personligt må jeg indrømme (på trods af en del undren og forvirring) er jeg blevet glad for Git, eller rettere sagt for den distributive model. Det at man er sin egen "server" og andre vil skulle "pushe" og "pulle" til og fra en syntes jeg virker genialt.
Dog kan jeg også se nogle problemer ved denne model.
Dog har jeg selv haft en god start i at bruge Git's officelle "getting started" guide: http://git-scm.com/ eller http://schacon.github.com/git/everyday.html
Kan dog hverken argumentere for hvor den ene skulle være bedre til dit formål end den anden, samt at det at bruge et versions styringsprogram har taget lidt tilvænding - men virker ret logisk nu her :-) ..
JEg siger tak forksen og
JEg siger tak forksen og kikker på det
Et par links
Et par links mere:
http://blog.bootstraptoday.com/2011/03/16/git-vs-subversion/
http://www.richappsconsulting.com/blog/blog-detail/svn-vs-git-who-will-…
Jeg synes, at kunne mindes noget om en her på sitet, der for et lille års tid siden begyndte på en Git-guide. Var det Marx?
...der var den http://linuxin.dk/node/17360
Svn synes jeg virker helt fint for det meste, men jeg kan også godt se nolge gode ting i git måden. Overvejer selv svn eller git til hjemmebrug. På job hedder det svn.
Kim
Så lige at "GitHub" har
Så lige at "GitHub" har lavet en video-guide, måske kan den bruges?
http://learn.github.com/p/intro.html
(EDIT: Måske bedre: http://blip.tv/scott-chacon/gitcasts-setup-init-and-cloning-4237671)
Lidt flere henvisninger:
http://pthree.org/2008/11/28/setup-a-git-repository/
#3, Har ladet mig fortælle engang at SVN nok er bedst til større virksomheder, da det gør at man har et fælles repo for data samt at man undgår at enkelte medarbejder ligger inde med revisioner som andre ikke har adgang til. Git skulle være godt til privat brug, samt til åbne/frie projekter, da det at kunne dele og udvikle uafhængigt af hinanden er en naturlig del af dennes udvikling.
Dog er det ikke noget jeg har noget belæg for, så :-)
Har ladet mig fortælle
#4: Har ladet mig fortælle engang at SVN nok er bedst til større virksomheder, da det gør at man har et fælles repo for data samt at man undgår at enkelte medarbejder ligger inde med revisioner som andre ikke har adgang til.
Det er vist mere et spørgsmål om diciplin og procedure, at de enkelte medarbejder ligger inde med kode de ikke har givet videre kan lige så godt ske med subversion. I forhold til den centrale server, vil man med et distribueret system, bare have en server med et main reprository, som all pusher og puller fra.
På mit arbejde har vi skiftet fra subversion til mercurial, hvilket vi har været rigtig glade for. Dels er den distribuerede model belejlig i mange tilfælde. Det er for eksempel dejligt at kunne tilgå sit repository uden internet forbindelse hvis man sider i et tog eller lignene.
Der ud over giver mercurial os bare mindre bøvl end subversion gjorde. Dette skyldes hovedsageligt, at subversion laver .svn mappen den følger, og samtlige den undermapper. Det giver et forfærdeligt rod, hvis man kommer til at flytte lidt rundt på filer uden om svn komandoen. Bevares Mercurial brokker sig selvfølgelig også over det, men subversion havde en tendens til at gå helt i fisk.
#5, Ved du hvorfor I valgte
#5, Ved du hvorfor I valgte mercurial fremfor f.eks. Git? Har tit tænkt over hvad den store forskel egentligt er, for umiddelbart lader kommandoerne til at være ret ens, deres tilgang til "problemstillingen" er også ret ens og de lader til at de er mere eller mindre lige hurtige...
#6
Jeg kender nogen, som
#6
Jeg kender nogen, som valgte at satse på Mercurial fordi, at det er bedre understøttet på Windows end Git er.
Kim
Bedre Windows
Bedre Windows understøttelse var en af grundene. Jeg sider heldigvis på en linux boks til daglig, men ikke alle i organisationen er så heldige.
Der er en del kommentarer rundt omkring på nettet som skelner dem ved at Mercurial skulle være den nemme brugervenlig model, mens Git skulle være den der har alle funktionerne men tilgængeld sværere at bruge. Dette er dog efter min mening kun noget der hænger på fra ældre tid. I dag er brugen af dem meget ens, og der er mig bekendt ikke noget den ene kan som den anden ikke kan.
Den største forskel er vist sproget de er skrevet i. Mercurial er skrevet i Python, men Git er skrevet i C og bash. Oprindeligt var det vist rigtig meget bash, men det er vist med tiden blevet mere og mere C, og om der overhovedet er noget bash kode tilbage er jeg ikke klar over.
Python koden giver Mercurial en stor fordel ved portering til andre platforme, så længe det er en platform som Python understøtter. Git skulle tilgængeld have en performance fordel, som dog nok er mere teoretisk end praktisk. I hvert fald kan jeg ikke mærke forskel i de projekter jeg arbejder med (eller kunne ikke da jeg testede for en 1½ år siden), som jeg ville generelt er små og middel store projektor, Jeg kan ikke afvise at der kan være forskel ved rigtig store projekter, det har jeg ikke prøvet i praksis.