Hvorfor er Git bedre enn Subversion?

stemmer
393

Jeg har brukt Subversion i noen år, og etter å ha brukt Source , jeg bare elsker Subversion. Kombinert med TortoiseSVN , jeg kan egentlig ikke forestille meg hvordan det kunne være noe bedre.

Likevel er det et økende antall utviklere hevder at Subversion har problemer, og at vi bør flytte til den nye rasen av distribuerte versjonskontrollsystemer som Git .

Hvordan Git forbedre Subversion?

Publisert på 03/08/2008 klokken 22:38
kilden bruker
På andre språk...                            


30 svar

stemmer
548

Git er ikke bedre enn Subversion. Men er heller ikke verre. Det er annerledes.

Den største forskjellen er at det er desentralisert. Tenk deg at du er en utvikler på veien, utvikler du på den bærbare datamaskinen, og du ønsker å ha kontroll, slik at du kan gå tilbake tre timer.

Med Subversion, har du et problem: SVN kan være på et sted du ikke kan nå (i din bedrift, og du trenger ikke internett for øyeblikket), kan du ikke har begått. Hvis du ønsker å lage en kopi av koden din, må du bokstavelig talt kopiere / lime det.

Med Git, trenger du ikke har dette problemet. Din lokale kopien er et oppbevaringssted, og du kan forplikte seg til det og få alle fordelene av kildekontroll. Når du gjenvinne tilkobling til hoved depotet, kan du begår mot det.

Dette ser bra ut i begynnelsen, men bare husk den ekstra kompleksiteten til denne tilnærmingen.

Git synes å være den "nye, skinnende, kule" ting. Det er på ingen måte dårlig (det er en grunn til Linus skrev det for Linux Kernel utviklingen tross alt), men jeg føler at mange mennesker hoppe på "Distributed kildekontroll" trene bare fordi det er nytt og er skrevet av Linus Torvalds, uten egentlig vite hvorfor / om det er bedre.

Subversion har problemer, men det gjør Git, Mercurial, CVS, TFS eller hva.

Edit: Så dette svaret er nå ett år gammel og fortsatt genererer mange upvotes, så jeg tenkte jeg vil legge til noen flere forklaringer. I det siste året siden skriver dette, har Git fått mye momentum og støtte, spesielt siden nettsteder som GitHub virkelig tok av. Jeg bruker både Git og Subversion i dag, og jeg vil gjerne dele noen personlige innsikt.

Først av alt, kan Git være veldig forvirrende i begynnelsen når du arbeider desentralisert. Hva er en ekstern? og hvordan du skal sette opp den første depot? er to spørsmål som kommer opp i begynnelsen, spesielt i forhold til SVN enkle "svnadmin create", Git er "git init" kan ta parametrene --bare og --shared som synes å være "riktig" måte å sette opp en sentralisert oppbevaringssted. Det er grunner til dette, men det legger kompleksitet. Dokumentasjonen av "kassen" kommandoen er veldig forvirrende for folk endrer over - den "riktig" måte synes å være "git klone", mens "git kassen" ser ut til å slå grener.

Git virkelig skinner når du er desentralisert. Jeg har en server hjemme og en bærbar PC på veien, og SVN rett og slett ikke fungerer godt her. Med SVN, kan jeg ikke ha lokal kilde kontroll hvis jeg ikke koblet til depotet (Ja, jeg vet om SVK eller om måter å kopiere repo). Med Git, er at standardmodus likevel. Det er en ekstra kommando om (git begå begår lokalt, mens git push-opprinnelse mester skyver hovedgren til den eksterne heter "opprinnelse").

Som sagt ovenfor: Git legger kompleksitet. To moduser skape repositories, kassa vs. klone, begår vs. trykk ... Du må vite hvilke kommandoer arbeid lokalt og som arbeider med "server" (jeg antar de fleste fremdeles som en sentral "master-depot" ).

Dessuten er det verktøy fortsatt utilstrekkelig, i alle fall på Windows. Ja, det er en Visual Studio tilleggsarbeidsbok, men jeg fortsatt bruke git bash med msysgit.

SVN har den fordelen at det er mye enklere å lære: Det er depotet, alle endringer i mot det, hvis du vet hvordan du oppretter, forplikte og kassa og du er klar til å gå, og kan pickup ting som forgrening, oppdatere osv senere på.

Git har den fordelen at det er mye bedre egnet hvis noen utviklere ikke alltid er koblet til master depotet. Dessuten er det mye raskere enn SVN. Og fra hva jeg hører, forgreninger og fletting støtte er mye bedre (som er å forvente, da disse er de viktigste grunnene til at det ble skrevet).

