Perché Git è meglio di Subversion?

Sto usando Subversion da alcuni anni e dopo aver usato SourceSafe , adoro Subversion. In combinazione con TortoiseSVN , non riesco davvero a immaginare come potrebbe essere meglio.

Eppure c’è un numero crescente di sviluppatori che sostengono che Subversion ha problemi e che dovremmo passare alla nuova generazione di sistemi di controllo delle versioni distribuite, come Git .

In che modo Git migliora su Subversion?

Git non è migliore di Subversion. Ma non è anche peggio. È diverso.

La differenza principale è che è decentralizzato. Immagina di essere uno sviluppatore sulla strada, di sviluppare sul tuo laptop e di avere il controllo del codice sorgente in modo da poter tornare indietro di 3 ore.

Con Subversion hai un problema: il repository SVN potrebbe trovarsi in una posizione che non puoi raggiungere (nella tua azienda e al momento non hai Internet), non puoi impegnarti. Se vuoi fare una copia del tuo codice, devi letteralmente copiarlo / incollarlo.

Con Git, non hai questo problema. La tua copia locale è un repository e puoi impegnarti a farlo e ottenere tutti i vantaggi del controllo del codice sorgente. Quando riacquisti la connettività al repository principale, puoi impegnarti contro di esso.

All’inizio sembra buono, ma tieni a mente la maggiore complessità di questo approccio.

Git sembra essere la cosa “nuova, brillante, fresca”. Non è affatto male (c’è una ragione per cui Linus lo ha scritto per lo sviluppo del Kernel Linux dopo tutto), ma sento che molte persone saltano sul treno “Distributed Source Control” solo perché è nuovo ed è scritto da Linus Torvalds, senza effettivamente sapendo perché / se è meglio.

Subversion ha problemi, ma anche Git, Mercurial, CVS, TFS o altro.

Edit: Quindi questa risposta ora ha un anno e genera ancora molti upvotes, quindi ho pensato di aggiungere ulteriori spiegazioni. Nell’ultimo anno da quando ho scritto questo, Git ha guadagnato molto slancio e supporto, soprattutto perché siti come GitHub sono decollati davvero. Sto usando Git e Subversion al giorno d’oggi e mi piacerebbe condividere alcune intuizioni personali.

Prima di tutto, Git può essere davvero confuso all’inizio quando si lavora in modo decentralizzato. Cos’è un telecomando? e come impostare correttamente il repository iniziale? sono due domande che sorgono all’inizio, specialmente rispetto al semplice “svnadmin create” di SVN, Git’s “git init” può prendere i parametri –bare e –shared che sembra essere il modo “corretto” per impostare un sistema centralizzato repository. Ci sono ragioni per questo, ma aggiunge complessità. La documentazione del comando “checkout” è molto confusa per le persone che cambiano – il modo “corretto” sembra essere “git clone”, mentre “git checkout” sembra cambiare ramo.

Git VERAMENTE brilla quando sei decentrato. Ho un server a casa e un laptop sulla strada, e SVN semplicemente non funziona bene qui. Con SVN, non posso avere il controllo del codice sorgente locale se non sono connesso al repository (Sì, so su SVK o sui modi per copiare il repository). Con Git, è comunque la modalità predefinita. È comunque un comando extra (commit git commit localmente, mentre git push origin master spinge il ramo master sul remoto chiamato “origin”).

Come detto sopra: Git aggiunge complessità. Due modalità di creazione di repository, checkout vs clone, commit vs. push … Devi sapere quali comandi funzionano localmente e quali funzionano con “il server” (presumo che la maggior parte delle persone abbia ancora un “master-repository” centrale ).

Inoltre, gli strumenti sono ancora insufficienti, almeno su Windows. Sì, c’è un AddIn di Visual Studio, ma uso ancora git bash con msysgit.

SVN ha il vantaggio che è MOLTO più semplice da imparare: c’è il tuo repository, tutti i cambiamenti verso di esso, se sai come creare, eseguire il commit e checkout e sei pronto per andare a raccogliere cose come ramificazioni, aggiornamenti, ecc. sopra.

