Cosa fa SVN meglio di Git? [chiuso]

Non c'è dubbio che la maggior parte dei dibattiti sugli strumenti del programmatore si concentri sulla scelta personale (da parte dell'utente) o sull'enfasi del design , cioè sull'ottimizzazione del design in base a casi d'uso particolari (dal costruttore dello strumento). Gli editor di testo sono probabilmente l'esempio più importante: un programmatore che lavora su Windows al lavoro e che codifica in Haskell su Mac a casa, apprezza l'integrazione multipiattaforma e del compilatore e sceglie quindi Emacs su TextMate , ecc.

È meno comune che una tecnologia appena introdotta sia davvero, dimostrabilmente superiore alle opzioni esistenti.

È questo il caso dei sistemi di controllo versione (VCS), in particolare VCS centralizzato ( CVS e SVN ) rispetto a VCS distribuito ( Git e Mercurial )?

Ho usato SVN per circa cinque anni e SVN è attualmente usato dove lavoro. Poco meno di tre anni fa sono passato a Git (e GitHub) per tutti i miei progetti personali.

Posso pensare a una serie di vantaggi di Git over Subversion (e che per la maggior parte in astratto ai vantaggi della distribuzione su VCS centralizzata), ma non riesco a pensare a un contro esempio - un compito (che è rilevante e si presenta in un solito programmatore flusso di lavoro) che Subversion fa meglio di Git.

L' unica conclusione che ho tratto da questo è che non ho dati - non che Git sia migliore, ecc.

La mia ipotesi è che tali contro-esempi esistano, quindi questa domanda.

Subversion è un repository centrale

Mentre molte persone vorranno avere repository distribuiti per gli ovvi benefici della velocità e delle copie multiple, ci sono situazioni in cui un repository centrale è più desiderabile. Ad esempio, se hai un pezzo di codice critico a cui non vuoi che nessuno acceda, probabilmente non vorrai metterlo sotto Git. Molte aziende vogliono mantenere il loro codice centralizzato e (immagino) tutti i (seri) progetti governativi sono sotto deposito centrale.

La sovversione è saggezza convenzionale

Questo per dire che molte persone (in particolare manager e capi) hanno il solito modo di numerare le versioni e di vedere lo sviluppo come una "linea singola" nel tempo hardcoded nel loro cervello. Senza offesa, ma la liberalità di Git non è facile da ingoiare. Il primo capitolo di ogni libro Git ti dice di cancellare tutti gli ideali convenzionali dalla tua mente e ricominciare da capo.

Subversion lo fa in un modo e nient'altro

SVN è un sistema di controllo della versione. Ha un modo per fare il suo lavoro e tutti lo fanno allo stesso modo. Periodo. Ciò semplifica la transizione da / verso SVN da / verso altri VCS centralizzati. Git NON è nemmeno un VCS puro - è un file system, ha molte topologie su come impostare i repository in diverse situazioni - e non esiste uno standard. Ciò rende più difficile sceglierne uno.

Altri vantaggi sono:

• SVN supporta directory vuote
• SVN ha un supporto Windows migliore
• SVN può estrarre / clonare un sottoalbero
• SVN supporta il controllo di accesso esclusivo, svn lockutile per i file difficili da unire
• SVN supporta file binari e file di grandi dimensioni più facilmente (e non richiede la copia di versioni precedenti ovunque).
• L'aggiunta di un commit comporta un numero considerevolmente minore di passaggi poiché non vi è alcun pull / push e le modifiche locali vengono sempre implicitamente riproposte svn update.

Un vantaggio di Subversion su Git può essere che Subversion consente di estrarre solo sotto-alberi. Con Git l'intero repository è un'unità, puoi ottenere solo tutto o niente. Con il codice modulare, questo può essere abbastanza carino rispetto ai sottomoduli Git. (Anche se i sottomoduli Git hanno il loro posto, ovviamente.)

