Perché Git meglio di Subversion?

08-06-2019
|

Domanda

Sto usando Subversion per un paio di anni e dopo l'utilizzo SourceSafe, Amo Subversion.Combinato con TortoiseSVN, Non riesco ad immaginare come potrebbe essere migliore.

Ma c'è un numero crescente di sviluppatori, sostenendo che utilizzi non ha problemi e che ci deve essere in movimento per la nuova generazione di sistemi di controllo di versione distribuito, come Git.

Come Git migliorare Subversion?

Soluzione

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

La differenza chiave è che è decentrata.Immaginate di essere uno sviluppatore su strada, si sviluppa su un computer portatile e si desidera avere il controllo del codice sorgente, in modo che si può andare indietro di 3 ore.

Con Subversion, si ha un Problema:Il Repository SVN può essere in una posizione in cui non può raggiungere (in vostra compagnia, e non si dispone di internet al momento), non si può commettere.Se si desidera creare una copia del codice, è letteralmente copia/incolla.

Con Git, non hanno questo problema.La copia locale è un repository, e si può impegnarsi a e ottenere tutti i benefici del controllo del codice sorgente.Quando si riconquistare la connettività per il repository principale, che si possa commettere contro di essa.

Questo sembra buono a prima, ma basta tenere a mente la complessità di questo approccio.