Git ha il vantaggio che è MOLTO più adatto se alcuni sviluppatori non sono sempre connessi al repository principale. Inoltre, è molto più veloce di SVN. E da quanto ho sentito, il supporto per ramificazioni e fusioni è molto migliore (il che è prevedibile, in quanto questi sono i motivi principali per cui è stato scritto).

Questo spiega anche perché guadagna così tanto entusiasmo su Internet, dato che Git è perfettamente adatto per i progetti Open Source: Just Fork, commetti le modifiche al tuo Fork personale, quindi chiedi al maintainer del progetto originale di ritirare le tue modifiche. Con Git, questo funziona. Davvero, provalo su Github, è magico.

Quello che vedo anche sono Git-SVN Bridges: il repository centrale è un repo di Subversion, ma gli sviluppatori lavorano localmente con Git e il bridge quindi trasferisce le loro modifiche a SVN.

Ma nonostante questa lunga aggiunta, resto ancora nel mio messaggio principale: Git non è migliore o peggiore, è solo diverso. Se hai bisogno di “Controllo del codice sorgente offline” e la volontà di dedicare un po ‘più di tempo ad apprenderlo, è fantastico. Ma se hai un controllo sorgente rigorosamente centralizzato e / o stai faticando a introdurre il controllo del codice sorgente in primo luogo perché i tuoi colleghi non sono interessati, allora la semplicità e gli eccellenti strumenti (almeno su Windows) di SVN brillano.

Con Git, puoi fare praticamente qualsiasi cosa offline, perché ognuno ha il proprio repository.

Creare filiali e fondersi tra filiali è davvero facile.

Anche se non hai diritti di commit per un progetto, puoi comunque avere il tuo repository online e pubblicare “richieste push” per le tue patch. Tutti quelli a cui piacciono le tue patch possono inserirli nel loro progetto, inclusi i manutentori ufficiali.

È banale imbustare un progetto, modificarlo e continuare a fondersi con le correzioni dei bug del ramo HEAD.

Git funziona per gli sviluppatori del kernel di Linux. Ciò significa che è molto veloce (deve essere) e si adatta a migliaia di contributori. Git usa anche meno spazio (fino a 30 volte meno spazio per il repository Mozilla).

Git è molto flessibile, molto TIMTOWTDI (c’è più di un modo per farlo). Puoi usare qualsiasi stream di lavoro che vuoi e Git lo supporterà.

Infine, c’è GitHub , un ottimo sito per ospitare i repository Git.

Svantaggi di Git:

  • è molto più difficile da imparare, perché Git ha più concetti e più comandi.
  • le revisioni non hanno numeri di versione come in sovversione
  • molti comandi Git sono criptici e i messaggi di errore sono molto poco intuitivi
  • manca una buona GUI (come il grande TortoiseSVN )

Altre risposte hanno fatto un buon lavoro di spiegazione delle caratteristiche principali di Git (che sono grandi). Ma ci sono anche tanti piccoli modi in cui Git si comporta meglio e aiuta a mantenere la mia vita più sana di mente. Ecco alcune delle piccole cose:

  1. Git ha un comando ‘pulito’. SVN ha un disperato bisogno di questo comando, considerando la frequenza con cui scaricherà file extra sul disco.
  2. Git ha il comando ‘bisect’. È carino.
  3. SVN crea directory .svn in ogni singola cartella (Git crea solo una directory .git). Ogni script che scrivi e ogni grep che fai, dovrà essere scritto per ignorare queste directory .svn. Hai anche bisogno di un intero comando (“svn export”) solo per ottenere una copia sensata dei tuoi file.
  4. In SVN, ogni file e cartella può provenire da una revisione o una filiale diversa. All’inizio, sembra bello avere questa libertà. Ma ciò che questo significa in realtà è che ci sono un milione di modi diversi per il checkout locale di essere completamente rovinato. (ad esempio, se “svn switch” fallisce a metà, o se si inserisce un comando errato). E la parte peggiore è: se ti trovi in ​​una situazione in cui alcuni dei tuoi file provengono da un posto, e alcuni di loro da un altro, lo “svn status” ti dirà che tutto è normale. Dovrai fare “svn info” su ogni file / directory per scoprire come sono strane le cose. Se “git status” ti dice che le cose sono normali, allora puoi fidarti che le cose sono davvero normali.
  5. Devi dire a SVN ogni volta che muovi o cancelli qualcosa. Git lo scoprirà.
  6. Ignorare la semantica è più facile in Git. Se ignori un pattern (come * .pyc), verrà ignorato per tutte le sottodirectory. (Ma se vuoi davvero ignorare qualcosa per una sola directory, puoi farlo). Con SVN, sembra che non ci sia un modo semplice per ignorare un modello in tutte le sottodirectory.
  7. Un altro elemento che coinvolge ignora i file. Git rende ansible avere impostazioni “private” di ignorare (usando il file .git / info / exclude), che non influenzerà nessun altro.

