Che cosa fa SVN meglio di Git? [chiuso]

Subversion è un repository centrale

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

Subversion è saggezza convenzionale

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

Subversion fa in un modo e nient'altro

SVN è un sistema di controllo della versione. Ha un modo di 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 situazioni diverse e non ci sono standard. Ciò rende più difficile sceglierne uno.

Altri vantaggi:

• SVN supporta le directory vuote
• SVN ha un supporto Windows migliore
• SVN può estrarre / clonare un sotto-albero
• SVN supporta il controllo di accesso esclusivo svn lock che è utile per i file difficili da unire
• SVN supporta più facilmente file binari e di grandi dimensioni (e non richiede la copia di vecchie versioni ovunque).
• L'aggiunta di un commit comporta un numero considerevolmente inferiore di passaggi poiché non vi è alcun pull / push e le tue modifiche locali sono sempre implicitamente basate su svn update .

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

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

Posso pensare a tre. Innanzitutto, è un po 'più facile da convincere, soprattutto per i non sviluppatori. Concettualmente è molto più semplice delle opzioni DCVS . Il secondo è la maturità, in particolare TortoiseSVN su Windows. TortoiseHg sta recuperando velocemente. In terzo luogo, la natura della bestia - solo un'immagine di un filesystem in cui è possibile controllare le cose da qualsiasi livello dell'albero - può essere abbastanza utile in alcuni scenari - come la versione di una varietà di file di configurazione molto diversi tra dozzine di server senza dozzine di repository.

Questo non vuol dire che non stiamo spostando tutti gli sviluppi su Mercurial.

• I repository SVN sono più gestibili dal punto di vista di un manager e dell'amministratore ( ACL + metodi di autenticazione + hotcopy + mirror + discariche)
• SVN * -gli sguardi sono più facili da implementare e supportare
• svn:external ha più potenza e flessibilità dei sottomoduli
• Gli archivi di repository basati su file system sono più facili da utilizzare rispetto agli archivi monolitici con separazione solo logica
• SVN ha altri diversi strumenti client
• SVN ha web-frontend utilizzabili da terze parti, molto meglio di quelli di Git
• SVN non ti spezza il cervello

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

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

SVN fa decisamente meglio il controllo manageriale top-down di Git. Nella mia migrazione skunkworks a Git (chiedendo perdono piuttosto che autorizzazione) ho terrorizzato molte volte il mio manager con l'idea che non c'è t qualsiasi server di controllo principale centrale imposto dal software a cui siamo tutti slave.

I miei motivi:

• scadenza - sia il server che gli strumenti (ad esempio TortoiseSVN)
• semplicità - meno passaggi coinvolti, un commit è un commit. DVCS come Git e Mercurial implicano commit, quindi push.
• gestione binaria - SVN gestisce gli eseguibili e le immagini binari 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 del commit leggibile, usando solo cifre - più facile tracciare i numeri di revisione. Git e Hg lo fanno in modo abbastanza diverso.

Apprezzo che tu stia cercando una buona informazione, ma questo tipo di domande 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. Sembrava che sarebbe stato fantastico per una grande squadra o gruppo di team distribuiti che sono geograficamente dispersi. Capisco molto i vantaggi di Git, ma il controllo del codice sorgente secondo me non è qualcosa che mi tiene sveglio la notte.

Sono un cacciatore di cervi, e quando io e i miei amici usciamo, sono armati fino ai denti, pieni di munizioni e attrezzi high tech. Mi presento con un solo fucile, sette proiettili e un coltello da sciabola. Se ho bisogno di più di sette round, allora sto facendo qualcosa di sbagliato, e faccio altrettanto bene a chiunque altro.

Il punto che sto cercando di fare è che se sei un piccolo team che lavora su un progetto medio-piccolo e hai già familiarità con SVN, allora usalo. È sicuramente migliore di CVS o (shudder) SourceSafe , e non mi occorrono 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 i progettisti, i programmatori web e simili - gestisce un po 'meglio le immagini e i file binari .

Usabilità. Non è proprio merito di Subversion, ma piuttosto TortoiseSVN 's .. TortoiseGit esiste, ma ha ancora una lunga strada da percorrere per abbinare TortoiseSVN.