Git sembra essere il "nuovo, lucido, fresco di" cosa.Non è affatto male (c'è una ragione Linus ha scritto per lo sviluppo del Kernel di Linux, dopo tutto), ma ho la sensazione che molte persone saltare sul "Distribuito Origine Controllo" treno solo perché è nuovo ed è stato scritto da Linus Torvalds, senza sapere perché/se è migliore.

Subversion ha Problemi, ma non così Git, Mercurial, CVS, TFS o qualsiasi altra cosa.

Edit: Quindi questa risposta è adesso ha un anno e genera ancora molti upvotes, così ho pensato di aggiungere alcune ulteriori spiegazioni.Nell'ultimo anno dopo aver scritto questo, Git ha guadagnato un sacco di slancio e di supporto, in particolare dal momento che siti come GitHub è decollata.Io sto usando sia Git, Subversion oggi e mi piacerebbe condividere qualche intuizione personale.

Prima di tutto, Git può essere davvero fonte di confusione in un primo momento quando lavoro decentrato.Che cosa è un telecomando?e Come configurare correttamente l'iniziale repository?sono due le domande che si presentano all'inizio, soprattutto rispetto a SVN semplice "svnadmin create", Git "git init" può assumere i parametri --nudo e --condivisa che sembra essere il "giusto" modo di impostare un repository centralizzato.Ci sono ragioni per questo, ma aggiunge complessità.La documentazione del comando "checkout" è molto confusa persone che cambiano oltre - il "proprio" modo sembra essere "git clone", mentre "git checkout" sembra passare rami.

Git brilla DAVVERO quando si sono decentrate.Ho un server a casa e un computer Portatile sulla strada, e SVN semplicemente non funziona bene qui.Con SVN, io non sono di origine locale di controllo se non sono collegato al repository (Sì, so che su SVK o sui modi per copiare il repo).Con Git, che è la modalità di default comunque.Si tratta di un extra di comando, anche se (git commit commit locale, mentre git push origin master spinge il ramo master remoto denominato "origine").

Come detto sopra:Git aggiunge complessità.Due modalità di creazione di repository, checkout vsclone, impegnarsi contropush...Devi sapere che i comandi di lavorare a livello locale e che lavorano con il "server" (sto dando per scontato che la maggior parte delle persone ancora come un "master" centrale-repository").

Inoltre, la lavorazione è ancora insufficiente, almeno su Windows.Sì, c'è un AddIn per Visual Studio, ma ho ancora utilizzare git bash con msysgit.

SVN ha il vantaggio che è MOLTO più semplice da imparare:C'è il repository di tutte le modifiche apportate al verso di esso, se si sa come creare, di impegnarsi e di pagamento e sei pronto per andare e può pickup roba come ramificazione, aggiornamento etc.in seguito.

Git ha il vantaggio che è MOLTO più adatta se alcuni sviluppatori non sono sempre collegato al master repository.Inoltre, è molto più veloce di SVN.E da quello che ho sentito, la ramificazione e la fusione di supporto è molto meglio (che deve essere previsto, in quanto questi sono i motivi fondamentali è stato scritto).

Questo spiega anche perché si guadagna così tanto buzz su Internet, come Git è perfettamente adatto per i progetti Open Source:Solo con la Forchetta, il commit delle modifiche proprio la Forcella, e poi chiedi il progetto originale manutentore a tirare le modifiche.Con Git, basta che funzioni.Davvero, prova su Github, è magia.

Quello che vedo sono Git-SVN Ponti:Il repository centrale è un Subversion repository, ma gli sviluppatori localmente lavorare con Git e il ponte poi spinge le modifiche SVN.

Ma anche con questo lungo oltre, ho ancora in stand by il mio messaggio principale:Git non è meglio o peggio, è solo diverso.Se avete la necessità di "Offline Origine Controllo" e la volontà di spendere del tempo per imparare, è fantastico.Ma se si dispone di un piano strettamente Fonte centralizzata di Controllo e/o stanno lottando per introdurre il Controllo del codice Sorgente, in primo luogo, perché il co-lavoratori non sono interessati, la semplicità e l'eccellente utensili (almeno su Windows) di SVN brillare.

Altri suggerimenti

Con Git, si può fare praticamente di tutto offline, perché ognuno ha il proprio repository.

Facendo rami e la fusione tra i rami, è davvero facile.

Anche se non si dispone di diritti di deposito per un progetto, si può ancora avere il proprio repository online, e la pubblicazione di "push" delle richieste per la vostra patch.Tutti coloro che ama le patch possono tirare nel loro progetto, tra cui l'ufficiale manutentori.

È banale per il fork di un progetto, modificarlo, e ancora mantenere la fusione in bugfix dalla TESTA ramo.

Git funziona per gli sviluppatori del kernel Linux.Ciò significa che è davvero veloce (deve essere), e le scale a migliaia di contribuenti.Git utilizza anche meno spazio (fino a 30 volte meno spazio per il repository di Mozilla).

Git è molto flessibile, molto TIMTOWTDI (C'è più di un modo per farlo).È possibile utilizzare qualsiasi flusso di lavoro che si desidera, e Git supporto.

Infine, c'è GitHub, un grande sito per l'hosting del tuo repository Git.

Svantaggi di Git:

è molto più difficile da imparare, perché la Git ha più concetti e comandi.
le revisioni non sono i numeri di versione come in subversion
molti comandi Git sono criptico, e i messaggi di errore sono molto user-unfriendly
manca una buona GUI (come i grandi TortoiseSVN)

Altre risposte hanno fatto un buon lavoro di spiegare le caratteristiche fondamentali di Git (che sono grandi).Ma ci sono anche tanti poco modi che Git si comporta meglio e aiuta a mantenere la mia vita più sano.Qui ci sono alcune piccole cose:

Git è un 'pulito' di comando.SVN ha disperatamente bisogno di questo comando, considerando come spesso si fa il dump dei file aggiuntivi sul vostro disco.
Git è il "bisecare" comando.È bello.
SVN crea .svn directory in ogni singola cartella (Git crea solo uno .git directory).Scrivere tutti gli script, e ogni grep contrario, sarà necessario essere scritto di ignorare questi .svn directory.Inoltre hai bisogno di un intero comando ("svn esportazione") solo per ottenere un sano copia dei tuoi file.
In SVN, ogni file e cartella può venire da un altro revisione o di un ramo.In un primo momento, sembra bello avere questa libertà.Ma che cosa questo significa è che c'è un milione di modi diversi per il tuo locale checkout per essere completamente avvitato.(per esempio, se "svn switch" non riesce a metà, o se si immette un comando errato).E la parte peggiore è:se siete mai in una situazione in cui alcuni dei tuoi file sono venuta da un luogo, e alcuni di loro da un altro, il "svn status" vi dirà che tutto ciò è normale.Avrai bisogno di fare "svn" informazioni su ogni file/directory per scoprire come le cose strane sono.Se "git status di" ti dice che le cose sono normali, quindi ci si può fidare che le cose sono normali.
Bisogna dire SVN ogni volta che si sposta o elimina qualcosa.Git sarà solo capire.
Ignorare la semantica è più facile in Git.Se si ignora un motivo (ad esempio *.pyc), sarà ignorato tutti le sottodirectory.(Ma se si vuole veramente di ignorare qualcosa per una sola directory, è possibile).Con SVN, sembra che non vi è alcun modo semplice per ignorare un modello in tutte le sottodirectory.
Un altro elemento che coinvolgono ignorare i file.Git permette di avere un "privato" ignora impostazioni (utilizzando il file .git/info/escludere), che non interessano nessuno.

"Perché Git è Meglio di X"delinea i vari pro e contro di Git vs altri Scm.

Brevemente:

Git tracce contenuto piuttosto che file
I rami sono leggeri e la fusione è facile, e voglio dire davvero facile.
Viene distribuito, praticamente ogni repository è un ramo.È molto più facile sviluppare contemporaneamente e in modo collaborativo che con Subversion, a mio parere.Rende anche offline lo sviluppo possibile.
Si non imporre qualsiasi flusso di lavoro, come si vede sulla il sito linkato sopra, ci sono molti flussi di lavoro possibile con Git.Una Sovversione in stile flusso di lavoro è facilmente imitato.
Repository Git sono molto più piccolo di dimensione del file di repository di Subversion.C'è una sola ".git" directory, contro decine di ".svn" repository (nota Subversion 1.7 e superiori ora utilizza una singola directory come Git.)
Il stadiazione la zona è fantastico, ti permette di vedere le modifiche che si impegnano, impegnarsi parziali modifiche e fare diverse altre cose.
Riporre è inestimabile quando si fa "caotico" di sviluppo, o semplicemente desidera la correzione di un bug mentre si sta ancora lavorando su qualcos'altro (su un altro ramo).
È possibile riscrivere la storia, che è grande per la preparazione di set di patch e risolvere i vostri erroriprima si pubblica il commit)
... e un sacco di più.

Ci sono anche alcuni svantaggi:

Non ci sono molte buone interfacce grafiche per esso ancora.E ' nuovo e Subversion è stato intorno per un tempo molto più lungo, quindi questo è naturale, come ci sono un paio di interfacce in via di sviluppo.Alcuni buoni includono TortoiseGit e GitHub per Mac.
~~Parziale estrazioni/cloni di repository non sono possibili al momento (ho letto che è in fase di sviluppo).Tuttavia, c'è submodule supporto.~~ Git 1.7+ supporta sparse estrazioni.
Potrebbe essere difficile da imparare, anche se non ho trovato che questo sia il caso (circa un anno fa).Git ha recentemente migliorato la sua interfaccia è molto user friendly.

In più semplicistico di utilizzo, Subversion e Git sono praticamente la stessa.Non c'è molta differenza tra:

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

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

Dove Git brilla davvero è la ramificazione e lavorare con altre persone.

Google Tech Talk:Linus Torvalds su git

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

Il Git Wiki la pagina di confronto

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

Beh, è distribuito.Benchmark indicano che è notevolmente più veloce (data la sua natura distribuita, operazioni come i diff e i registri sono tutte così, naturalmente, è molto più veloce in questo caso), e le cartelle di lavoro sono più piccoli (che ancora soffia la mia mente).

Quando si lavora su subversion, o qualsiasi altro client/server revisione del sistema di controllo, è essenzialmente creare copie di lavoro sulla vostra macchina da il check-out revisioni.Questo rappresenta un'istantanea di ciò che il repository sembra.Si aggiorna la tua copia di lavoro tramite aggiornamenti e aggiornare il repository via impegna.

Con un controllo di versione distribuito, non hai una fotografia, ma piuttosto l'intero codebase.Voglio fare un diff con 3 mesi di vecchia versione?Nessun problema, il 3 mese precedente versione è ancora sul tuo computer.Questo non significa solo cose sono il modo più veloce, ma se si è disconnessi dal server centrale, si può ancora fare molte delle operazioni che hai usato per.In altre parole, non basta avere un'istantanea di una revisione data, ma l'intero codebase.

Si potrebbe pensare che Git vorresti prendere un po ' di spazio sul vostro hard disk, ma da un paio di benchmark che ho visto, è, in realtà, prende di meno.Non chiedetemi come.Voglio dire, è stato costruito da Linus, sa una cosa o due riguardo il filesystem credo.

I punti principali che mi piace DVC sono questi :

Si possono commettere cose rotte.Non importa, perché gli altri popoli non li vedi fino a che si pubblica.Pubblicare volta è diverso, di impegnare il tempo.
A causa di questo si può commettere più spesso.
È possibile unire la completa funzionalità.Questa funzionalitã, avrà un suo ramo.Tutti i commit di questo ramo sarà legato a questa funzionalità.Si può fare con un CVC tuttavia con i DVCS sua default.
È possibile cercare la vostra storia (trovare quando una funzione è cambiato )
È possibile annullare un pull se qualcuno avvitare il repository principale, non è necessario correggere gli errori.È sufficiente deselezionare l'unione.
Quando avete bisogno di un controllo del codice sorgente in qualsiasi directory fare :git init .e che si possa commettere, annullare le modifiche, ecc...
È veloce (anche su Windows )

La ragione principale di un relativamente grande progetto è il miglioramento della comunicazione creati dal punto 3.Gli altri sono bonus.

La cosa divertente è:I progetti d'accoglienza in Subversion Repo, ma l'accesso tramite il comando Git Clone.

Si prega di leggere Sviluppare con Git su un Progetto su Google Code

Anche se Google Codice nativo parla Subversion, si può facilmente utilizzare Git durante lo sviluppo.La ricerca di "git svn" suggerisce questa pratica è diffusa, e noi incoraggiamo sperimentare con esso.

Utilizzando Git su un Repository Svn dà benefici:

Posso lavorare distribuito su diversi macchine, inviare e tirando e a loro
Ho un centrale backup/public repository svn per gli altri a controllare
E sono liberi di usare Git per loro

Qui tutte le risposte sono, come previsto, un programmatore centric, tuttavia, cosa succede se la vostra azienda utilizza un controllo di revisione al di fuori del codice sorgente?Ci sono un sacco di documenti che non sono il codice sorgente che beneficiano di controllo di versione, e deve vivere vicino al codice e non in un altro CMS.La maggior parte dei programmatori non lavorano in isolamento - lavoriamo per aziende come parte di una squadra.

Con questo in mente, confrontare la facilità di utilizzo, in entrambi i client di utensileria e formazione, tra Sovversione e git.Non vedo uno scenario in cui qualsiasi distribuito revisione del sistema di controllo sta per essere più facile da usare o spiegare a un non-programmatore.Mi piacerebbe essere smentito, perché poi mi piacerebbe essere in grado di valutare git e in realtà hanno una speranza di essere accettato da persone che hanno bisogno di controllo di versione che non sono programmatori.

Anche allora, se richiesto dalla direzione, perché si dovrebbe passare da un sistema centralizzato di controllo di versione distribuito del sistema, non sarebbe difficile dare una risposta onesta, perché non ne abbiamo bisogno.

Disclaimer:Mi sono interessato in Subversion presto (intorno a v0.29) così, ovviamente io sono di parte, ma la società per cui ho lavorato da allora sono beneficiare mio entusiasmo perché ho incoraggiato e sostenuto il suo utilizzo.Ho il sospetto che questo è ciò che accade con la maggior parte delle aziende di software.Con così tanti programmatori di saltare sul git carrozzone, mi chiedo come molte aziende stanno andando a perdere i benefici di usando la versione di controllo al di fuori del codice sorgente?Anche se si dispone di sistemi separati per diverse squadre, vi state perdendo su alcuni vantaggi, come ad esempio (unificata) gestione dei problemi di integrazione, aumentando al contempo la manutenzione, hardware e requisiti di formazione.

Subversion è ancora molto più utilizzato sistema di controllo di versione, il che significa che ha un migliore strumento di supporto.Troverete maturo SVN plug-in per quasi ogni IDE, e ci sono buone explorer estensioni disponibili (come TurtoiseSVN).Oltre a questo, io sono d'accordo con Michael:Git non è migliore o peggiore di Subversion, è diverso.

Una delle cose su SubVersion, che mi infastidisce è che si mette la sua cartella nella cartella di un progetto, mentre la git mette solo uno nella root directory.Non che un grande affare, ma piccole cose che si sommano.

Naturalmente, SubVersion ha Tartaruga, [di solito] molto bello.

David Richards WANdisco Blog su Subversion / GIT

L'emergere di GIT ha portato con sé una razza di DVCS fondamentalisti – il ‘Gitterons’ – che pensare a qualcosa di diverso da GIT è una schifezza.Il Gitterons sembrano pensare ingegneria del software avviene sulla loro isola e spesso si dimentica che la maggior parte delle organizzazioni non utilizzano software senior ingegneri esclusivamente.Che è ok, ma non è come il resto del mercato che pensa, e io sono felice per dimostrarlo:GIT, all'ultimo sguardo aveva meno di tre per cento del mercato, mentre Subversion è nella regione di cinque milioni di utenti e circa la metà del mercato complessivo.

Il problema che abbiamo visto è stato che il Gitterons erano cottura (basso) scatti di Sovversione.Tweet come “Subversion è così [slow/merda/restrittiva/non è un buon odore/mi guarda in un modo divertente] e ora ho GIT e [tutto funziona in vita mia/mia moglie è rimasta incinta/ho avuto una ragazza, dopo 30 anni di tentativi/ho vinto sei volte in esecuzione sul tavolo di blackjack].Si ottiene l'immagine.

Git fa anche la ramificazione e la fusione davvero facile.Subversion 1.5 appena aggiunto unione di monitoraggio, ma Git è ancora meglio.Con Git ramificazione è molto veloce e a buon mercato.Esso rende la creazione di un ramo per ogni nuova caratteristica più fattibile.Oh, e repository Git sono molto efficienti con lo spazio di archiviazione rispetto a Subversion.

È tutto circa la facilità di utilizzo/passaggi necessari per fare qualcosa.

Se sto sviluppando un progetto unico sul mio PC, laptop, git è meglio, perché è molto più facile da impostare e utilizzare.Non hai bisogno di un server, e non hai bisogno di digitare repository URL a quando non si fonde.

Se erano solo 2 persone, direi che git è anche più facile, perché si può solo spingere e tirare l'uno dall'altro.

Una volta a ottenere oltre che, però, mi piacerebbe andare per subversion, perché a questo punto è necessario impostare un 'dedicato' server o posizione.

Si può fare questo solo con git come SVN, ma i benefici di git ottenere compensato dalla necessità di fare ulteriori passi per la sincronizzazione con un server centrale.In SVN appena commesso.In git è necessario git commit, quindi git push.L'ulteriore passo diventa fastidioso, semplicemente perché si finisce per fare così tanto.

SVN ha anche il vantaggio di una migliore interfaccia grafica, tuttavia il git ecosistema sembra essere la cattura rapidamente, quindi io non mi preoccuperei di questo, a lungo termine.

Facile Git ha una bella pagina di confronto effettivo utilizzo di Git e SVN che vi darà un'idea di ciò che le cose Git grado di fare (o di non fare più facilmente) rispetto a SVN.(Tecnicamente, questo si basa su semplici Git, che è un leggero wrapper su di Git.)

Git e DVCS, in generale, è grande per gli sviluppatori di fare un sacco di codifica in modo indipendente l'uno dell'altro perché ognuno ha una propria filiale.Se avete bisogno di un cambiamento da parte di qualcun altro, però, ha di impegnarsi per il suo repository locale e, quindi lei deve spingere il changeset a voi o si deve tirare da lei.

Mio ragionamento mi fa pensare a DVCS rende le cose più difficili per il controllo qualità e la gestione del rilascio, se si fanno le cose come centralizzati versioni.Qualcuno deve essere responsabile per la loro azione di push/pull da tutti gli altri repository, per la risoluzione di eventuali conflitti che si sarebbe risolta in una fase iniziale di impegnare tempo prima, poi fare il build, e poi tutti gli altri sviluppatori di ri-sincronizzare le loro operazioni.

Tutto questo può essere affrontato con i processi umani, naturalmente;DVC si è rotto qualcosa che è stato fissato dal centralizzata controllo di versione al fine di fornire alcune nuove convenienze.

Mi piace Git, perché in realtà aiuta la comunicazione, sviluppatore a sviluppatore di una medio-grande squadra.Come un controllo di versione distribuito, attraverso il suo push/pull system, consente agli sviluppatori di creare un codice sorgente eco-sistema che consente di gestire una grande piscina di sviluppatori che lavorano su un singolo progetto.

Per esempio dire che la fiducia di 5 sviluppatori e solo tirare i codici da loro repository.Ognuno di questi sviluppatori è proprio la fiducia di rete da dove tirano i codici.Lo sviluppo, quindi, è basata sulla fiducia tessuto di sviluppatori di codice dove la responsabilità è condivisa tra la comunità di sviluppo.

Naturalmente, ci sono altri benefici che sono menzionati in altre risposte qui.

Alcune risposte hanno accennato a questi, ma io voglio fare 2 punti esplicito:

1) La capacità di fare selettiva impegna, per esempio, git add --patch).Se la cartella di lavoro contiene più modifiche che non fanno parte della stessa logica di cambiamento, Git rende molto facile fare un commit che comprende solo una parte delle modifiche.Con Subversion, è difficile.

