svn - how - tortoise git




Perché Git è meglio di Subversion? (20)

" Why Git is Better than X " delinea i vari pro e contro di Git rispetto ad altri SCM.

Brevemente:

  • Git tiene traccia dei contenuti anziché dei file
  • I rami sono leggeri e la fusione è facile e intendo davvero facile .
  • È distribuito, praticamente ogni repository è un ramo. A mio avviso, è molto più facile svilupparsi contemporaneamente e collaborativamente che con Subversion. Inoltre rende possibile lo sviluppo offline .
  • Non impone alcun flusso di lavoro , come visto sul sito Web sopra linkato , ci sono molti flussi di lavoro possibili con Git. Un flusso di lavoro in stile Subversion può essere facilmente imitato.
  • I repository Git hanno dimensioni del file molto inferiori rispetto ai repository Subversion. C'è solo una directory ".git", a differenza di dozzine di repository ".svn" (nota Subversion 1.7 e successive ora usa una singola directory come Git.)
  • L'area di gestione temporanea è fantastica, ti consente di vedere le modifiche che commetterai, eseguire modifiche parziali e fare varie altre cose.
  • Lo stashing ha un valore inestimabile quando si fa uno sviluppo "caotico" o si desidera semplicemente correggere un bug mentre si sta ancora lavorando su qualcos'altro (su un ramo diverso).
  • Puoi riscrivere la cronologia , il che è ottimo per preparare set di patch e correggere i tuoi errori ( prima di pubblicare i commit)
  • ... e molto altro ancora.

Ci sono alcuni svantaggi:

  • Non ci sono ancora molte buone GUI per questo. È nuovo e Subversion è in circolazione da molto più tempo, quindi è naturale poiché ci sono alcune interfacce in fase di sviluppo. Alcuni buoni includono code.google.com/p/tortoisegit e GitHub per Mac .
  • Al momento non è possibile effettuare checkout / cloni parziali dei repository (ho letto che è in fase di sviluppo). Tuttavia, esiste un supporto sottomodulo. Git 1.7+ supporta checkout sparsi .
  • Potrebbe essere più difficile da imparare, anche se non l'ho trovato (circa un anno fa). Git ha recentemente migliorato la sua interfaccia ed è abbastanza facile da usare.

Nell'uso più semplicistico, Subversion e Git sono praticamente gli stessi. 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 si sta ramificando e lavorando con altre persone.

Uso Subversion da alcuni anni e dopo aver utilizzato SourceSafe , adoro Subversion. In combinazione con TortoiseSVN , non riesco davvero a immaginare come potrebbe essere migliore.

Eppure c'è un numero crescente di sviluppatori che affermano che Subversion ha problemi e che dovremmo passare alla nuova generazione di sistemi di controllo della versione distribuita, come Git .

Come migliora Git su Subversion?


Adoro assolutamente poter gestire i rami locali del mio codice sorgente in Git senza confondere l'acqua del repository centrale. In molti casi eseguirò il checkout del codice dal server Subversion ed eseguirò un repository Git locale solo per poterlo fare. È anche bello che l'inizializzazione di un repository Git non inquini il filesystem con un mucchio 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 a leggere i log di commit.


Altre risposte hanno fatto un buon lavoro nello spiegare le caratteristiche principali di Git (che sono fantastiche). Ma ci sono anche tanti piccoli modi in cui Git si comporta meglio e aiuta a mantenere la mia vita più sana. 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 tuo 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, dovranno essere scritti per ignorare queste directory .svn. Hai anche bisogno di un intero comando ("svn export") solo per ottenere una copia sana dei tuoi file.
  4. In SVN, ogni file e cartella può provenire da una revisione o ramo diverso. All'inizio sembra bello avere questa libertà. Ma ciò che ciò significa in realtà è che ci sono milioni di modi diversi per completare completamente il checkout locale. (ad esempio, se "svn switch" non riesce a metà strada o se si immette un comando errato). E la parte peggiore è: se mai ti imbatti in una situazione in cui alcuni dei tuoi file provengono da un posto e alcuni da un altro, lo "stato svn" ti dirà che tutto è normale. Dovrai fare "svn info" su ogni file / directory per scoprire quanto 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 sposti o elimini qualcosa. Git lo capirà e basta.
  6. Ignorare la semantica è più facile in Git. Se si ignora un modello (come * .pyc), verrà ignorato per tutte le sottodirectory. (Ma se vuoi davvero ignorare qualcosa per una sola directory, puoi). Con SVN, sembra che non esiste un modo semplice per ignorare un modello in tutte le sottodirectory.
  7. Un altro elemento che coinvolge ignora i file. Git rende possibile che le impostazioni "private" ignorino (usando il file .git / info / exclude), che non influirà su nessun altro.

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 è incredibilmente più veloce in questo caso) e le cartelle di lavoro sono più piccole (il che mi fa ancora impazzire).