” Perché Git è meglio di X ” delinea i vari pro e contro di Git rispetto ad altri SCM.

Brevemente:

  • Git tiene traccia del contenuto piuttosto che dei file
  • I rami sono leggeri e la fusione è facile , e intendo davvero facile .
  • È distribuito, praticamente ogni repository è un ramo. È molto più facile da sviluppare contemporaneamente e in collaborazione rispetto a Subversion, secondo me. Rende anche ansible lo sviluppo offline .
  • Non impone alcun stream di lavoro , come visto sul sito Web collegato sopra , ci sono molti flussi di lavoro possibili con Git. Un stream di lavoro in stile Subversion viene facilmente imitato.
  • I repository Git sono molto più piccoli nella dimensione del file rispetto ai repository Subversion. C’è solo una directory “.git”, a differenza di dozzine di repository “.svn” (nota Subversion 1.7 e successivi ora usa una singola directory come Git.)
  • L’area di staging è fantastica, ti permette di vedere le modifiche che commetterai, commettere modifiche parziali e fare altre cose.
  • Lo stashing è inestimabile quando fai lo sviluppo “caotico”, o semplicemente vuoi correggere un bug mentre stai ancora lavorando su qualcos’altro (su un ramo diverso).
  • Puoi riscrivere la cronologia , che è ottima per preparare i set di patch e correggere i tuoi errori ( prima di pubblicare i commit)
  • … e molto altro

Ci sono alcuni svantaggi:

  • Non ci sono ancora molte buone GUI per questo. È nuovo e Subversion è in circolazione da molto più tempo, quindi è naturale perché ci sono alcune interfacce in fase di sviluppo. Alcuni buoni includono TortoiseGit e GitHub per Mac .
  • Al momento non è ansible effettuare il checkout parziale / clone dei repository (ho letto che è in sviluppo). Tuttavia, esiste un supporto per i sottomoduli. Git 1.7+ supporta controlli sparsi .
  • Potrebbe essere più difficile da imparare, anche se non ho trovato che fosse così (circa un anno fa). Git ha recentemente migliorato la sua interfaccia ed è abbastanza intuitivo.

Nell’uso più semplicistico, Subversion e Git sono praticamente la stessa cosa. Non c’è molta differenza tra:

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

e

 git clone [email protected]:foo/bar.git cd bar # edit git commit -a -m "foo" git push 

Dove Git brilla davvero è ramificazione e collaborazione con altre persone.

Google Tech Talk: Linus Torvalds su git

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

La pagina di confronto di Git Wiki

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

Bene, è distribuito. I benchmark indicano che è considerevolmente più veloce (data la sua natura distribuita, le operazioni come diff e log sono tutte locali quindi ovviamente in questo caso è incredibilmente più veloce) e le cartelle di lavoro sono più piccole (cosa che mi fa impazzire ancora).

Quando si lavora su subversion, o su qualsiasi altro sistema di controllo di revisione client / server, si creano essenzialmente copie di lavoro sulla macchina eseguendo il check-out delle revisioni. Questo rappresenta un’istantanea in tempo di come appare il repository. Si aggiorna la propria copia di lavoro tramite aggiornamenti e si aggiorna il repository tramite commit.