2) La capacità di impegnarsi, senza fare la modifica pubblici.In Subversion, ogni commit è immediatamente pubblico, e quindi irrevocabile.Questo limita fortemente le possibilità di sviluppo a "commettere presto, commettono spesso".

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

Penso che Subversion è bene..fino a quando si avvia la fusione..o fare qualcosa di complicato..o fare qualcosa di Subversion pensa che è complicato (come fare le query per trovare i cui rami incasinato con un particolare file, dove un cambiamento in realtà viene, la rilevazione di copia&incolla, ecc)...

Io non sono d'accordo con una risposta vincente, dicendo che il il principale beneficio di GIT è collegato lavoro è certamente utile, ma è più un extra per il mio caso d'uso.SVK grado di lavorare anche offline, ancora non c'è dubbio per me che quella di investire il mio tempo di apprendimento in).

È solo che è incredibilmente potente e veloce, e dopo aver utilizzato i concetti sono molto utili (sì, in questo senso:user friendly).

Per ulteriori informazioni su una fusione di storia, vedere questo :Utilizzando git-svn (o simili) *solo* per aiutare con un svn merge?

Grazie, infatti, 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 sono più lenti, semplicemente perché non hanno a initalise connessioni SSH).La ramificazione è molto, molto più facile (un semplice comando per ramo, un semplice comando per unire)

