Voglio scegliere un sistema di controllo versione per la mia azienda. Finora so di avere Git, Subversion e Mercurial.
In questi giorni vedo che Git è il più usato, quindi mi chiedo: ci sarebbe una ragione specifica per usare ancora Subversion, o dovrei andare direttamente a Git?
SVN non è affatto morto. È ancora in uso estremamente ampio, e non sta andando da nessuna parte presto. SVN è molto più semplice da usare rispetto al controllo di versione distribuito, specialmente se non stai eseguendo un progetto distribuito che ha bisogno di controllo di versione distribuito.
Se si dispone di un solo repository centrale (di cui tutta la società avrà bisogno se sono ancora abbastanza piccoli da cavarsela senza il controllo del codice sorgente finora), è molto più semplice usare SVN per interagire con esso. Ad esempio, con SVN è possibile estrarre le modifiche dal repository o eseguire il commit delle modifiche locali su di esso, con una singola operazione, mentre HG e Git richiedono due o tre passaggi per eseguire il lavoro equivalente.
E con le recenti revisioni, SVN ha risolto molti dei problemi di prestazioni che hanno reso le persone preferire HG e Git. È molto più veloce ora di un paio d'anni fa e, a questo punto, non c'è davvero nessuna buona ragione per guardare a HG o Git per il tuo progetto a meno che tu non abbia effettivamente bisogno delle funzionalità avanzate del controllo di versione distribuito.
Gli strumenti client non sono ancora stati menzionati. Puoi certamente fare tutto con uno script da riga di comando, ma avere un'integrazione con la GUI può essere un vero incremento di produttività.
Lavoriamo principalmente con Visual Studio; l'integrazione nell'IDE è decisamente migliore con SVN che con Git in questo momento. Questo potrebbe cambiare in futuro, ma certamente peserei questo nella tua decisione tanto quanto le funzioni di controllo della versione.
Proprio come tutto il resto, un sistema di controllo delle versioni non è un obiettivo in sé, ma solo uno strumento per portarti dove vai. Scegli quello che ti porterà più veloce in base alla tua situazione.
Sono un fan Git. Recentemente ho dovuto ammettere che uno degli svantaggi di Git è che identifica le versioni con hash come opposto ai numeri di rilascio di svn. Il numero di rilascio può essere reso più semplice per telefono o qualcosa del genere.
E questo è l'unico pro che posso immaginare. Se vuoi veramente fare affidamento su quella funzionalità, puoi averla in un VCS distribuito e / o centralizzato Bazaar . In Git ci sono tag che possono servire allo scopo.
In ogni caso, non potevo immaginare di svilupparmi senza il cambio rapido dei rami e la conservazione. Queste due caratteristiche bastano a battere SVN, dove per quanto mi ricordo la stessa operazione richiedeva la creazione e il check-out di un intero albero in directory separate per raggiungere lo stesso obiettivo.
Le cosiddette "funzioni avanzate di controllo della versione distribuita" vengono fornite con il tempo e non è necessario impararle all'inizio. Non aver paura di loro. Sono qui per aiutarti, non per intralciarti. E non c'è alcun problema a configurare un repository centrale per un DVCS.
Con SVN puoi facilmente eseguire il checkout di parti di un repository fino al livello della cartella, mentre con git ottieni l'intero repository, inclusa tutta la cronologia.
A seconda della situazione, questo potrebbe avere alcuni vantaggi per SVN
(questo ha anche alcuni grossi svantaggi come la "nascosta" .svn nascosta nell'albero delle cartelle).
"Se hai un'attività che può essere svolta in sei ore, è meglio scrivere uno strumento che funzioni in 20 minuti, anche quando la creazione dello strumento richiede sei ore?"
Il controllo della versione distribuita è una bestia diversa da affrontare. Richiede un apprendimento sostanziale per ogni sviluppatore. Se si dispone del buffer per ospitare il processo di apprendimento per ogni sviluppatore, è necessario passare a un buon sistema di controllo della versione distribuito. Una volta terminata la fase di apprendimento, Distributed Version Control è molto meglio del controllo della versione centralizzata.
Il controllo della versione distribuito sembra essere un'eventualità. È qui per rimanere per un tempo molto lungo, è meglio che ci adattiamo ad esso prima che dopo. Ricordo la stessa discussione quando SVN era nuovo e le persone erano abituate al CVS, molti argomenti venivano forniti per non usare SVN, ma alla fine SVN divenne il sistema di controllo di versione più popolare.
Se la società è ben consolidata con un sacco di codice sorgente nel sistema di controllo della versione esistente, passare a un nuovo sistema è un compito importante, ma se la società è piccola o in fase di avviamento, passare a una nuova versione di controllo è molto facile. Ma se ci si attiene a un controllo di versione precedente (in una nuova configurazione) si verificherà il collo di bottiglia da qualche parte in futuro, dove si dovrà eventualmente pianificare una migrazione di controllo della versione.
Ho visto molti commenti SVN pro, ma tutti tendono ad essere della natura "SVN non è male" piuttosto che "SVN è migliore". Quindi ti consiglio vivamente di scegliere un controllo di versione distribuito (come Git) per il tuo progetto.
Modifica Vantaggi di GIT su SVN
Qualcuno ha menzionato gli strumenti (per Visual Studio) come motivo per attenersi a SVN. Il link fornisce il supporto GIT per Visual Studio.
would there be any specific reason to use Subversion those days
Oltre al supporto degli strumenti negli IDE (che non uso) - non proprio, no. Ovviamente SVN potrebbe essere più familiare ma questo è l'unico motivo, e ho trovato sia Hg che Git molto facili (e molto veloci) da imparare.
Sì, ci sono tutte quelle guide complesse là fuori che descrivono come Git è banale una volta capito che i rami sono solo endofunors omeomorfi che mappano le sottovarietà di uno spazio di Hilbert. 1
Non lo capisco. Ma sai cosa? Non importa. Non hai bisogno di sapere nulla di questo per usare Git.
Per la maggior parte, Git e Hg sono facili da usare e hanno vantaggi definitivi su SVN. L'elefante nella stanza è naturalmente ramificato: i rami funzionano solo a Git e Hg. Al contrario, in SVN sono dolorosi nel migliore dei casi e interrotti nel peggiore dei casi (fusione di più teste).
Naturalmente puoi usare ancora SVN. Puoi anche utilizzare Windows XP. Tuttavia, la maggior parte degli utenti che hanno provato entrambi concordano sul fatto che una delle alternative è di gran lunga superiore.
1 Sì, capisco che questo è uno scherzo. Penso.
Leggi altre domande sui tag git version-control svn