Dette forklarer også hvorfor det får så mye buzz på Internett, som Git er perfekt for Open Source prosjekter: Bare Fork det, legge inn forandringene til din egen Fork, og deretter be opprinnelige prosjektet vedlikehold å trekke endringene. Med Git, dette bare virker. Virkelig, prøv den på Github, det er magi.

Det jeg også ser er Git-SVN Bridges: Den sentrale lageret er en Subversion repo, men utviklerne lokalt jobbe med Git og broen skyver deretter sine endringer i SVN.

Men selv med denne lange tillegg har jeg fortsatt står ved min kjernebudskap: Git er ikke bedre eller verre, det er bare annerledes. Hvis du har behov for "Offline Source Control" og vilje til å bruke litt ekstra tid på å lære det, det er fantastisk. Men hvis du har en strengt sentralisert kildekontroll og / eller sliter med å innføre kildekontroll i første omgang fordi dine medarbeidere ikke er interessert, så enkelhet og gode verktøy (i alle fall på Windows) av SVN glans.

Svarte 03/08/2008 kl. 22:45
kilden bruker

stemmer
145

Med Git, kan du gjøre nesten hva som helst offline, fordi alle har sin egen depotet.

Making grener og sammenslåing mellom grenene er virkelig enkelt.

Selv om du ikke har forplikte rettigheter for et prosjekt, kan du fortsatt ha din egen depot på nettet, og publisere "push forespørsler" for patcher. Alle som liker dine patcher kan trekke dem inn i sitt prosjekt, inkludert de offisielle vedlikeholdere.

Det er trivielt å punge et prosjekt, endre den, og fortsatt holde sammenslåing i feilrettinger fra hodet grenen.

Git fungerer for Linux-kjernen utviklere. Det betyr at det er veldig fort (det må være), og skalerer til tusenvis av bidragsytere. Git bruker også mindre plass (opp til 30 ganger mindre plass for Mozilla depotet).

Git er meget fleksibelt, meget TIMTOWTDI (det er mer enn én måte å gjøre det). Du kan bruke hva arbeidsflyt du vil, og Git vil støtte det.

Til slutt er det GitHub , et godt nettsted for hosting Git-lagrene.

Ulempene ved Git:

  • det er mye vanskeligere å lære, fordi Git har flere konsepter og flere kommandoer.
  • revisjoner har ikke versjonsnumre som i subversion
  • mange Git-kommandoer er kryptisk, og feilmeldinger er svært bruker uvennlig
  • det mangler en god GUI (slik som den store TortoiseSVN )
Svarte 04/08/2008 kl. 00:24
kilden bruker

stemmer
110

Andre svar har gjort en god jobb med å forklare de viktigste funksjonene i Git (som er stor). Men det er også så mange små måter som Git oppfører seg bedre og bidrar til å holde livet mitt mer tilregnelig. Her er noen av de små tingene:

  1. Git har en 'ren' kommandoen. SVN trenger desperat denne kommandoen, med tanke på hvor ofte det vil dumpe ekstra filer på disken din.
  2. Git har 'halvere' kommandoen. Det er fint.
  3. SVN skaper .svn kataloger i hver enkelt mappe (Git skaper bare en .git katalog). Hver skript du skriver, og hver grep du gjør, må være skrevet for å ignorere disse .svn kataloger. Du trenger også en hel kommando ( "svn eksport") bare for å få en normal kopi av filene dine.
  4. I SVN, kan hver fil og mappe kommer fra en annen revisjon eller gren. Ved første, høres det fint å ha denne friheten. Men hva dette egentlig betyr er at det er en million forskjellige måter for den lokale kassen for å være skrudd helt opp. (For eksempel hvis "svn switch" svikter halvveis gjennom, eller hvis du skriver inn en kommando feil). Og det verste er: hvis du skulle komme i en situasjon hvor noen av filene kommer fra et sted, og noen av dem fra hverandre, "svn status" vil fortelle deg at alt er normalt. Du må gjøre "svn info" på hver fil / katalog å oppdage hvor rare ting er. Hvis "git status" forteller deg at ting er normalt, så kan du stole på at ting egentlig er normal.
  5. Du må fortelle SVN når du flytter eller sletter noe. Git vil bare finne ut av det.
  6. Ignorer semantikk er lettere i Git. Hvis du ignorerer et mønster (for eksempel * .pyc), vil det bli ignorert for alle underkataloger. (Men hvis du virkelig ønsker å ignorere noe for bare en katalog, kan du). Med SVN, virker det som det er ingen enkel måte å ignorere et mønster på tvers av alle underkataloger.
  7. Et annet element som involverer ignorere filer. Git gjør det mulig å ha "privat" ignorere innstillingene (ved hjelp av filen .git / info / ekskludere), som ikke vil påvirke noen andre.