Adoro essere in grado di gestire le filiali del mio codice sorgente in Git, senza confondere le acque del repository centrale.In molti casi io checkout il codice dal server Subversion ed eseguire un repository Git locale, solo per essere in grado di fare questo.E ' anche ideale che l'inizializzazione di un repository Git non inquinare il filesystem con un sacco di fastidiosi .svn cartelle ovunque.

E per quanto riguarda Windows strumento di supporto, TortoiseGit gestisce le basi molto bene, ma io preferisco ancora la linea di comando, a meno che non mi desidera visualizzare il registro.Mi piace molto il modo di Tartaruga, {Git|SVN}, aiuta durante la lettura di commettere registri.

Questa è la domanda sbagliata per chiedere.E ' tutto troppo facile concentrarsi su git di verruche e di formulare un argomento sul perché subversion è apparentemente migliore, almeno per alcuni casi di utilizzo.Il fatto che git è stato originariamente progettato come un basso livello di controllo di versione di costruzione e barocco linux-developer-oriented rende più facile per le guerre sante per guadagnare trazione e percepito legittimità.Git sostenitori bang il tamburo con milioni di flusso di lavoro di vantaggi, quali svn ragazzi proclamare inutili.Molto presto l'intero dibattito è inquadrata come centralizzato vs distribuito, che serve gli interessi dell'impresa svn strumento di comunità.Queste aziende, che di solito messo fuori il più convincente articoli di subversion superiorità nell'impresa, sono dipendente sulla percezione dell'insicurezza di git e la disponibilità enterprise di svn per il successo a lungo termine dei loro prodotti.