E un piccolo piccolo vantaggio: Subversion può tracciare directory vuote. Git tiene traccia dei contenuti dei file, quindi una directory senza file non verrà visualizzata.

Mi vengono in mente tre. Innanzitutto, è un po 'più facile fare grok, specialmente per i non sviluppatori. Concettualmente è molto più semplice delle opzioni DCVS . Il secondo è la maturità, in particolare TortoiseSVN su Windows. TortoiseHg sta recuperando terreno però. In terzo luogo, la natura della bestia - solo l'immagine di un filesystem in cui è possibile controllare le cose da qualsiasi livello dell'albero - può rivelarsi molto utile in alcuni scenari, come il controllo delle versioni di una varietà di file di configurazione ampiamente diversi tra dozzine di server senza dozzine di repository.

Questo non vuol dire che non stiamo spostando tutto lo sviluppo su Mercurial.

• I repository SVN sono più gestibili dal punto di vista di un manager e di un amministratore ( ACL + metodi di autenticazione + hotcopy + mirror + dump)
• I gancio SVN * sono più facili da implementare e supportare
• svn:external ha più potenza e flessibilità rispetto ai sottomoduli
• Gli alberi dei repository basati su filesystem sono più facili da usare rispetto ai repository monolitici con separazione solo logica
• SVN ha strumenti client più diversi
• SVN ha front-end web utilizzabili di terze parti, molto meglio di Git
• SVN non ti spezza il cervello

Ho scritto questo come un commento sulla risposta di qualcun altro, ma credo che meriti di essere una risposta in sé e per sé.

La configurazione accuratamente scelta della mia azienda per SVN richiede il blocco a livello di file per modificare il contenuto e mai e poi mai utilizza l'unione. Di conseguenza, più sviluppatori si contendono i blocchi, e può essere un grosso collo di bottiglia, e non c'è mai alcuna possibilità di un conflitto di unione.

SVN fa sicuramente il controllo manageriale top-down meglio di Git. Nella mia migrazione di skunkworks su Git (chiedendo perdono piuttosto che permesso) ho terrorizzato il mio manager molte volte con l'idea che non ci sono server centrali di controllo master controllati da software a cui siamo tutti schiavi.

Le mie ragioni:

• maturità - sia il server che gli strumenti (ad esempio TortoiseSVN)
• semplicità: meno passaggi, un commit è un commit. DVCS come Git e Mercurial comportano il commit, quindi spingono.
• gestione binaria - SVN gestisce gli eseguibili binari e le immagini meglio di Git / Hg. Particolarmente utile con i progetti .NET poiché mi piace controllare gli strumenti relativi alla build nel controllo del codice sorgente.
• numerazione - SVN ha uno schema di numerazione commit leggibile, usando solo cifre - più facile da tenere traccia dei numeri di revisione. Git e Hg lo fanno in modo abbastanza diverso.

Apprezzo che tu stia cercando buone informazioni, ma questo tipo di domanda invita semplicemente: "Penso che Git sia così tanto vincente e svn teh suxorz!" risposte.

Ho provato e trovato personalmente Git un po 'troppo per la mia piccola squadra. Sembra che sarebbe fantastico per una grande squadra distribuita o un gruppo di squadre che sono geograficamente disperse. Capisco molto i vantaggi di Git, ma secondo me il controllo del codice sorgente non mi tiene sveglio la notte.

Sono un cacciatore di cervi e quando io e i miei amici usciamo siamo armati fino ai denti, irti di munizioni e equipaggiamento ad alta tecnologia. Mi faccio vedere con un solo fucile, sette proiettili e un coltello da caccia. Se ho bisogno di più di sette round, sto facendo qualcosa di sbagliato, e lo faccio bene come chiunque altro.