Con un controllo di versione distribuito, non si dispone di un’istantanea, ma dell’intero codebase. Vuoi fare un diff con una versione vecchia di 3 mesi? Nessun problema, la versione di 3 mesi è ancora sul tuo computer. Questo non significa solo che le cose sono molto più veloci, ma se sei disconnesso dal tuo server centrale, puoi comunque eseguire molte delle operazioni a cui sei abituato. In altre parole, non si ha solo un’istantanea di una determinata revisione, ma l’intera base di codici.

Penseresti che Git occuperebbe un sacco di spazio sul tuo hard disk, ma da un paio di benchmark che ho visto, in realtà richiede meno. Non chiedermi come. Voglio dire, è stato costruito da Linus, lui sa una cosa o due sui filesystem che immagino.

I punti principali che mi piacciono di DVCS sono quelli:

  1. Puoi commettere cose rotte. Non importa perché gli altri popoli non li vedranno fino alla pubblicazione. Il tempo di pubblicazione è diverso dal tempo di commit.
  2. Per questo puoi impegnarti più spesso.
  3. Puoi unire funzionalità complete. Questa funzionalità avrà una propria diramazione. Tutti i commit di questo ramo saranno correlati a questa funzionalità. Puoi farlo con un CVCS, tuttavia con DVCS è l’impostazione predefinita.
  4. Puoi cercare la tua cronologia (trova quando una funzione è cambiata)
  5. È ansible annullare un pull se qualcuno rovina il repository principale, non è necessario correggere gli errori. Basta cancellare l’unione.
  6. Quando hai bisogno di un controllo del codice sorgente in qualsiasi directory, esegui: git init. e puoi commettere, annullare le modifiche, ecc …
  7. È veloce (anche su Windows)

La ragione principale di un progetto relativamente grande è la comunicazione migliorata creata dal punto 3. Altri sono dei buoni bonus.

La cosa divertente è: I progetti host in Subversion Repos, ma li accedo tramite il comando Git Clone.

Leggi lo sviluppo con Git su un progetto Google Code

Sebbene Google Code indichi in modo nativo Subversion, puoi facilmente utilizzare Git durante lo sviluppo. La ricerca di “git svn” suggerisce che questa pratica è diffusa e anche noi ti incoraggiamo a sperimentarla.

Usare Git su un repository Svn mi dà benefici:

  1. Posso lavorare distribuito su diverse macchine, impegnando e tirando da e verso di loro
  2. Ho un repository centrale di backup/public svn backup/public che gli altri possono controllare
  3. E sono liberi di usare Git per conto loro

Tutte le risposte qui sono come previsto, programmatore centric, ma cosa succede se la tua azienda utilizza il controllo di revisione al di fuori del codice sorgente? Ci sono molti documenti che non sono codice sorgente che traggono vantaggio dal controllo della versione e dovrebbero vivere vicino al codice e non in un altro CMS. La maggior parte dei programmatori non lavora in modo isolato: lavoriamo per le aziende come parte di un team.

Con questo in mente, confrontare la facilità d’uso, sia in termini di strumenti client che di addestramento, tra Subversion e git. Non riesco a vedere uno scenario in cui qualsiasi sistema di controllo di revisione distribuito sarà più facile da usare o da spiegare a un non programmatore. Mi piacerebbe essere smentito, perché poi sarei in grado di valutare git e in realtà avere una speranza che venga accettato da persone che hanno bisogno del controllo della versione che non sono programmatori.

Anche allora, se il management chiedesse il motivo per cui dovremmo passare da un sistema di controllo di revisione centralizzato a uno distribuito, mi sarebbe difficile dare una risposta onesta, perché non ne abbiamo bisogno.

Disclaimer: Mi sono interessato inizialmente a Subversion (intorno alla v0.29), quindi ovviamente sono di parte, ma le aziende per le quali ho lavorato da allora beneficiano del mio entusiasmo perché ho incoraggiato e supportato il suo utilizzo. Sospetto che sia così che succede con la maggior parte delle aziende di software. Con così tanti programmatori che saltano sul carro del git, mi chiedo quante aziende non potranno più sfruttare i vantaggi dell’utilizzo del controllo della versione al di fuori del codice sorgente? Anche se disponi di sistemi separati per team diversi, ti stai perdendo alcuni dei vantaggi, come l’integrazione del monitoraggio dei problemi (unificata), aumentando al contempo i requisiti di manutenzione, hardware e formazione.