Ma ecco il problema: Subversion è un architettonici del dead-end.

Mentre si può prendere git e costruire una centralizzato subversion sostituzione abbastanza facilmente, pur essendo in giro per più di due volte più a lungo svn non è mai stato in grado di ottenere ancora di base in fusione di monitoraggio di lavoro da nessuna parte vicino così come avviene in git.Una ragione di ciò, è la decisione di progettazione per rendere le filiali della stessa directory.Non so perché sono andato in questo modo, originariamente, si rende certamente parziale estrazioni molto semplice.Purtroppo anche rende impossibile tracciare correttamente.Ora, ovviamente, si suppone di utilizzare il repository subversion convenzioni di layout di rami separati da regolare directory e svn utilizza alcune euristiche per far funzionare le cose per l'uso quotidiano casi.Ma tutto questo è solo rattoppare molto povera, e limitando la progettazione di basso livello decisione.Essere in grado di fare un repository-saggio diff (anziché directory saggio diff) è di base e le funzionalità critiche per un sistema di controllo di versione, e semplifica notevolmente l'interno, rendendo possibile lavorare in modo più intelligente e caratteristiche utili su di esso.Si può vedere la quantità di sforzo che è stato messo in estensione subversion, e ancora, quanto lontano dietro di esso è il raccolto di moderni Vcs in termini di operazioni fondamentali come unione di risoluzione.