Quando lavori su sovversione o su qualsiasi altro sistema di controllo di revisione client / server, essenzialmente crei copie funzionanti sul tuo computer controllando le revisioni. Ciò rappresenta un'istantanea nel tempo dell'aspetto del repository. Aggiorna la tua copia di lavoro tramite aggiornamenti e aggiorna il repository tramite commit.

Con un controllo di versione distribuito, non hai un'istantanea, ma piuttosto l'intera base di codice. Vuoi fare un diff con una versione 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 fare molte delle operazioni a cui sei abituato. In altre parole, non hai solo un'istantanea di una data revisione, ma l'intera base di codice.

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


Git e DVCS in generale sono fantastici per gli sviluppatori che fanno molta codifica indipendentemente l'uno dall'altro perché ognuno ha il proprio ramo. Se hai bisogno di un cambiamento da qualcun altro, però, lei deve impegnarsi nel suo repository locale e quindi deve spingerti quel cambiamento o devi estrarlo da lei.

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

Tutto ciò può essere affrontato con i processi umani, ovviamente; DVCS ha appena rotto qualcosa che è stato risolto dal controllo centralizzato della versione al fine di fornire alcune nuove comodità.


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

La differenza fondamentale è che è decentralizzato. Immagina di essere uno sviluppatore in viaggio, 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 e ottenere tutti i vantaggi del controllo del codice sorgente. Quando riacquisti la connettività al repository principale, puoi impegnarti contro di essa.

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

Git sembra essere la cosa "nuova, brillante, bella". Non è affatto male (c'è una ragione per cui Linus l'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.

Modifica: Quindi questa risposta ha ormai un anno e genera ancora molti voti, quindi ho pensato di aggiungere qualche spiegazione in più. Nell'ultimo anno da quando ho scritto questo, Git ha guadagnato molto slancio e supporto, in particolare da quando siti come GitHub sono davvero decollati. Attualmente sto usando sia Git che Subversion e mi piacerebbe condividere alcune intuizioni personali.

Prima di tutto, Git può essere davvero fonte di confusione all'inizio quando si lavora decentralizzato. Che cos'è un telecomando? e come impostare correttamente il repository iniziale? sono due domande che sorgono all'inizio, soprattutto rispetto al semplice "svnadmin create" di SVN, "git init" di Git può prendere i parametri --bare e --shared che sembra essere il modo "corretto" di 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 i rami.

Git brilla DAVVERO quando si è decentralizzati. Ho un server a casa e un laptop in viaggio 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 di SVK o di come copiare il repository). Con Git, questa è comunque la modalità predefinita. È comunque un comando aggiuntivo (git commit esegue il commit a livello locale, mentre git push origin master spinge il ramo master sul telecomando 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" (suppongo che alla maggior parte delle persone piaccia ancora un "master-repository" centrale ).

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

SVN ha il vantaggio di essere MOLTO più semplice da imparare: c'è il tuo repository, tutte le modifiche verso di esso, se sai come creare, eseguire il commit e il checkout e sei pronto per andare e puoi raccogliere cose come ramificare, aggiornare ecc. Più tardi su.

Git ha il vantaggio di essere MOLTO più adatto se alcuni sviluppatori non sono sempre connessi al repository principale. Inoltre, è molto più veloce di SVN. E da quello che sento dire, ramificare e fondere il supporto è molto meglio (cosa prevedibile, poiché questi sono i motivi principali per cui è stato scritto).

Questo spiega anche perché guadagna così tanto ronzio su Internet, poiché Git è perfettamente adatto ai progetti Open Source: basta Fork, applicare le modifiche al proprio Fork e quindi chiedere al manutentore del progetto originale di apportare le modifiche. Con Git, questo funziona e basta. Davvero, provalo su Github, è magico.

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

Ma anche con questa lunga aggiunta, resto ancora al mio messaggio principale: Git non è migliore o peggiore, è solo diverso. Se hai bisogno del "Controllo del codice sorgente offline" e della volontà di dedicare del tempo extra all'apprendimento, è fantastico. Ma se hai un controllo sorgente rigorosamente centralizzato e / o stai lottando per introdurre il controllo sorgente in primo luogo perché i tuoi colleghi non sono interessati, allora la semplicità e gli strumenti eccellenti (almeno su Windows) di SVN brillano.



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


La cosa divertente è: ospito progetti in Subversion Repos, ma accedo ad essi tramite il comando Git Clone.

Leggi Sviluppa con Git su un progetto codice Google

Sebbene Google Code parli nativamente Subversion, puoi facilmente usare Git durante lo sviluppo. La ricerca di "git svn" suggerisce che questa pratica è diffusa e anche noi ti incoraggiamo a sperimentarla.

L'uso di Git su un repository Svn mi dà vantaggi:

  1. Posso lavorare distribuito su più macchine, impegnandomi e tirandole da e verso di loro
  2. Ho un archivio centrale di backup/public svn backup/public per gli altri da verificare
  3. E sono liberi di usare Git per conto proprio

Mi piace Git perché in realtà aiuta gli sviluppatori di comunicazioni a sviluppatori 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 ampio pool di sviluppatori che lavorano su un singolo progetto.

Ad esempio, dire che ti fidi di 5 sviluppatori e estrae i codici solo 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 fiduciario degli sviluppatori in cui la responsabilità del codice è condivisa tra la comunità di sviluppo.

Naturalmente ci sono altri vantaggi che sono menzionati in altre risposte qui.


Questa è la domanda sbagliata da porre. È 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 progettato come un set di costruzione di controllo di versione di basso livello e abbia un'interfaccia barocca orientata agli sviluppatori Linux rende più facile per le guerre sante ottenere trazione e percepire la legittimità. I sostenitori di Git fanno battere il tamburo con milioni di vantaggi del flusso di lavoro, che svn proclamano inutili. Molto presto l'intero dibattito è definito centralizzato e distribuito, al servizio degli interessi della comunità degli strumenti svn aziendali. Queste aziende, che in genere pubblicano gli articoli più convincenti sulla superiorità di 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 creare abbastanza facilmente una sostituzione centralizzata della sovversione, nonostante sia in circolazione da più del doppio, svn non è mai stato in grado di far funzionare il tracciamento delle fusioni di base ovunque così come in git. Un motivo di base di ciò è la decisione di progettazione di rendere i rami uguali alle directory. Non so perché siano andate in questo modo in origine, sicuramente rende i controlli parziali molto semplici. Sfortunatamente, è anche impossibile tenere traccia della storia in modo corretto. Ora, ovviamente, dovresti usare le convenzioni del layout del repository di sovversione per separare i rami dalle directory normali e svn usa alcune euristiche per far funzionare le cose per i casi d'uso quotidiani. Ma tutto questo è solo una carta di una decisione di progetto di basso livello molto scadente e limitante. Essere in grado di fare un diff a livello di repository (piuttosto che diff a livello di directory) è una funzionalità di base e critica per un sistema di controllo della versione e semplifica notevolmente gli interni, rendendo possibile la creazione di funzionalità più intelligenti e utili su di esso. Puoi vedere la quantità di sforzo che è stato fatto per estendere la sovversione, e tuttavia quanto è lontano dall'attuale raccolto di VCS moderni in termini di operazioni fondamentali come la risoluzione di unione.

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

Subversion 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 non sarebbe davvero svn, vero? Indipendentemente da quanto pensi di non avere le capacità di un VCS moderno, la tua ignoranza non ti proteggerà dalle insidie ​​di 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 della fonte è uno strumento così fondamentale nell'arsenale dello sviluppatore, che ritengo che debba essere dichiarato in modo inequivocabile. Indipendentemente dal requisito di utilizzare svn per motivi organizzativi, imploro tutti gli utenti svn di non lasciare che la loro mente logica costruisca una falsa convinzione che i VCS più moderni sono 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 imparerai a utilizzare VCS meglio progettati, che si tratti di Git, Mercurial, Darcs o molti altri.


Riguarda la facilità d'uso / i 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 gli URL del repository quando si eseguono le fusioni.

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 sovversione, perché a quel punto è necessario impostare un server o una posizione "dedicati".

Puoi farlo sia con git che con SVN, ma i vantaggi di git vengono superati dalla necessità di eseguire ulteriori passaggi per la sincronizzazione con un server centrale. In SVN ti impegni e basta. 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 strumenti GUI migliori, tuttavia l'ecosistema git sembra essere in rapido recupero, quindi non mi preoccuperei di questo a lungo termine.


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

Con Git ottieni un VCS più flessibile. Puoi usarlo allo stesso modo di SVN con un repository remoto in cui esegui tutte le modifiche.Ma puoi anche usarlo principalmente offline e inviare di tanto in tanto le modifiche al repository remoto. Ma Git è più complesso e ha una curva di apprendimento più ripida. Mi sono trovato per la prima volta a impegnarmi in filiali sbagliate, a creare filiali indirettamente o a ricevere messaggi di errore con poche informazioni sull'errore e dove devo cercare con Google per ottenere informazioni migliori. Alcune cose semplici come la sostituzione dei marcatori ($ Id $) non funzionano, ma GIT ha un meccanismo di filtraggio e hook molto flessibile per unire i propri script e quindi ottieni tutto ciò di cui hai bisogno e altro, ma richiede più tempo e lettura della documentazione ;)

Se lavori principalmente offline con il tuo repository locale non hai alcun backup se qualcosa viene perso sul tuo computer locale. Con SVN stai lavorando principalmente con un repository remoto che è allo stesso tempo il tuo backup su un altro server ... Git può funzionare allo stesso modo, ma questo non era l'obiettivo principale di Linus avere qualcosa come SVN2. È stato progettato per gli sviluppatori del kernel Linux e le esigenze di un sistema di controllo della versione distribuito.

Git è meglio di SVN? Gli sviluppatori che richiedono solo un po 'di cronologia delle versioni e un meccanismo di backup hanno una vita buona e facile con SVN. Gli sviluppatori che lavorano spesso con filiali, testano più versioni contemporaneamente o lavorano principalmente offline possono beneficiare delle funzionalità di Git. Ci sono alcune funzioni molto utili come lo stashing non trovato con SVN che può semplificare la vita. D'altra parte, non tutte le persone avranno bisogno di tutte le funzionalità. Quindi non riesco a vedere i morti di SVN.

Git ha bisogno di una documentazione migliore e la segnalazione degli errori deve essere più utile. Anche le utili GUI esistenti sono solo raramente. Questa volta ho trovato solo 1 GUI per Linux con il supporto della maggior parte delle funzionalità di Git (git-cola). L'integrazione con Eclipse funziona ma non è rilasciata ufficialmente e non esiste un sito di aggiornamento ufficiale (solo qualche sito di aggiornamento esterno con build periodiche dal trunk http://www.jgit.org/updates ) Quindi il modo più preferito di usare Git in questi giorni è la riga di comando.


Tutte le risposte qui sono come previsto, incentrate sul programmatore, ma cosa succede se la tua azienda utilizza il controllo di revisione al di fuori del codice sorgente? Esistono molti documenti che non sono codice sorgente che beneficiano del controllo della versione e dovrebbero vivere vicini 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, confronta la facilità d'uso, sia negli strumenti client che nella formazione, 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 spiegare a un non programmatore. Mi piacerebbe essere smentito, perché poi sarei in grado di valutare git e in realtà spererei che venisse accettato da persone che hanno bisogno del controllo della versione che non sono programmatori.

Anche in questo caso, se il management chiedesse perché dovremmo passare da un sistema di controllo di revisione centralizzato a uno distribuito, mi farebbe fatica a dare una risposta onesta, perché non ne abbiamo bisogno.

Disclaimer: mi sono interessato a Subversion all'inizio (intorno al v0.29), quindi ovviamente sono di parte, ma le aziende per cui ho lavorato da quel momento stanno beneficiando del mio entusiasmo perché ne ho incoraggiato e supportato l'uso. Sospetto che sia così che succede con la maggior parte delle società di software. Con così tanti programmatori che saltano sul carro di Git, mi chiedo quante aziende perderanno i vantaggi dell'utilizzo del controllo di versione al di fuori del codice sorgente? Anche se disponi di sistemi separati per team diversi, perdi alcuni dei vantaggi, come l'integrazione del monitoraggio dei problemi (unificata), aumentando al contempo i requisiti di manutenzione, hardware e formazione.


Blog di David Richards WANdisco su Subversion / GIT

L'emergere di GIT ha portato con sé una razza di fondamentalisti DVCS - i "Gitteron" - che pensano che qualsiasi cosa diversa da GIT sia una merda. I Gitteron sembrano pensare che l'ingegneria del software avvenga sulla propria isola e spesso dimenticano che la maggior parte delle organizzazioni non impiega esclusivamente ingegneri del software senior. Va bene, ma non è come 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 circa 5 milioni di utenti e circa la metà il mercato globale.

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


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

Penso che sia abbastanza sicuro dire che tra gli sviluppatori, la SVN vs. L'argomento Git infuria da qualche tempo, con tutti che hanno la propria opinione su quale sia il migliore. Questo è stato anche sollevato nelle domande durante il nostro webinar su Subversion nel 2010 e oltre.

Hyrum Wright, il nostro direttore dell'open source e il presidente della Subversion Corporation parlano delle differenze tra Subversion e Git, insieme ad altri sistemi di controllo della versione distribuita (DVCS).

Parla anche delle imminenti modifiche in Subversion, come Working Copy Next Generation (WC-NG), che secondo lui farà sì che numerosi utenti Git si convertano nuovamente in Subversion.

Guarda il suo video e facci sapere cosa ne pensi commentando questo blog o pubblicando nei nostri forum. La registrazione è semplice e richiederà solo un momento!


Easy Git ha una bella pagina che confronta l'utilizzo effettivo di Git e SVN che ti darà un'idea di ciò che Git può fare (o fare più facilmente) rispetto a SVN. (Tecnicamente, questo si basa su Easy Git, che è un involucro leggero sopra Git.)



Innanzitutto, il controllo simultaneo della versione sembra un problema facile da risolvere. Non lo è affatto. Comunque...

SVN è abbastanza non intuitivo. Git è anche peggio. [speculazione sarcastica] Ciò potrebbe essere dovuto al fatto che gli sviluppatori, a cui piacciono i problemi difficili come il controllo simultaneo della versione, non hanno molto interesse a creare una buona interfaccia utente. [/ Sarcastico-speculazione]

I sostenitori di SVN pensano di non aver bisogno di un sistema di controllo della versione distribuito. L'ho pensato anch'io. Ma ora che usiamo esclusivamente Git, sono un credente. Ora il controllo della versione funziona per me E per il team / progetto invece di lavorare solo per il progetto. Quando ho bisogno di un ramo, mi ramifico. A volte è un ramo che ha un ramo corrispondente sul server, a volte no. Per non parlare di tutti gli altri vantaggi che dovrò studiare (grazie in parte all'assurda e assurda mancanza dell'interfaccia utente che è un moderno sistema di controllo della versione).


Per le persone che cercano una buona interfaccia grafica Git, Syntevo SmartGit potrebbe essere una buona soluzione. Il suo proprietario, ma gratuito per uso non commerciale, funziona su Windows / Mac / Linux e supporta persino SVN usando una specie di bridge git-svn, credo.







git