Se hai chiesto cosa Git fa meglio di SVN, risponderei 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 da usare. Git è troppo complesso per i casi semplici, poiché cerca di semplificare la ramificazione / fusione.

(Molti piccoli progetti non devono mai diramarsi se sono gestiti bene. Git si rivolge a casi complessi, quindi la maggior parte della documentazione di Git presuppone che sia necessario eseguire operazioni complesse come la ramificazione e la fusione.)

Bene, mio nonno poteva usare SVN sul suo computer con Windows XP, ma avrebbe avuto problemi con l'uso di 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 per mio nonno, perché non ha ancora programmato alcuna programmazione. Tuttavia, ero una volta in una squadra, dove i nostri artisti grafici utilizzavano 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) e di essere intuitivi. A parte il fatto, che sarebbe stato un grande sforzo farli andare d'accordo con un DVCS , c'era poco da guadagnare. E con solo due programmatori del team, aveva senso anche per noi limitarci a SVN.

Al lavoro non potevo passare gli sviluppatori da SVN a qualsiasi DVCS per due motivi:

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

• Senso di sicurezza quando si esegue un "svn commit". Dal momento che i commit vengono inviati al server, non è possibile che avvenga un errore che cancellerà le mie modifiche dopo che sono state commesse. In git, i commit sono locali, quindi fino a quando non spingo, un rm "rm -rf" è tutto finito.
• I commit sono autenticati. Di default in git posso dire che sto commettendo come chiunque.
• Meno comandi da imparare per l'uso quotidiano. 'svn checkout', 'svn up' e 'svn commit' ti porteranno molto lontano.
• I checkout condivisi funzionano molto meglio. Quando vai al commit, ti chiede il tuo nome utente / password, non devi ricordarti di passare determinati argomenti della riga di comando. A volte sul posto di lavoro abbiamo una macchina condivisa con un controllo svn condiviso di alcuni progetti. Qualcuno potrebbe dire "Bob puoi guardarlo su questa macchina" e lui può, e può commettere le sue modifiche come suo utente senza errori.
• Layout del repository. Puoi avere un progetto ombrello e sottoprogetti e scegliere cosa controllare quando.
• I numeri di revisione stanno incrementando gli interi.
• Progettato per il flusso di lavoro del repository centrale.

Altre persone hanno pubblicato alcune risposte piuttosto buone, ma per quanto riguarda le autorizzazioni? Usando Subversion su SSH, puoi creare un account separato sul tuo server per SVN. Agli sviluppatori diversi può essere concesso un accesso diverso alle diverse parti del repository. GIT può farlo? Immagino che ci sia la gitolite, ma non mi sembra né flessibile né robusta, né conosco nessuno che la stia effettivamente utilizzando.

Velocità. A volte occorrono 10 o 15 minuti per clonare un grande repository git, mentre un repository di subversion di dimensioni simili impiega un paio di minuti per il checkout.

Lo postò come risposta piuttosto che come commento.

Ammetto che i DVCS sono abbastanza in voga in questo momento, ma cercherò di spiegarne il motivo.

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

Tuttavia, non tutti i progetti software sono buoni come sono:

• Il progetto a lungo termine ha tratto molti benefici da DVCS, perché utilizza meno overhead, consente una gestione molto migliore (branching, ecc.) ed è strongmente supportato da host come google code e github.

• Quei progetti non sono i soli, ci sono altri tipi di progetti che vengono sviluppati nelle aziende senza alcuna assistenza da parte del mondo esterno o di Internet: tutto viene 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 realmente bisogno di ramificazioni o funzionalità sofisticate che DVCS possa offrire, ma vogliono solo condividere il codice sorgente e le risorse. Il codice che fanno non è probabile che venga riutilizzato, perché c'è una scadenza. Si basano su SVN piuttosto che su DVCS per diversi motivi:

• Gli sviluppatori hanno macchine che appartengono all'azienda e questo potrebbe cambiare rapidamente. La configurazione di un repo è una perdita di tempo.
• Se quei ragazzi non hanno la propria macchina, è meno probabile che lavorino 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 SVN, è una cattiva pratica ma i backup sono fatti ecc.
• SVN è solo più semplice da usare, anche se è il modo sbagliato: sincronizzare i file su peer senza ridondanza non è un problema semplice, e "farlo nel modo giusto" non è possibile farlo in tempo se vuoi sempre che sia perfetto.

Pensa alla macchina del settore dei giochi e a come SVN è un risparmiatore di tempo; le persone comunicano molto di più su quei 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 sono assoldati, codificano la loro parte, la compilano, la testano un po ', si impegnano, si fanno, i tester del gioco si occuperanno del resto.

I DVC sono fatti per Internet e per progetti molto complessi. SVN sono per piccoli, a breve termine, progetti di squadra serrati. Non hai bisogno di imparare molto da SVN, è quasi un FTP con una stupida diff.

Subversion e Git incoraggiano entrambi approcci particolari (e molto diversi) allo sviluppo e alla collaborazione. Alcune organizzazioni otterranno di più da Git e altre otterranno di più da Subversion, a seconda della loro organizzazione e cultura.

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

Subversion, d'altra parte, incoraggia una struttura di gestione più centralizzata e strettamente accoppiata, con più 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 gli sviluppatori tende a verificarsi 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 sistemi, ingegneri di algoritmi o altri specialisti di aree tematiche).

Se la tua squadra viene distribuita, con membri che lavorano da casa o da diversi siti internazionali, o se preferiscono lavorare da soli e in silenzio, con una piccola comunicazione faccia a faccia, un DVCS come Git o Mercurial essere un buon adattamento culturale.

Se, d'altra parte, la tua squadra si trova su un singolo sito, con un approccio attivo al "team" per lo sviluppo, e molte comunicazioni faccia a faccia, con un "brusio" nell'aria, quindi SVN potrebbe essere una misura culturale migliore, in particolare se hai un sacco di squadre interdisciplinari.

Naturalmente, è possibile configurare Git e Hg (potenti e flessibili così come sono) per fare praticamente quello che vuoi, ma è sicuramente più lavoro, e sono decisamente più difficili da usare, in particolare per i membri di il team che non sarebbe naturalmente incline a utilizzare qualsiasi forma di controllo della versione di qualsiasi tipo.

Infine, trovo anche che la condivisione delle funzionalità usando lo sviluppo di librerie "hot" sotto Svn (con CI e un approccio basato sui test) permetta un ritmo di sviluppo coordinato che è difficile da ottenere con un team più distribuito e liberamente accoppiato .

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

1. La curva di apprendimento. SVN è più facile di Git, anche il setup (server o client), usabilità e comandi.
2. Pacchetti server migliori come Subversion Edge , VisualSVN , uberSVN ecc.

Al momento ci sono due principali tendenze nel controllo della versione; Distribuzione e integrazione .

Git è grande nel decentramento.

SVN ha molti strumenti integrati che si integrano con esso. È normale impostare il server SVN in modo che quando si esegue il check-in di una correzione, si citi il numero di bug nel commento di controllo, e lo imposta automaticamente ma a uno stato "in testing" e avvisa il tester assegnato di cui hanno bisogno guardarlo. Quindi puoi 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 vengono usati ogni giorno.

In Subversion, puoi modificare i messaggi di log (chiamati anche "messaggi di commit") dopo che il commit è stato eseguito e inviato. Per la maggior parte degli usi pratici, questo è impossibile dalla progettazione in sistemi decentralizzati, incluso git. Certo, in git puoi fare "git commit --amend", ma questo non ti aiuta dopo che il tuo commit è stato spostato altrove. In SVN, quando modifichi il messaggio di registro, lo stai facendo sul repository centrale condiviso da tutti, così tutti potranno ottenere la modifica e senza modificare 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 permette 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 attuale).

Non c'è alcun pericolo di perdere informazioni, a proposito. I ganci pre-rev-change-change e post-rev-rap-change possono salvare una cronologia dei vecchi messaggi se si è veramente preoccupati, o inviare e-mail con il messaggio di registro diff (questo è più comune, in realtà), così che c'è un audit trail.