Subversion è ancora un sistema di controllo delle versioni molto più utilizzato, il che significa che ha un migliore supporto per gli strumenti. Troverai plugin SVN maturi per quasi tutti gli IDE , e ci sono buone estensioni explorer disponibili (come TurtoiseSVN). Oltre a questo, dovrò essere d’accordo con Michael : Git non è migliore o peggiore di Subversion, è diverso.

Una delle cose su SubVersion che mi infastidisce è che mette la propria cartella in ogni directory di un progetto, mentre git ne mette solo uno nella directory root. Non è un grosso problema, ma piccole cose come quelle si sumno.

Ovviamente, SubVersion ha Tortoise, che è [di solito] molto carino.

David Richards WANdisco Blog su Subversion / GIT

L’emergere di GIT ha portato con sé una serie di fondamentalisti del DVCS – i “Gitteron” – che pensano che qualcosa di diverso dal GIT sia una schifezza. I Gitteron sembrano pensare che l’ingegneria del software avvenga sulla loro isola e spesso dimenticano che la maggior parte delle organizzazioni non impiega esclusivamente ingegneri esperti del software. Va bene, ma non è così che pensa il resto del mercato, e sono felice di dimostrarlo: GIT, all’ultima occhiata aveva meno del tre per cento del mercato mentre Subversion ha nella regione cinque milioni di utenti e circa la metà di il mercato generale.

Il problema che abbiamo visto è che i Gitteron sparavano colpi (a buon mercato) su Subversion. Tweets come “Subversion è così [lento / schifoso / restrittivo / non ha un buon profumo / mi guarda in modo divertente] e ora ho GIT e [tutto funziona nella mia vita / mia moglie è rimasta incinta / Ho avuto una ragazza dopo 30 anni di tentativi / Ho vinto sei volte sul tavolo del blackjack]. Ottieni l’immagine.

Git rende anche la ramificazione e la fusione veramente facili. Subversion 1.5 ha appena aggiunto il tracciamento delle unioni, ma Git è ancora migliore. Con la ramificazione di Git è molto veloce ed economico. Rende la creazione di un ramo per ogni nuova funzionalità più fattibile. I repository di Oh e Git sono molto efficienti con spazio di archiviazione rispetto a Subversion.

È tutto sulla facilità d’uso / passaggi necessari per fare qualcosa.

Se sto sviluppando un singolo progetto sul mio PC / laptop, git è migliore, perché è molto più facile da configurare e utilizzare. Non è necessario un server e non è necessario continuare a digitare l’URL del repository quando si esegue l’unione.

Se fossero solo 2 persone, direi che git è anche più facile, perché puoi semplicemente spingere e tirare l’uno dall’altro.

Una volta superato questo, preferirei la sovversione, perché a quel punto è necessario impostare un server o una posizione “dedicata”.

Puoi farlo altrettanto bene con git come con SVN, ma i benefici di git vengono superati dalla necessità di fare ulteriori passi per la sincronizzazione con un server centrale. In SVN devi solo impegnarti. In git devi git commit, quindi git push. Il passaggio aggiuntivo diventa fastidioso semplicemente perché finisci per farlo così tanto.

SVN ha anche il vantaggio di migliori strumenti GUI, tuttavia l’ecosistema git sembra recuperare rapidamente, quindi non mi preoccuperei di questo a lungo termine.

Easy Git ha una bella pagina che confronta l’uso effettivo di Git e SVN che ti darà un’idea di quali cose Git può fare (o fare più facilmente) rispetto a SVN. (Tecnicamente, questo è basato su Easy Git, che è un involucro leggero su Git.)

Git e DVCS in generale sono ottimi per gli sviluppatori che fanno molto codice indipendentemente l’uno dall’altro perché ognuno ha il proprio ramo. Se hai bisogno di un cambiamento da qualcun altro, però, lei deve impegnarsi con il suo repo locale e quindi deve spingerti quel changeset o devi estrarlo da lei.