Il punto che sto cercando di sottolineare è che se sei un piccolo team che lavora su un progetto medio-piccolo e hai già familiarità con SVN, utilizzalo. È sicuramente meglio di CVS o (shudder) SourceSafe , e non mi ci vogliono più di cinque minuti per impostare un repository. Git a volte può essere eccessivo.

Questo è tutto relativo, e come ha detto maple_shaft, se uno funziona per te, non cambiare!

Ma se vuoi davvero qualcosa , direi che forse è meglio per designer, programmatori web e simili - gestisce un po 'meglio immagini e file binari .

Usabilità. In realtà non è merito di Subversion ma piuttosto TortoiseSVN . TortoiseGit esiste, ma ha ancora molta strada da fare per abbinare TortoiseSVN.

Se chiedessi cosa fa Git meglio di SVN, risponderei a GitHub . È divertente come gli strumenti di terze parti facciano una differenza così grande.

Quando non hai bisogno di diramare e unire , SVN (con TortoiseSVN su Windows) è molto facile da capire e usare. Git è troppo complesso per i casi semplici, in quanto cerca di semplificare la ramificazione / fusione.

(Molti piccoli progetti non devono mai ramificarsi se gestiti bene. Git è indirizzato a casi complessi; pertanto la maggior parte della documentazione di Git presuppone che sia necessario eseguire operazioni complesse come la diramazione e l'unione.)

Bene, mio ​​nonno poteva usare SVN sul suo computer Windows XP, ma avrebbe avuto problemi con Git. Forse questo è più un risultato di TortoiseSVN su TortoiseGit , ma penso che sia piuttosto legato al fatto, che Git è intrinsecamente più potente e quindi più complesso, e sarebbe inutile ridurlo allo stesso livello.

Ora non importa davvero per mio nonno, perché non ha programmato fino a tardi. Tuttavia, una volta ero in una squadra, dove i nostri artisti grafici stavano usando anche il nostro controllo del codice sorgente.

E quelle sono persone che si aspettano semplicemente che i loro strumenti funzionino (anche io, ma ho una possibilità realistica di farli funzionare in caso di fallimento) ed essere intuitivi. A parte il fatto che sarebbe stato piuttosto uno sforzo per farli andare d'accordo con un DVCS , c'era poco da guadagnare. E con solo due programmatori nel team, era logico che ci attenessimo anche a SVN.

Al lavoro non sono riuscito a passare gli sviluppatori da SVN a nessun DVCS per due motivi:

• Checkout parziali (come solo tre cartelle da profondità diverse nella struttura del progetto)
• Blocco dei file (report in formato binario)

• Senso di sicurezza quando si esegue un 'svn commit'. Dato che i commit vanno sul server, non posso fare nulla che possa cancellare i miei cambiamenti dopo che sono stati eseguiti. A dire il vero, gli commit sono locali, quindi fino a quando spingo, un rand 'rm -rf' ed è tutto finito.
• Gli commit sono autenticati. Di default in Git posso dire che mi sto impegnando come chiunque.
• Meno comandi da imparare per l'uso quotidiano. 'svn checkout', 'svn up' e 'svn commit' ti porteranno abbastanza lontano.
• I checkout condivisi funzionano molto meglio. Quando vai a impegnarti, ti chiede il tuo nome utente / password, non devi ricordarti di passare determinati argomenti della riga di comando. A volte al lavoro abbiamo una macchina condivisa con una verifica svn condivisa di alcuni progetti. Qualcuno potrebbe dire "Bob, puoi vedere questo su questa macchina" e lui può, e può eseguire il commit delle sue modifiche come suo utente senza problemi.
• Layout del repository. Puoi avere un progetto ombrello e sottoprogetti e scegliere cosa controllare quando.
• I numeri di revisione stanno incrementando numeri interi.
• Progettato per il flusso di lavoro del repository centrale.

Altre persone hanno pubblicato delle risposte piuttosto valide, ma per quanto riguarda le autorizzazioni? Usando Subversion su SSH, puoi creare un account separato sul tuo server per SVN. A diversi sviluppatori può essere concesso un accesso diverso a diverse parti del repository. GIT può farlo? Immagino che ci sia gitolite, ma per me non sembra flessibile o robusto, né conosco nessuno che lo stia effettivamente usando.

Velocità. A volte occorrono 10 o 15 minuti per clonare un repository git di grandi dimensioni, mentre un repository di sovversione di dimensioni simili richiede un paio di minuti per il check-out.

Pubblico questo come risposta piuttosto che come commento.

Devo ammettere che i DVCS sono abbastanza in voga in questo momento, ma proverò a spiegarne il perché.

I DVCS sono migliori perché, proprio come molte persone hanno detto, "questo è il modo in cui avremmo dovuto lavorare dall'inizio". È vero, puoi fare con un DVCS quello che facevi con SVN, quindi in un modo che rende SVN obsoleto.

Tuttavia, non tutti i progetti software sono validi quanto si ottiene:

• I progetti a lungo termine hanno beneficiato molto del DVCS, poiché utilizzano meno costi generali, consentono una gestione molto migliore (branching ecc.) Ed è notevolmente supportato da host come google code e github.

• Quei progetti non sono i soli, ci sono altri tipi di progetti che vengono sviluppati in aziende senza alcuna assistenza dal mondo esterno o da Internet: tutto è fatto internamente e spesso a breve termine. Un buon esempio: un videogioco. Il codice si evolve rapidamente.

Per quest'ultimo caso, gli sviluppatori non hanno davvero bisogno di diramazioni o funzionalità sofisticate che DVCS può offrire, vogliono solo condividere codice sorgente e risorse. È improbabile che il codice che realizzano venga riutilizzato, poiché esiste una scadenza. Si basano su SVN piuttosto che su un DVCS per diversi motivi:

• Gli sviluppatori hanno macchine che appartengono alla società e questo potrebbe cambiare rapidamente. La configurazione di un repository è una perdita di tempo.
• Se quei ragazzi non hanno la propria macchina, hanno meno probabilità di lavorare sullo stesso codice sorgente / parte del progetto. Più uno per i dati centralizzati.
• velocità di rete e grandi quantità di denaro consentono l'uso di un server centralizzato che gestisce tutto ciò che è SVN, è una cattiva pratica ma vengono effettuati backup ecc.
• SVN è solo più semplice da usare, anche se è nel modo sbagliato: sincronizzare i file su peer senza ridondanza non è un problema semplice e "farlo nel modo giusto" non può farlo in tempo se si vuole sempre che sia perfetto.

Pensa alla macchina dell'industria dei giochi e al modo in cui SVN risparmia tempo; la gente comunica molto di più su questi progetti perché i giochi riguardano la programmazione ripetitiva e il codice adattivo: non c'è nulla di difficile da codificare, ma deve essere fatto nel modo giusto, al più presto. I programmatori vengono assunti, codificano la loro parte, la compilano, la provano un po ', si impegnano, finiscono, i tester di gioco si occuperanno del resto.

I DVCS sono realizzati per Internet e per progetti molto complessi. Le SVN sono destinate a progetti di team ristretti, a breve termine. Non hai bisogno di imparare molto da SVN, è quasi un FTP con una differenza stupida.

Subversion e Git incoraggiano entrambi approcci particolari (e molto diversi) allo sviluppo e alla collaborazione. Alcune organizzazioni trarranno il massimo da Git e altre trarranno il massimo da Subversion, a seconda della loro organizzazione e cultura.

Git e Mercurial sono entrambi eccellenti per team distribuiti e liberamente organizzati di programmatori professionisti altamente competenti. Entrambi questi popolari strumenti DVCS incoraggiano piccoli repository, con il riutilizzo tra gli sviluppatori tramite librerie pubblicate con interfacce (relativamente) stabili.

Subversion, d'altra parte, incoraggia una struttura di gestione più centralizzata e strettamente accoppiata, con una maggiore comunicazione tra gli sviluppatori e un maggior grado di controllo organizzativo sulle attività di sviluppo quotidiane. All'interno di questi team organizzati in modo più compatto, il riutilizzo tra sviluppatori tende a avvenire tramite librerie non pubblicate con interfacce (relativamente) instabili. TortoiseSVN consente inoltre a Subversion di supportare team multidisciplinari con membri che non sono programmatori professionisti (ad esempio ingegneri di sistema, ingegneri di algoritmi o altri specialisti dell'area).

Se il tuo team è distribuito, con membri che lavorano da casa o da molti siti internazionali diversi, o se preferiscono lavorare da soli e in silenzio, con poca comunicazione faccia a faccia, allora un DVCS come Git o Mercurial sarà un buon adattamento culturale.

Se, d'altra parte, il tuo team si trova in un unico sito, con un approccio "team" attivo allo sviluppo e molte comunicazioni faccia a faccia, con un "ronzio" nell'aria, SVN potrebbe essere un migliore adattamento culturale, in particolare se si hanno molte squadre interdisciplinari.

Certo, è possibile configurare Git e Hg (potenti e flessibili come sono) per fare praticamente tutto quello che vuoi, ma è sicuramente più lavoro e sono sicuramente più difficili da usare, in particolare per quei membri del team che non sarebbe naturalmente incline a utilizzare qualsiasi forma di controllo di versione di sorta.

Infine, trovo anche che la condivisione delle funzionalità utilizzando lo sviluppo di librerie "a caldo" sotto Svn (con CI e un approccio test-driven) consente un ritmo di sviluppo coordinato che è difficile da raggiungere con un team più distribuito e debolmente accoppiato.

Di seguito sono riportati i due motivi per cui rimango ancora con SVN.

1. La curva di apprendimento. SVN è più semplice di Git, anche l'installazione (server o client), l'usabilità e i comandi.
2. Pacchetti server migliori come Subversion Edge , VisualSVN , uberSVN ecc.

Ci sono due principali tendenze nel controllo delle versioni in questo momento; Distribuzione e integrazione .

Git è eccezionale nel decentramento.

SVN ha molti strumenti integrati che si integrano con esso. È comune configurare il server SVN in modo che quando si effettua il check-in in una correzione, si menziona il numero di bug nel commento del check-in e lo imposta automaticamente su uno stato "in testing" e avvisa il tester assegnato che è necessario guardarlo. Quindi è possibile taggare una versione e ottenere un elenco di tutti i bug corretti in questa versione.

Gli strumenti che fanno questo con SVN sono maturi e usati ogni giorno.

In Subversion, è possibile modificare i messaggi di registro (chiamati anche "messaggi di commit") dopo che il commit è stato eseguito e inviato. Per la maggior parte degli usi pratici, ciò è impossibile in base alla progettazione in sistemi decentralizzati, incluso git. Ovviamente, in git puoi fare "git commit --amend", ma questo non ti aiuta dopo che il tuo commit è stato spinto altrove. In SVN, quando modifichi il messaggio di registro, lo stai facendo sul repository centrale che tutti condividono, così tutti riceveranno la modifica e senza cambiare l'identificatore della revisione.

La modifica dei messaggi di registro dopo il fatto è spesso molto utile. Oltre a correggere un errore o un'omissione in un messaggio di registro, ti consente di fare cose come aggiornare un messaggio di registro per fare riferimento a un commit futuro (come una revisione che corregge un bug o completa il lavoro introdotto nella revisione corrente) .

A proposito, non c'è pericolo di perdere informazioni. Gli hook pre-revprop-change e post-revprop-change possono salvare una cronologia dei vecchi messaggi se sei veramente preoccupato, o inviare e-mail con il messaggio di registro diff (questo è più comune, in realtà), in modo che ci sia un pista di controllo.