Attenzione: da questo post ho trovato Mercurial e lo adoro molto meglio di SVN. Quindi questo post è un po 'obsoleto con i commenti Pro SVN e anti-DVCS generale, ma le cose anti-git sono ancora rilevanti
Sono un fan di SVN su Git.
Perché? Perché SVN è stato molto più semplice per un singolo sviluppatore o un piccolo team e git (in particolare msysgit) mi ha lasciato un cattivo gusto in bocca.
Quando stavo internando in un piccolo negozio, mi è stato presentato Git su Windows. Ho subito notato la quantità di lavoro necessaria per farlo funzionare con Github. Innanzitutto, ho dovuto generare una chiave privata ssh, incollare la chiave pubblica in Github, quindi richiamare lo spettacolo e aprire la mia chiave privata ogni volta che volevo spingere, il che era estremamente fastidioso.
E non mi è mai piaciuto davvero che stavo tirando giù l'intero repository. Devo ammettere che non ho mai lavorato con nulla di enorme, ma avrei paura di scaricare il repository di KDE in Git se l'intero repository e le sue revisioni sono sul mio HD.
Poi c'è stato il processo confuso per effettuare un commit. TMK, ho dovuto prima "mettere in scena" tutti i file che volevo eseguire il commit (il che faceva schifo quando avevi molti file, mi ci è voluto un po 'per trovare il comando manuale per mettere in scena tutto), quindi eseguire il commit, quindi passare al principale repo (perché è un'operazione separata ?!).
Hai anche avuto i dati di commit non (!) Molto utili. Oh guarda, questo è commit 14f74433245ae17aeeaa parte dell'albero 2167a4934d0a4a7db0de e padre d7042abb4821d3faf600. Che diavolo significa? Dovrei essere in grado di capire le cose abbastanza rapidamente e non dovrei consultare una strana documentazione.
A proposito di documentazione, almeno quando la stavo usando, sembrava che tutto fosse in formato linux man file, IE confuso e inutile per me. Raramente ho potuto trovare molto aiuto nei documenti e ho semplicemente fatto ricorso a Google.
E con commit, l'unica cosa che non mi è piaciuta è stata la mancanza di numeri di versione. Ora so che questo è dovuto al design di git, ma qualsiasi software ha bisogno di un numero di versione. Ricordo ancora il commit dei marker che si apriva dicendo "Versione modificata a 1.8.6" o qualcosa di simile, ma non si riusciva ancora a costruire numeri. Per me avere la versione 1.8.6.5164 (l'ultima parte è il numero di revisione) mi dice molto di più della semplice 1.8.6 e una nota che dice che qualcosa di secondario è cambiato, provalo
Essendo specifico per il software, il programma di base su Windows è msysgit, che è un'interfaccia terribile. Mi ha bloccato alcune volte, aveva un'interfaccia orribile e l'integrazione CLI-GUI era al massimo incerta. I drogati della riga di comando intorno a me odiavano ancora di più la gui.
Ora diamo un'occhiata a SVN. E dal momento che sono su Windows e ho un account Google, in particolare TortoiseSVN e Google Code.
Per prima cosa, completa l'integrazione della shell per fare tutto sul repository (e per te gente Linux, RabbitVCS fa la stessa cosa), non è necessaria alcuna GUI principale. Ottenere un repository è facile come un checkout, non è necessario SSH (non ricordo se Github ha richiesto SSH per i pull) e nessun repository completo + tutto il passato si impegna sul tuo HD.
Impegnarsi è estremamente facile, principalmente perché non sono richiesti SSH o stadiazione. Devi semplicemente controllare tutti i file che desideri utilizzando l'utilissima opzione seleziona tutto che nella mia versione di msysgit non era disponibile, digita un messaggio di commit e premi commit. Google Code ti chiede quindi le tue informazioni di accesso (che la maggior parte dei clienti memorizza) e il tuo lavoro. Semplice, facile e senza SSH
Numeri di versione? Con un po 'di codice semplice, puoi aggiungere un numero di versione e un numero di commit a tutti i checkout, il che rende le cose molto più facili. Ottieni anche numeri di versione utilizzabili che mostrano effettivamente una modifica, ad esempio 1.8.6.5165 è più recente di 1.8.6.5164.
Documentazione? Beh, è difficile da dire. La tartaruga è documentata, ma non ho fatto riferimento alla documentazione ufficiale da così tanto tempo che non posso giudicare. Leggere una semplice guida introduttiva è stato abbastanza per me.
La fusione è qualcos'altro che non posso confrontare. Ho dovuto farlo una volta in Git quando qualcun altro ha commesso una modifica a un file su cui stavo lavorando, ma mai in SVN.
Quale consiglierei? Bene in grandi gruppi, git ha i suoi vantaggi, principalmente nel suo ciclo di sviluppo non lineare. In un altro progetto ho visto 4 programmatori iniziare in rami separati, quindi unire tutto il codice in modi molto strani che in qualche modo si sono trasformati nel ramo master finale. Github e msysgit avevano uno strumento di visualizzazione davvero carino per l'intero progetto che mi piaceva molto.
Per i progetti di singoli sviluppatori o piccoli team, SVN sarebbe la migliore in quanto la maggior parte delle funzionalità di Gits non vengono utilizzate e si ottengono solo parti negative. La semplicità è una cosa così bella