Il mio ragionamento mi fa anche pensare che DVCS renda le cose più difficili per il controllo qualità e rilasci la gestione se fai cose come le versioni centralizzate. Qualcuno deve essere responsabile di fare quel push / pull dal repository di tutti gli altri, risolvendo eventuali conflitti che sarebbero stati risolti prima del commit iniziale, quindi facendo la build, e facendo in modo che tutti gli altri sviluppatori risincronizzassero i propri repository.

Tutto ciò può essere affrontato con processi umani, naturalmente; DVCS ha appena rotto qualcosa che è stato risolto dal controllo centralizzato della versione per fornire alcuni nuovi vantaggi.

Mi piace Git perché in realtà aiuta lo sviluppatore della comunicazione allo sviluppatore in un team medio-grande. Come sistema di controllo della versione distribuito, attraverso il suo sistema push / pull, aiuta gli sviluppatori a creare un ecosistema di codice sorgente che aiuta a gestire un grande pool di sviluppatori che lavorano su un singolo progetto.

Ad esempio, supponi di aver fiducia in 5 sviluppatori e di estrarre solo codici dal loro repository. Ognuno di questi sviluppatori ha la propria rete di fiducia da cui estraggono i codici. Pertanto lo sviluppo si basa su quel tessuto di fiducia degli sviluppatori in cui la responsabilità del codice è condivisa tra la comunità di sviluppo.

Naturalmente ci sono altri benefici che sono citati in altre risposte qui.

Alcune risposte hanno alluso a queste, ma voglio rendere espliciti 2 punti:

1) La possibilità di eseguire commit selettivi (ad esempio, git add --patch ). Se la tua directory di lavoro contiene più modifiche che non fanno parte della stessa modifica logica, Git rende molto facile eseguire un commit che include solo una parte delle modifiche. Con Subversion, è difficile.

2) La capacità di impegnarsi senza rendere pubblico il cambiamento. In Subversion, qualsiasi commit è immediatamente pubblico e quindi irrevocabile. Ciò limita notevolmente la capacità dello sviluppatore di “impegnarsi presto, impegnarsi spesso”.

Git è più di un semplice VCS; è anche uno strumento per lo sviluppo di patch. Subversion è semplicemente un VCS.

Penso che Subversion stia bene .. fino a quando non inizierai a fondere .. oa fare qualcosa di complicato .. o fare qualsiasi cosa pensi che Subversion sia complicato (come fare query per scoprire quali rami sono incasinati con un particolare file, da cui proviene davvero un cambiamento, rilevare copia e incolla , eccetera)…

Non sono d’accordo con la risposta vincente, dicendo che il vantaggio principale di GIT è il lavoro offline – è certamente utile, ma è più come un extra per il mio caso d’uso. SVK può funzionare anche offline, ma non c’è dubbio per me su quale investire il mio tempo di apprendimento).

È solo che è incredibilmente potente e veloce e, dopo essersi abituato ai concetti, molto utile (sì, in questo senso: facile da usare).

Per maggiori dettagli su una storia di fusione, vedi questo: Usare git-svn (o simili) * solo * per dare una mano in una svn unione?

Grazie al fatto che non ha bisogno di comunicare con un server centrale costantemente, praticamente ogni comando viene eseguito in meno di un secondo (ovviamente git push / pull / fetch è più lento semplicemente perché devono inizializzare le connessioni SSH). La ramificazione è molto più semplice (un semplice comando da ramificare, un semplice comando da unire)

Adoro assolutamente poter gestire i rami locali del mio codice sorgente in Git senza intaccare l’acqua del repository centrale. In molti casi eseguo il checkout del codice dal server Subversion ed eseguo un repository Git locale solo per poterlo fare. È anche bello che l’inizializzazione di un repository Git non inquini il filesystem con un sacco di fastidiose cartelle .svn ovunque.

E per quanto riguarda il supporto degli strumenti di Windows, TortoiseGit gestisce molto bene le basi, ma preferisco comunque la riga di comando a meno che non voglia visualizzare il registro. Mi piace molto il modo in cui Tortoise {Git | SVN} aiuta durante la lettura dei registri di commit.