Ora qui è il mio cuore in feltro e agnostico consiglio, per chi ancora crede Subversion è abbastanza buono per il prossimo futuro:

Subversion non potrà mai raggiungere il più recente razze di Vcs che hanno imparato dagli errori di RCS e CVS;si tratta di una impossibilità tecnica a meno che non riorganizzare il repository modello da terra, ma poi non sarebbe davvero essere svn avrebbe?A prescindere da quanto pensi di non avere le funzionalità di un moderno VCS, la tua ignoranza non protegge da Subversion insidie, molti dei quali sono delle situazioni che sono impossibili o facilmente risolto in altri sistemi.

E ' estremamente raro che il tecnico di inferiorità di una soluzione è così chiara come è con svn, di certo non mi sarei mai stato ad un parere su win vs linux o emacs-vs-vi, ma in questo caso non è così netta, e la fonte di controllo è uno strumento fondamentale per lo sviluppatore dell'arsenal, che io sento, devono essere dichiarati in modo inequivocabile.A prescindere dal requisito di usare svn, per ragioni organizzative, vi prego tutti gli utenti svn non lasciare la loro mente logica costruire una falsa credenza quella più moderna Vcs sono utili solo per i grandi progetti open source.A prescindere dalla natura del vostro lavoro di sviluppo, se sei un programmatore, vi sarà una più efficace programmatore se si impara a usare meglio progettato, Vcs, sia 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 ottimi strumenti con interfaccia grafica e il supporto per l'SVN integrazione è grande.

