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?
Risposte:
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. Oggi 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 sei decentralizzato. 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ì, conosco SVK o i modi per copiare il repository). Con Git, questa è comunque la modalità predefinita. È comunque un comando extra (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 i bridge Git-SVN: 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.
Con Git puoi praticamente fare qualsiasi cosa offline, perché ognuno ha il proprio repository.
Creare filiali e fondersi tra le filiali è davvero facile.
Anche se non hai i 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 inserirle nel loro progetto, inclusi i manutentori ufficiali.
È banale biforcare un progetto, modificarlo e continuare a unire le correzioni del ramo HEAD.
Git funziona per gli sviluppatori del kernel Linux. Ciò significa che è veramente veloce (deve essere) e si ridimensiona a migliaia di collaboratori. Git utilizza 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 qualunque flusso di lavoro desideri e Git lo supporterà.
Infine, c'è GitHub , un ottimo sito per ospitare i tuoi repository Git.
Svantaggi di Git:
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:
git mve git rm.
" Why Git is Better than X " delinea i vari pro e contro di Git rispetto ad altri SCM.
Brevemente:
Ci sono alcuni svantaggi:
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 git@github.com: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.
Google Tech Talk: Linus Torvalds su git
http://www.youtube.com/watch?v=4XpnKHJAok8
La pagina di confronto di Git Wiki
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.
I punti principali che mi piacciono del DVCS sono quelli:
La ragione principale di un progetto relativamente grande è la comunicazione migliorata creata dal punto 3. Altri sono buoni bonus.
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:
backup/public per gli altri a dare un'occhiataTutte 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.
Subversion è ancora un sistema di controllo versione molto più utilizzato, il che significa che ha un migliore supporto degli strumenti. Troverai plugin SVN maturi per quasi tutti gli IDE e ci sono buone estensioni di Explorer disponibili (come TurtoiseSVN). A parte questo, dovrò essere d'accordo con Michael : Git non è migliore o peggiore di Subversion, è diverso.
Una delle cose di SubVersion che mi infastidisce è che mette la sua cartella in ogni directory di un progetto, mentre git ne mette solo una nella directory root. Non è che grande di un affare, ma piccole cose che si sommano.
Ovviamente, SubVersion ha la tartaruga, che [di solito] è molto bella.
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 percento del mercato mentre Subversion ha circa 5 milioni di utenti e circa la metà di 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.
Git rende anche la ramificazione e la fusione davvero facili. Subversion 1.5 ha appena aggiunto il monitoraggio delle unioni, ma Git è ancora migliore. Con Git la ramificazione è molto veloce ed economica. Rende più fattibile la creazione di un ramo per ogni nuova funzionalità. I repository Oh e Git sono molto efficienti con lo spazio di archiviazione rispetto a Subversion.
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.
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 per fornire alcune nuove comodità.
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 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.
Alcune risposte hanno fatto riferimento a queste, ma voglio chiarire 2 punti:
1) La capacità 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 semplifica l'esecuzione di un commit che include solo una parte delle modifiche. Con Subversion è difficile.
2) La capacità di impegnarsi senza rendere pubblica la modifica. In Subversion, ogni 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 vada bene ... fino a quando non inizi a fonderti ... o fai qualcosa di complicato ... o fai qualcosa che Subversion pensa sia complicato (come fare query per scoprire quali rami hanno incasinato un determinato file, da dove proviene effettivamente 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: è sicuramente utile, ma è più come un extra per il mio caso d'uso. SVK può funzionare anche offline, ma non ho dubbi su quale investire nel mio tempo di apprendimento).
È solo che è incredibilmente potente e veloce e, ben 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 simile) * solo * per dare una mano con una fusione svn?
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)
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.
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 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,
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 monitoraggio 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, rende anche impossibile tenere traccia della cronologia in modo corretto. Ora, ovviamente, dovresti usare le convenzioni di 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 ciò è 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 di 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.
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 molte 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 facile e piacevole 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.
Eric Sink di SourceGear ha scritto una serie di articoli sulle differenze tra i sistemi di controllo della versione distribuiti e non distribuiti. Confronta i pro ei contro dei più popolari sistemi di controllo delle versioni. Lettura molto interessante.
Gli articoli sono disponibili sul suo blog, www.ericsink.com :
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.
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 un certo numero di 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!
Git in Windows è ora abbastanza ben supportato.
Dai un'occhiata a GitExtensions = http://code.google.com/p/gitextensions/
e il manuale per una migliore esperienza con Windows Git.
Ultimamente ho abitato nella terra di Git e mi piace per progetti personali, ma non sarei ancora in grado di passare da Subversion a progetti di lavoro dato il cambiamento nel modo di pensare richiesto dal personale, senza alcun vantaggio pressante. Inoltre, il più grande progetto che gestiamo internamente dipende estremamente da svn: gli esterni che, da quello che ho visto finora, non funzionano così bene e perfettamente in 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).
Perché penso che Subversion sia migliore di Git (almeno per i progetti su cui lavoro), principalmente grazie alla sua usabilità e al flusso di lavoro più semplice:
http://www.databasesandlife.com/why-subversion-is-better-than-git/