Questa è la domanda sbagliata da chiedere. È fin troppo facile concentrarsi sulle verruche di Git e formulare una discussione sul perché la sovversione sia apparentemente migliore, almeno per alcuni casi d’uso. Il fatto che git sia stato originariamente concepito come un set di costruzione di controllo di versione di basso livello e abbia un’interfaccia barocca orientata allo sviluppatore di linux rende più facile per le guerre sante ottenere trazione e percezione della legittimità. I sostenitori di Git sbattono il tamburo con milioni di vantaggi del stream di lavoro, che i ragazzi svn proclamano inutili. Ben presto l’intero dibattito è inquadrato come centralizzato rispetto a distribuito, che serve gli interessi della comunità di strumenti dello svn aziendale. Queste aziende, che tipicamente pubblicano gli articoli più convincenti sulla superiorità della sovversione nell’impresa, dipendono dall’insicurezza percepita di git e dalla prontezza dell’impresa di svn per il successo a lungo termine dei loro prodotti.

Ma ecco il problema: Subversion è un vicolo cieco architettonico .

Considerando che puoi prendere git e build una sostituzione di sovversione centralizzata abbastanza facilmente, nonostante sia in giro per più di due volte il numero di svn non è mai stato in grado di far funzionare anche il basic merge-tracking ovunque e in git. Un motivo fondamentale per questo è la decisione di progettazione di rendere i rami uguali alle directory. Non so perché sono andati in questo modo in origine, certamente rende i checkout parziali molto semplici. Sfortunatamente, inoltre, rende imansible tracciare correttamente la cronologia. Ora ovviamente si suppone che si debbano utilizzare convenzioni di layout del repository di sovversione per separare i rami dalle directory normali e svn usa delle euristiche per far funzionare le cose nei casi d’uso quotidiano. Ma tutto ciò si limita a prendere una decisione di progettazione a basso livello molto scarsa e limitante. Essere in grado di fare un diffetto-saggio diff (piuttosto che directory-saggio diff) è la funzionalità di base e critica per un sistema di controllo di versione, e semplifica notevolmente le parti interne, rendendo ansible build funzioni più intelligenti e utili su di esso. È ansible vedere la quantità di sforzo che è stata messa in atto per estendere la sovversione, e tuttavia quanto è lontana dal stream attuale di VCS moderni in termini di operazioni fondamentali come la risoluzione di unione.

Ora ecco il mio consiglio sincero e agnostico per chiunque crede ancora che Subversion sia abbastanza buono per il prossimo futuro:

La sovversione non raggiungerà mai le nuove razze di VCS che hanno imparato dagli errori di RCS e CVS; è un’impossibilità tecnica a meno che non riorganizzino il modello di repository da zero, ma in questo caso non sarebbe veramente svn vero? Indipendentemente da quanto pensi di non avere le capacità di un VCS moderno, la tua ignoranza non ti proteggerà dalle insidie ​​della Subversion, molte delle quali sono situazioni impossibili o facilmente risolvibili in altri sistemi.

È estremamente raro che l’inferiorità tecnica di una soluzione sia così netta come lo è con svn, certamente non direi mai una simile opinione su win-vs-linux o emacs-vs-vi, ma in questo caso è così chiaro, e il controllo del codice sorgente è uno strumento fondamentale nell’arsenale dello sviluppatore, che ritengo debba essere dichiarato inequivocabilmente. A prescindere dall’obbligo di usare svn per ragioni organizzative, implorano tutti gli utenti svn di non lasciare che la loro mente logica costruisca una falsa convinzione che VCS più moderni siano utili solo per grandi progetti open-source. Indipendentemente dalla natura del tuo lavoro di sviluppo, se sei un programmatore, sarai un programmatore più efficace se impari a utilizzare VCS di migliore progettazione, che si tratti di Git, Mercurial, Darcs o molti altri.

Subversion è molto facile da usare. Non ho mai trovato negli ultimi anni un problema o qualcosa non funziona come previsto. Inoltre ci sono molti strumenti GUI eccellenti e il supporto per l’integrazione SVN è grande.

Con Git ottieni un VCS più flessibile. È ansible utilizzarlo allo stesso modo di SVN con un repository remoto in cui si accettano tutte le modifiche. But you can also use it mostly offline and only push the changes from time to time to the remote repository. But Git is more complex and has a steeper learning curve. I found myself in the first time committing to wrong branches, creating branches indirectly or get error messages with not much informations about the mistake and where I must search with Google to get better informations. Some easy things like substitution of markers ($Id$) doesn’t work but GIT has a very flexible filtering and hook mechanism to merge own scripts and so you get all things you need and more but it needs more time and reading of the documentation 😉

If you work mostly offline with your local repository you have no backup if something is lost on your local machine. With SVN you are mostly working with a remote repository which is also the same time your backup on another server… Git can work in the same way but this was not the main goal of Linus to have something like SVN2. It was designed for the Linux kernel developers and the needs of a distributed version control system.

Is Git better then SVN? Developers which needs only some version history and a backup mechanism have a good and easy life with SVN. Developers working often with branches, testing more versions at the same time or working mostly offline can benefit from the features of Git. There are some very useful features like stashing not found with SVN which can make the life easier. But on the other side not all people will need all features. So I cannot see the dead of SVN.

Git needs some better documentation and the error reporting must be more helpful. Also the existing useful GUIs are only rarely. This time I have only found 1 GUI for Linux with support of most Git features (git-cola). Eclipse integration is working but its not official released and there is no official update site (only some external update site with periodical builds from the trunk http://www.jgit.org/updates ) So the most preferred way to use Git this days is the command line.

Eric Sink from SourceGear wrote series of articles on differences between distributed and nondistributed version controls systems. He compares pros and cons of most popular version control systems. Very interesting reading.
Articles can be found on his blog, http://www.ericsink.com :

  • Read the Diffs

  • Git is the C of Version Control Tools

  • On Git’s lack of respect for immutability and the Best Practices for a DVCS

  • DVCS and DAGs, Part 1

  • DVCS and DAGs, Part 2

  • DVCS and Bug Tracking

  • Merge History, DAGs and Darcs

  • Why is Git so Fast?

  • Mercurial, Subversion, and Wesley Snipes

For people looking for a good Git GUI, Syntevo SmartGit might be a good solution. Its proprietary, but free for non-commercial use, runs on Windows/Mac/Linux and even supports SVN using some kind of git-svn bridge, I think.

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

I think it’s fairly safe to say that amongst developers, the SVN Vs. Git argument has been raging for some time now, with everyone having their own view on which is better. This was even brought up in the of the questions during our Webinar on Subversion in 2010 and Beyond.

Hyrum Wright, our Director of Open Source and the President for the Subversion Corporation talks about the differences between Subversion and Git, along with other Distributed Version Control Systems (DVCS).

He also talks about the upcoming changes in Subversion, such as Working Copy Next Generation (WC-NG), which he believes will cause a number of Git users to convert back to Subversion.

Have a watch of his video and let us know what you think by either commenting on this blog, or by posting in our forums. Registration is simple and will only take a moment!

Git in Windows is quite well supported now.

Check out GitExtensions = http://code.google.com/p/gitextensions/

and the manual for a better Windows Git experience.

I have been dwelling in Git land lately, and I like it for personal projects, but I wouldn’t be able to switch work projects to it yet from Subversion given the change in thinking of required from staff, without no pressing benefits. Moreover the biggest project we run in-house is extremely dependent on svn:externals which, from what I’ve seen so far, does not work so nicely and seamlessly in Git.

First, concurrent version control seems like an easy problem to solve. It’s not at all. Comunque…

SVN is quite non-intuitive. Git is even worse. [sarcastic-speculation] This might be because developers, that like hard problems like concurrent version control, don’t have much interest in making a good UI. [/sarcastic-speculation]

SVN supporters think they don’t need a distributed version-control system. I thought that too. But now that we use Git exclusively, I’m a believer. Now version control works for me AND the team/project instead of just working for the project. When I need a branch, I branch. Sometimes it’s a branch that has a corresponding branch on the server, and sometimes it does not. Not to mention all the other advantages that I’ll have to go study up on (thanks in part to the arcane and absurd lack of UI that is a modern version control system).

Why I think Subversion is better than Git (at least for the projects I work on), mainly due to its usability, and simpler workflow:

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