Con Git si ottiene una maggiore flessibilità del VCS.Si può utilizzare allo stesso modo come SVN con un repository remoto in cui si salva tutte le modifiche.Ma si può anche usare per lo più non in linea e inviare solo le modifiche al repository remoto.Ma Git è più complesso e ha una ripida curva di apprendimento.Mi ritrovai in un primo tempo impegnandosi a sbagliato rami, la creazione di filiali o indirettamente ottenere messaggi di errore con non molto informazioni circa l'errore e dove devo cercare con Google per ottenere migliori informazioni.Alcune cose semplici come la sostituzione dei marcatori ($Id$) non funziona, ma GIT è molto flessibile, il filtraggio e il meccanismo del gancio per unire i propri script e in modo da ottenere tutte le cose che avete bisogno e anche di più, ma si ha bisogno di più tempo e di lettura della documentazione ;)

Se si lavora per lo più non in linea con il tuo repository locale si dispone di alcun backup se qualcosa è perso sulla vostra macchina locale.Con SVN si sta lavorando principalmente con un repository remoto, che è anche lo stesso tempo di backup su un altro server...Git può lavorare nello stesso modo, ma questo non era il principale obiettivo di Linus per avere qualcosa di simile SVN2.E ' stato progettato per gli sviluppatori del kernel Linux e la necessità di un controllo di versione distribuito.