Svarte 26/09/2008 kl. 00:18
kilden bruker

stemmer
56

" Hvorfor Git er bedre enn X " skisserer ulike fordeler og ulemper med Git vs andre SCMS.

Kort:

  • Git sporer innhold i stedet filer
  • Grener er lette og sammenslåing er enkel , og jeg mener virkelig enkelt .
  • Det er distribuert, i utgangspunktet alle depotene er en gren. Det er mye lettere å utvikle samtidig og samarbeide enn med Subversion, etter min mening. Det gjør også offline utvikling mulig.
  • Det pålegger ikke noen arbeidsflyt , sett på de ovennevnte tilknyttede hjemmesider , er det mange arbeidsflyter er mulig med Git. En Subversion-stil arbeidsflyt er lett etterlignet.
  • Git-lagrene er mye mindre i filstørrelse enn Subversiondepoter. Det er bare én ".git" katalog, i motsetning til mange ".svn" repositories (merk Subversion 1.7 og høyere nå bruker en enkelt katalog som Git.)
  • Den staging området er fantastisk, det kan du se endringene du vil begå, forplikte delvis endringer og gjøre diverse andre ting.
  • Stashing er uvurderlig når du gjør "kaotisk" utvikling, eller bare ønsker å fikse en feil mens du fortsatt jobber med noe annet (på en annen gren).
  • Du kan skrive om historien , som er flott for å forberede patch sett og fikse feilene dine ( før du publiserer inger)
  • ... og mye mer.

Det er noen ulemper:

  • Det er ikke mange gode GUI for det ennå. Det er nytt og Subversion har eksistert mye lenger, så dette er naturlig som det er noen grensesnitt i utvikling. Noen gode inkludere TortoiseGit og GitHub for Mac .
  • Delvis kassene / kloner av depotene er ikke mulig for øyeblikket (jeg leste at det er under utvikling). Men det er submodule støtte. Git 1.7+ støtter sparsom kassene .
  • Det kan være vanskeligere å lære, selv om jeg ikke synes dette å være tilfelle (om et år siden). Git har nylig forbedret sitt grensesnitt og er ganske brukervennlig.

I den mest forenklede bruk, Subversion og Git er ganske mye det samme. Det er ikke mye forskjell mellom:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

og

git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Hvor Git virkelig skinner er forgrening og arbeid med andre mennesker.

Svarte 10/02/2009 kl. 04:18
kilden bruker

stemmer
54

Google Tech Talk: Linus Torvalds på git

http://www.youtube.com/watch?v=4XpnKHJAok8

Den Git Wiki sammenligningssiden

http://git.or.cz/gitwiki/GitSvnComparsion

Svarte 03/08/2008 kl. 22:44
kilden bruker

stemmer
26

Vel, det er fordelt. Benchmarks viser at det er betydelig raskere (gitt sin distribuerte natur, operasjoner som differ og logger er alle lokale, så det er selvfølgelig super raskere i dette tilfellet), og arbeidsmapper er mindre (som fortsatt blåser meg).

Når du jobber med omveltning, eller noen annen klient / server revisjonskontroll system, du egentlig lage arbeidskopier på din maskin ved å sjekke ut revisjoner. Dette representerer et øyeblikksbilde i tid av hva depotet ser ut. Du oppdaterer arbeidskopien via oppdateringer, og du oppdaterer depotet via inger.

Med et distribuert versjonskontroll, trenger du ikke et øyeblikksbilde, men snarere hele kodebasen. Vil gjøre en diff med en 3 måneder gammel versjon? Ikke noe problem, er det tre måneder gamle versjonen fortsatt på datamaskinen din. Dette betyr ikke bare ting er måten raskere, men hvis du er koblet fra den sentrale server, kan du fortsatt gjøre mange av de operasjonene du er vant til. Med andre ord, har du ikke bare et øyeblikksbilde av en gitt revisjon, men hele kodebasen.

Man skulle tro at Git ville ta opp en haug med plass på harddisken din, men fra et par benchmarks jeg har sett, er det faktisk tar mindre. Ikke spør meg hvordan. Jeg mener, det ble bygget av Linus, han vet en ting eller to om filsystemer jeg gjette.

Svarte 03/08/2008 kl. 22:47
kilden bruker

stemmer
22

De viktigste punktene jeg liker DVCS er de:

  1. Du kan begå ødelagte ting. Det spiller ingen rolle, fordi andre folk ikke vil se dem før du publiserer. Publisere tid er forskjellig fra å begå tid.
  2. På grunn av dette kan du begår oftere.
  3. Du kan flette komplett functionnality. Dette functionnality vil ha sin egen gren. Alle inger av denne grenen vil være relatert til dette functionnality. Du kan gjøre det med en SVK men med DVCS sin standard.
  4. Du kan søke i loggen (finne når en funksjon endres)
  5. Du kan angre et trekk hvis noen skru opp hoved depotet, trenger du ikke å fikse feilene. Bare fjerne sammenslåingen.
  6. Når du trenger en kilde kontroll i en katalog gjøre: git init. og du kan begå, angre endringer, osv ...
  7. Det er raskt (selv på Windows)

Den viktigste grunnen for et relativt stort prosjekt er det bedre kommunikasjon skapt av poenget 3. Andre er hyggelig bonuser.

Svarte 04/09/2008 kl. 11:06
kilden bruker

stemmer
15

Det morsomme er: jeg vert prosjekter i Subversion Repos, men tilgang til dem via Git Clone kommandoen.

Vennligst les Utvikle med Git på Google Code Prosjekt

Selv om Google Code opprinnelig snakker Subversion, kan du enkelt bruke Git under utvikling. Søker etter "git svn" antyder denne praksisen er utbredt, og vi også oppfordre deg til å eksperimentere med det.

Ved hjelp av Git på en SVN gir meg fordeler:

  1. Jeg kan jobbe fordelt på flere maskiner, forplikter og trekke fra og til dem
  2. Jeg har en sentral backup/public svn oppbevaringssted for andre å sjekke ut
  3. Og de er fri til å bruke Git for sin egen
Svarte 02/10/2008 kl. 13:05
kilden bruker

stemmer
11

Alle svarene her er som forventet, programmerer risk, men hva skjer hvis firmaet bruker revisjonskontroll utenfor kildekoden? Det er mange dokumenter som ikke er kildekoden som drar nytte av versjonskontroll, og skal leve nær kode og ikke i en annen CMS. De fleste programmerere virker ikke i isolasjon - vi jobber for selskaper som en del av et team.

Med det i tankene, sammenlign brukervennlighet, både klient verktøy og trening, mellom Subversion og git. Jeg kan ikke se et scenario der noen distribuert revisjonskontrollsystem skal være enklere å bruke, eller forklare til en ikke-programmerer. Jeg vil gjerne bli vist feil, for da ville jeg være i stand til å vurdere git og faktisk har et håp om at det blir akseptert av folk som trenger versjonskontroll som ikke er programmerere.

Selv da, hvis du blir bedt av ledelsen hvorfor vi skal flytte fra en sentralisert til distribuert revisjonskontroll system, ville jeg bli hardt presset til å gi et ærlig svar, fordi vi ikke trenger det.

Disclaimer: Jeg ble interessert i Subversion tidlig (rundt v0.29) så åpenbart jeg er partisk, men selskapene jeg har jobbet for siden den gang drar nytte av min entusiasme fordi jeg har oppmuntret og støttet bruken. Jeg mistenker at dette er hvordan det skjer med de fleste programvareselskaper. Med så mange programmerere hoppe på git bandwagon, jeg lurer på hvor mange selskaper kommer til å gå glipp av fordelene ved å bruke versjonskontroll utenfor kildekoden? Selv om du har separate systemer for forskjellige lag, er du glipp av noen av fordelene, som (samlet) problemet sporing integrasjon, mens økende vedlikehold, maskinvare og krav til opplæring.

Svarte 13/10/2009 kl. 07:01
kilden bruker

stemmer
9

Subversion er fortsatt en mye mer brukt versjonskontrollsystem, noe som betyr at den har bedre verktøy støtte. Du vil finne modne SVN plugins for nesten alle IDE , og det er gode explorer utvidelser tilgjengelig (som TurtoiseSVN). Annet enn det, vil jeg må være enig med Michael : Git er ikke bedre eller verre enn Subversion, er det annerledes.

Svarte 18/09/2008 kl. 18:44
kilden bruker

stemmer
8

David Richards WANdisco Blogg på Subversion / GIT

Fremveksten av GIT har brakt med seg en rase av DVCS fundamentalister - den 'Gitterons' - som tror noe annet enn GIT er crap. De Gitterons synes å mene software engineering som skjer på sin egen øy, og ofte glemmer at de fleste organisasjoner ikke ansette senior programvare ingeniører eksklusivt. Det er ok, men det er ikke hvordan resten av markedet tenker, og jeg er glad for å bevise det: GIT, ved siste blikk hadde mindre enn tre prosent av markedet, mens Subversion har i regionen på fem millioner brukere og omtrent halvparten av det totale markedet.

Problemet vi så var at Gitterons var skyting (billig) skudd på Subversion. Tweets som “Subversion er så [treg / crappy / restriktiv / lukter ikke godt / ser på meg på en morsom måte] og nå har jeg GIT og [alt fungerer i mitt liv / min kone ble gravid / fikk jeg en venninne etter 30 år med å prøve / jeg vant seks ganger kjører på blackjack-bord]. Du får bildet.

Svarte 17/09/2010 kl. 18:22
kilden bruker

stemmer
8

En av de tingene om Subversion som irriterer meg er at det setter en egen mappe i hver katalog av et prosjekt, mens git bare setter en i rotkatalogen. Det er ikke at stor av en avtale, men små ting som det legger opp.

Selvfølgelig har Subversion Tortoise, som er [vanligvis] veldig hyggelig.

Svarte 22/08/2008 kl. 15:24
kilden bruker

stemmer
7

Git gjør også forgreninger og fletting virkelig enkelt. Subversion 1.5 nettopp lagt merge sporing, men Git er fortsatt bedre. Med Git forgrening er svært rask og billig. Det gjør lage en gren for hver ny funksjon mer gjennomførbart. Oh og Git-lagrene er svært effektive med lagringsplass i forhold til Subversion.

Svarte 09/08/2008 kl. 03:22
kilden bruker

stemmer
6

Easy Git har en fin side å sammenligne faktiske bruk av Git og SVN som vil gi deg en idé om hva ting Git kan gjøre (eller gjøre lettere) sammenlignet med SVN. (Teknisk sett dette er basert på Easy Git, som er en lett wrapper på toppen av Git.)

Svarte 22/08/2008 kl. 15:19
kilden bruker

stemmer
6

Det handler om brukervennlighet / trinn som kreves for å gjøre noe.

Hvis jeg utvikle et enkelt prosjekt på min PC / laptop, er git bedre, fordi det er langt enklere å sette opp og bruke. Du trenger ikke en server, og du trenger ikke å fortsette å skrive depot URL-er i når du gjør fusjonerer.

Hvis det var bare 2 personer, vil jeg si git er også lettere, fordi du kan bare dytte og dra fra hverandre.

Når du får utover det selv, ville jeg gå for undergraving, fordi på det tidspunktet du trenger for å sette opp en 'dedikert' server eller sted.

Du kan gjøre dette like godt med git som med SVN, men fordelene med git bli oppveies av behovet for å gjøre ytterligere tiltak for å samkjøre med en sentral server. I SVN du nettopp har begått. I git må du git begå, da git push. Den ekstra trinnet blir irriterende rett og slett fordi du ende opp med å gjøre det så mye.

SVN har også fordelen av bedre grafiske verktøy, men git økosystemet synes å være å fange opp raskt, så jeg ville ikke bekymre deg for dette på lang sikt.

Svarte 03/08/2008 kl. 23:38
kilden bruker

stemmer
5

Jeg liker Git fordi det faktisk bidrar til kommunikasjon utvikler til utbygger på et middels til stort team. Som et distribuert versjonskontrollsystem, gjennom sin push / pull system, det hjelper utviklere å lage en kildekode øko-system som bidrar til å styre en stor pool av utviklere som arbeider på et enkelt prosjekt.

For eksempel si at du stoler på 5 utviklere og bare trekke koder fra deres depotet. Hver av disse utviklerne har sin egen tillit nettverket fra hvor de trekker koder. Dermed utviklingen er basert på at tillit stoff utviklere hvor kode ansvaret er delt mellom utviklingen samfunnet.

Selvfølgelig er det andre fordeler som er nevnt i andre svar her.

Svarte 05/10/2008 kl. 16:52
kilden bruker

stemmer
5

Git og DVCS generelt er stor for utviklere å gjøre en masse koding uavhengig av hverandre fordi alle har sin egen gren. Hvis du trenger en endring fra noen andre, men hun har til å forplikte seg til sin lokale repo og hun må presse at forandrings til deg eller du må trekke den fra henne.

Mitt eget resonnement også gjør meg til å tenke DVCS gjør ting vanskeligere for QA og slipp styring hvis du gjør ting som sentraliserte utgivelser. Noen må ha ansvaret for å gjøre det push / pull fra alle andres depotet, løse eventuelle konflikter som ville ha blitt løst ved første gangs begå før, så gjør bygge, og så har alle de andre utviklerne re-sync sine repos.

Alt dette kan løses med menneskelige prosesser, selvfølgelig; DVCS bare brøt noe som ble løst ved sentralisert versjonskontroll for å gi noen nye bekvemmeligheter.

Svarte 03/08/2008 kl. 23:08
kilden bruker

stemmer
4

Jeg tror Subversion er greit .. før du begynner å flette .. eller gjør noe komplisert .. eller gjør noe Subversion mener er komplisert (som gjør søk for å finne ut hvilke grener søl med en bestemt fil, der en endring faktisk kommer fra, oppdage kopier og pastaer , etc)...

Jeg er uenig med den vinnende svaret, sier den viktigste fordelen av GIT er offline arbeid - det er sikkert nyttig, men det er mer som en ekstra for min bruk sak. SVK kan arbeide offline også, fortsatt er det ingen tvil for meg som en til å investere min læretid i).

Det er bare at det er utrolig kraftig og rask og, vel -etter å bli vant til begrepene - veldig nyttig (ja, i den forstand: brukervennlig).

For mer informasjon om en sammenslåing historie, se denne: Bruke git-svn (eller lignende) * bare * å hjelpe til med en svn merge?

Svarte 27/07/2010 kl. 15:40
kilden bruker

stemmer
4

Noen svar har antydet dette, men jeg ønsker å gjøre 2 poeng eksplisitt:

1) Muligheten for å gjøre selektive inger (for eksempel git add --patch). Hvis arbeidsmappen inneholder flere endringer som ikke er del av den samme logiske endring, Git gjør det svært enkelt å lage en iverksetting som inneholder bare en del av endringene. Med Subversion, er det vanskelig.

2) Muligheten til å begå uten å gjøre endringen publikum. I Subversion noen begår er umiddelbart offentlig, og dermed ugjenkallelig. Dette begrenser sterkt muligheten for utvikleren å "begå tidlig, begår ofte".

Git er mer enn bare en VCS; det er også et verktøy for å utvikle patcher. Subversion er bare en VCS.

Svarte 07/08/2009 kl. 14:59
kilden bruker

stemmer
3

Dette er feil spørsmål å spørre. Det er altfor lett å fokusere på git vorter og formulere et argument om hvorfor subversion er tilsynelatende bedre, i hvert fall for noen brukstilfeller. Det faktum at git ble opprinnelig utviklet som et lavt nivå versjonskontroll byggesettet og har en barokk linux-utvikler-orientert grensesnitt gjør det lettere for de hellige kriger for å få trekkraft og oppfattet legitimitet. Git talsmenn bang trommelen med millioner av arbeidsflyt fordeler, som svn gutta forkynne unødvendig. Ganske snart hele debatten er innrammet som sentralisert vs distribuert, som tjener interessene til bedriften svn verktøy samfunnet. Disse selskapene, som vanligvis legger ut de mest overbevisende artikler om undergraving overlegenhet i bedriften, er avhengig av det som oppfattes som usikkerhet i git og enterprise-beredskap av svn for langsiktig suksess for sine produkter.

Men her er problemet: Subversion er en arkitektonisk blindvei .

Mens du kan ta git og bygge et sentralisert omveltning erstatning ganske lett, til tross for at rundt i mer enn dobbelt så lenge svn har aldri vært i stand til å få selv grunnleggende merge-sporing arbeider på langt nær så godt som den gjør i git. En grunnleggende årsak til dette er utformingen avgjørelse å ta grener på samme måte som kataloger. Jeg vet ikke hvorfor de gikk på denne måten opprinnelig, sikkert gjør det delvis kassene veldig enkelt. Dessverre gjør det også umulig å spore historien riktig. Nå åpenbart du skal bruke Subversion layout konvensjoner for å skille greiner fra vanlige kataloger, og svn bruker noen heuristikk for å gjøre ting fungerer for den daglige bruk tilfeller. Men alt dette er bare tapetsering over en svært dårlig og begrense lavt nivå design beslutning. Å kunne en gjøre en depot-messig diff (i stedet for katalog-messig diff) er grunnleggende og kritisk funksjonalitet for et versjonskontrollsystem, og forenkler det innvendige, noe som gjør det mulig å bygge smartere og nyttige funksjoner på toppen av det. Du kan se på mengden arbeid som har blitt satt inn som strekker omveltning, og likevel hvor langt bak det er fra dagens avling av moderne VCSes i form av grunnleggende operasjoner som merge oppløsning.

Nå her er mitt hjerte-filt og agnostiker råd til alle som fortsatt tror Subversion er god nok i overskuelig fremtid:

Subversion vil aldri nå opp til de nyere raser av VCSes som har lært av feilene fra RCS og CVS; det er en teknisk umulighet med mindre de endre seg depotet modell fra grunnen av, men da ville det egentlig ikke bli svn ville det? Uansett hvor mye du tror du ikke egenskapene til en moderne VCS, din uvitenhet vil ikke beskytte deg fra Subversions fallgruver, hvorav mange er situasjoner som er umulig eller lett løses i andre systemer.

Det er svært sjelden at den tekniske underlegenhet av en løsning er så entydig som det er med svn, sikkert jeg ville aldri oppgi slik uttalelse om vinn-vs-linux eller emacs-vs-vi, men i dette tilfellet er det så entydig, og kildekontroll er en så grunnleggende verktøy i utviklerens arsenal, at jeg føler at det må oppgis utvetydig. Uavhengig av kravet om å bruke svn for organisatoriske grunner, jeg bønnfaller alle svn brukerne ikke å la deres logiske tankene konstruere en falsk tro at mer moderne VCSes er bare nyttig for store åpen kildekode-prosjekter. Uavhengig av innholdet i din utviklingsarbeid, hvis du er en programmerer, vil du bli en mer effektiv programmerer hvis du lære å bruke bedre designede VCSes, enten det er Git, Mercurial, darc, eller mange andre.

Svarte 29/05/2011 kl. 17:30
kilden bruker

stemmer
3

Jeg elsker å være i stand til å håndtere lokale grener av min kildekode i Git uten muddying ut vannet i det sentrale lageret. I mange tilfeller vil jeg kassa koden fra Subversionserver og kjøre en lokal Git repository bare for å være i stand til å gjøre dette. Det er også flott at initialisere en Git repository forurenser ikke det filsystemet med en haug av irriterende .svn mapper overalt.

Og så langt som verktøy støtter Windows, håndterer TortoiseGit det grunnleggende godt, men jeg foretrekker kommandolinjen med mindre jeg ønsker å vise loggen. Jeg liker måten Tortoise {Git | SVN} hjelper når du leser loggmeldinger.

Svarte 10/02/2010 kl. 22:54
kilden bruker

stemmer
3

Takket være det faktum at det ikke trenger å kommunisere med en sentral server hele tiden, ganske mye hver kommandoen kjører i mindre enn ett sekund (selvsagt git push / pull / hente er tregere rett og slett fordi de må initalise SSH forbindelser). Forgrening er langt langt enklere (en enkel kommando for å gren, til en enkel kommando fusjonere)

Svarte 30/08/2008 kl. 12:01
kilden bruker

stemmer
2

For folk på jakt etter en god Git GUI, Syntevo SmartGit kan være en god løsning. Sin proprietære, men gratis for ikke-kommersiell bruk, kjører på Windows / Mac / Linux og selv støtter SVN å bruke noen form for git-svn bro, tror jeg.

Svarte 09/03/2011 kl. 14:05
kilden bruker

stemmer
2

Eric Sink fra SourceGear skrev artikkelserie om forskjellene mellom distribuert og nondistributed versjonskontroller systemer. Han sammenligner fordeler og ulemper med de fleste populære versjonskontrollsystemer. Veldig interessant lesning.
Artiklene kan bli funnet på sin blogg, www.ericsink.com :

Svarte 13/10/2009 kl. 13:36
kilden bruker

stemmer
2

Subversion er svært enkel å bruke. Jeg har aldri funnet i de siste årene et problem eller at noe ikke fungerer som forventet. Også er det mange gode grafiske verktøy og støtte for SVN integrering er stor.

Med Git får du en mer fleksibel VCS. Du kan bruke den på samme måte som SVN med en fjernlager der du forplikte alle endringer. Men du kan også bruke den stort sett offline og bare skyve endringer fra tid til annen for å fjernlager. Men Git er mer kompleks og har en brattere læringskurve. Jeg fant meg selv i første gang å binde seg til feil grener, lage grener indirekte eller få feilmeldinger med ikke mye informasjon om feilen og hvor jeg skal søke med Google for å få bedre informasjon. Noen enkle ting som substitusjon av markører ($ Id $) virker ikke, men GIT har en svært fleksibel filtrering og krok mekanisme for å fusjonere egne skript, og slik at du får alt du trenger og mer, men det er behov for mer tid og lesing av dokumentasjonen ;)

Hvis du jobber for det meste offline med din lokale repository du ikke har noen backup hvis noe går tapt på din lokale maskin. Med SVN du det meste jobber med en ekstern depot som også samtidig backup på en annen server ... Git kan arbeide på samme måte, men dette var ikke det viktigste målet for Linus å ha noe sånt SVN2. Den ble utviklet for Linux-kjernen utviklere og behovene til en distribuert versjonskontrollsystem.

Er Git bedre da SVN? Utviklere som trenger bare en versjon historie og en backup mekanisme har et godt og enkelt liv med SVN. Utviklere som arbeider ofte med grener, testing flere versjoner samtidig eller arbeider hovedsakelig offline kan dra nytte av funksjonene i Git. Det er noen svært nyttige funksjoner som stashing ikke funnet med SVN som kan gjøre livet enklere. Men på den andre siden ikke alle mennesker vil trenge alle funksjoner. Så jeg kan ikke se den døde av SVN.

Git trenger litt bedre dokumentasjon og feilrapportering må være mer nyttig. Også eksisterende nyttige GUI er bare sjelden. Denne gangen har jeg funnet bare en GUI for Linux med støtte for de fleste Git funksjoner (git-cola). Eclipse integreringen fungerer, men det er ikke offisielt lansert, og det er ingen offisiell oppdatering området (bare noen ekstern oppdatering nettsted med periodisk bygger fra stammen http://www.jgit.org/updates ) Så den mest foretrukne måten å bruke Git denne dager blir kommandoen.

Svarte 13/10/2009 kl. 13:14
kilden bruker

stemmer
1

Hvorfor jeg tror Subversion er bedre enn Git (i hvert fall for de prosjektene jeg jobber på), hovedsakelig på grunn av sin brukervennlighet og enklere arbeidsflyt:

http://www.databasesandlife.com/why-subversion-is-better-than-git/

Svarte 22/10/2010 kl. 16:25
kilden bruker

stemmer
1

Jeg har blitt boende i Git land i det siste, og jeg liker det for personlige prosjekter, men jeg ville ikke være i stand til å bytte arbeidsprosjekter til det ennå fra Subversion gitt endring i tenkning som kreves fra ansatte, uten noen presserende fordeler. Dess det største prosjektet vi kjører i-huset er svært avhengig av svn: externals som, etter hva jeg har sett så langt, ikke fungerer så pent og sømløst i Git.

Svarte 25/04/2010 kl. 21:35
kilden bruker

stemmer
1

http://subversion.wandisco.com/component/content/article/1/40.html

Jeg tror det er ganske trygt å si at blant utviklere, SVN Vs. Git argument har pågått i noen tid nå, med alle har sitt eget syn på noe som er bedre. Dette ble også tatt opp i av spørsmålene under Webinar på Subversion i 2010 og utover.

Hyrum Wright, vår direktør for Open Source og presidenten for Subversion Corporation snakker om forskjellene mellom Subversion og Git, sammen med andre distribuerte versjonskontrollsystemer (DVCS).

Han snakker også om de kommende endringene i Subversion, som for eksempel arbeidskopi Next Generation (WC-NG), som han mener vil føre til en rekke Git brukere å konvertere tilbake til Subversion.

Ha en klokke av hans video og fortell oss hva du synes ved enten å kommentere på denne bloggen, eller ved å legge ut i våre fora. Registreringen er enkel og tar bare et øyeblikk!

Svarte 10/02/2010 kl. 18:51
kilden bruker

stemmer
1

Git i Windows er ganske godt støttet nå.

Sjekk ut GitExtensions = http://code.google.com/p/gitextensions/

og manual for en bedre Windows Git opplevelse.

Svarte 10/02/2010 kl. 16:29
kilden bruker

stemmer
1

Først synes samtidig versjonskontroll som et enkelt problem å løse. Det er ikke i det hele tatt. Uansett...

SVN er ganske ikke-intuitive. Git er enda verre. [Sarkastisk-spekulasjon] Dette kan være fordi utviklere, som liker harde problemer som samtidig versjonskontroll, har ikke mye interesse i å gjøre en god UI. [/ Spydig-spekulasjon]

SVN støttespillere tror de ikke trenger et distribuert versjonskontrollsystem. Jeg trodde det også. Men nå som vi bruker Git utelukkende, jeg er en troende. Nå versjonskontroll som fungerer for meg og laget / prosjekt i stedet for bare å arbeide for prosjektet. Når jeg trenger en gren, gren jeg. Noen ganger er det en gren som har en tilsvarende avdeling på serveren, og noen ganger er det ikke. For ikke å nevne alle de andre fordelene som jeg må gå studere opp på (delvis takket være uforståelige og absurde mangel på UI som er en moderne versjon kontrollsystem).

Svarte 03/01/2010 kl. 12:45
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more