Ci sono vantaggi nell'usare un DVCS per uno sviluppatore solista?

In questo momento, uso visual svn sul mio server e ho ankhsvn / tortoise sulla mia macchina personale. Funziona abbastanza bene e non devo cambiare, ma se riesco a vedere alcuni vantaggi dell'utilizzo di un DVCS, allora potrei provarlo.

Tuttavia, se non ha senso o differenza usarlo senza altre persone, non mi preoccuperò.

Quindi, chiedo, ci sono dei vantaggi nell'usare un DVCS quando sei l'unico sviluppatore?

Sì! Penso che il più grande vantaggio sia il migliore supporto di branching + fusione offerto da molti DVCS. Ramificarsi e fondersi è una specie di dolore nel culo in SVN; è abbastanza fastidioso che non valga la pena di creare piccoli rami di breve durata per aggiunte rapide di funzionalità, correzioni di bug o sperimentazione, ma la fusione è anche abbastanza fastidioso da creare anche rami di lunga durata. D'altra parte, ramificare e fondere è un gioco da ragazzi in Git, tanto che creo un ramo (locale) per quasi tutte le correzioni di bug o funzionalità su cui lavoro.

Penso che gli strumenti offerti da Git per visualizzare repository, log di grepping, ecc., Siano molto meglio che in SVN (anche se è più una cosa di Git che specifica di un DVCS).

Un DVCS inoltre non richiede un server centrale; quando si utilizza SVN come sviluppatore, è necessario creare un repository locale da inserire, che non è un requisito con Git, poiché ogni repository contiene la cronologia completa. Come corollario, l'archiviazione di un repository è solo una questione di zippare il progetto: non esiste un "database centrale" per il backup.

Ho iniziato a usare Git quasi quattro anni fa, dopo aver usato SVN per un po ', e non ho guardato indietro.

Uso un DVCS molto per le mie cose personali. (Sono uno di quei ragazzi che a $ HOME in git .) Ci sono diversi vantaggi:

• Rende davvero semplice la replica tra il mio laptop e desktop e computer di laboratorio . Anche se questo era vero anche per SVN ...
• Posso impegnarmi sul laptop anche quando non ho accesso a Internet.
• I backup sono semplici come a git pull.
• Posso utilizzare git citoolper suddividere molte modifiche in commit di dimensioni logiche, anche se ho apportato molte modifiche non correlate prima di decidere di eseguire il commit. Non sono a conoscenza di uno strumento per farlo in Subversion.
• Quando devo patchare un progetto open source, è più facile mantenere le cose organizzate creando un nuovo repository git nella directory del progetto piuttosto che creare una seconda copia di qualsiasi albero dei sorgenti che sto patch. (Non puoi farlo facilmente con Subversion perché hai bisogno di un repository separato da qualche altra parte sul tuo hard disk.)
• Uso le semplici funzioni di diramazione per controllare le revisioni ottenute da altre persone. Ad esempio, quando modifico un documento della conferenza con il mio consulente, anche se non ha accesso al repository, posso inviargli una copia del documento e controllare le sue revisioni in un ramo in base alla versione che ho inviato lui, e poi usa git mergeper unire le sue revisioni con qualsiasi cosa che abbia fatto nel frattempo.

Git mi ha abituato a pensare a tutti i miei cambiamenti in blocchi logici, molto più di quanto Subversion abbia mai fatto.

Mia madre spegne il modem quando è troppo tardi per dormire. DVCS mi consente di continuare a lavorare con VCS dopo che il modem è spento.

Bene, la risposta predefinita sarebbe "Se (qualunque cosa tu stia usando ora) funziona per te, perché dovresti cambiare?".

Ma sì, anche se non c'è motivo di cambiare, trovo che usare DVCS sia un po 'più semplice dei "vecchi modelli". Quanto segue vale per Mercurial , che uso di più, quindi il tuo chilometraggio può variare, a seconda del sistema che intendi utilizzare.

• davvero facile da usare - ho capito tutti i comandi di cui ho bisogno in circa un'ora
• tutto è locale (non è necessario che il server remoto sia online)
• diramazione / fusione molto facili: non ci pensi più nemmeno a queste cose
• clonazione semplice (anche, un tipo di ramificazione) - e in generale un'interfaccia molto più user friendly (l'ho trovata più divertente di quella di git su windows; anche alcuni concetti sono più semplici; cioè non è necessario pensare dalla mia parte, portando quindi a meno complicazioni con VS e più lavoro svolto)
• funziona bene con svn

Porta di salto verso un'introduzione a Mercurial e un blog (bei colori ;-) con consigli utili .