È Git meglio di SVN?Gli sviluppatori, che necessita solo di qualche versione della storia e di un meccanismo di backup di avere una buona e facile la vita con SVN.Gli sviluppatori che lavorano spesso con rami, il test più versioni, allo stesso tempo, o di lavorare per lo più in linea possono trarre beneficio dalle caratteristiche di Git.Ci sono alcune caratteristiche molto utili come trasmissione non trovato con SVN che possono rendere la vita più facile.Ma, d'altra parte non tutte le persone hanno bisogno di tutte le funzionalità.Così non riesco a vedere i morti di SVN.

Git bisogno di un po ' meglio la documentazione e la segnalazione deve essere più utile.Anche l'esistente utili interfacce grafiche sono solo raramente.Questa volta ho trovato solo 1 GUI per Linux con il supporto di più Git caratteristiche (git-cola).Eclipse integrazione funziona, ma non è ufficiale rilasciato e non c'è nessun aggiornamento ufficiale sito (solo esterni, aggiornamento sito con periodici costruisce dal tronco http://www.jgit.org/updates) Quindi, il modo più preferito utilizzare Git questo giorni è la riga di comando.

Eric Sink da SourceGear ha scritto una serie di articoli sulle differenze tra distribuito e non-distribuite versione sistemi di controllo.Paragona i pro e i contro dei più popolari sistemi di controllo di versione.Molto interessante la lettura.
Gli articoli possono essere trovati sul suo blog, www.ericsink.com:

Per chi cerca un buon Git GUI, Syntevo SmartGit potrebbe essere una buona soluzione.La sua proprietaria, ma gratuito per uso non commerciale, gira su Windows/Mac/Linux e supporta anche la SVN usando un qualche tipo di git-svn ponte, credo.

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

Penso che sia abbastanza sicuro di dire che tra gli sviluppatori, SVN Vs.Git argomento è stato infuria per un certo tempo, tutti i membri hanno la loro propria opinione su quale sia il migliore.Questo è stato anche portato in domande durante il nostro Webinar su Subversion nel 2010 e Oltre.

Hyrum Wright, Direttore di Open Source e il Presidente per la Sovversione Corporation parla delle differenze tra Sovversione e Git, insieme con altri Distribuiti Sistemi di Controllo di Versione (DVC).

Egli parla anche di cambiamenti imminenti in Subversion, come la Copia di Lavoro di Prossima Generazione (WC-NG), che egli ritiene di causare un certo numero di Git utenti di convertire Subversion.

Avere un orologio di suoi video e fateci sapere cosa ne pensate o commentare su questo blog, o da post nel nostro forum.La registrazione è semplice e richiede solo un momento!

Git in Windows è molto ben supportato.

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

e il manuale per una migliore Windows Git esperienza.

Sono stato dimora in Git terra ultimamente, e mi piace per progetti personali, ma non vorrei essere in grado di passare i progetti di lavoro ancora da Subversion dato il cambiamento nel modo di pensare di richieste da parte del personale, senza pressioni di alcun benefici.Inoltre il più grande progetto che abbiamo eseguito in casa è estremamente dipendente svn:esterni che, da quello che ho visto finora, non funziona così bene e senza soluzione di continuità in Git.

Prima, in concomitanza del controllo di versione sembra un problema facile da risolvere.Non è per tutti.Comunque...

SVN è abbastanza non intuitivo.Git è anche peggio.[sarcastico-speculazione] Questo potrebbe essere perché gli sviluppatori, che come hard problemi come concorrente di controllo di versione, non hanno molto interesse a fare una buona interfaccia utente.[/sarcastico-speculazione]

SVN sostenitori pensano che non hanno bisogno di una versione distribuito-sistema di controllo. Ho pensato che troppo. Ma ora che si usa Git esclusivamente, io sono un credente.Ora il controllo di versione funziona per me E per il team di progetto/invece di lavorare per il progetto.Quando ho bisogno di un ramo I ramo.A volte è un ramo che ha un ramo corrispondente sul server, e a volte non è così.Per non parlare di tutti gli altri vantaggi che dovrò andare a studiare fino a (in parte grazie ad arcana e assurda la mancanza di interfaccia utente, che è un moderno sistema di controllo di versione).

Perché penso che Subversion è meglio di Git (almeno per i progetti di lavoro), principalmente a causa della sua usabilità, e il flusso di lavoro più semplice:

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow