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

Sì! Penso che il vantaggio maggiore sia il supporto ramificato + fusione offerto da molti DVCS. Branching and merging è una specie di rompiscatole in SVN; è abbastanza fastidioso che non valga la pena dedicare tempo a creare piccole filiali di breve durata per aggiunte rapide di funzionalità, correzioni di bug o sperimentazione, ma anche la fusione è abbastanza fastidiosa da rendere difficile creare rami a lungo termine. D'altra parte, la ramificazione e la fusione sono un gioco da ragazzi in Git, tanto che creo un ramo (locale) per quasi tutte le correzioni di bug o funzioni su cui lavoro.

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

Anche un DVCS 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, archiviare un repository è solo questione di azzerare il tuo progetto - non c'è un "database centrale" di cui eseguire il backup.

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

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

• Rende facile la replica tra il mio laptop e il desktop ei computer di laboratorio veramente . Anche se questo era vero per SVN ...
• Posso eseguire il commit sul laptop anche quando non ho accesso a Internet.
• I backup sono semplici come git pull .
• Posso usare git citool per 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 applicare una patch a 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 qualunque albero dei sorgenti che sto applicando. (Non puoi farlo facilmente con Subversion perché hai bisogno di un repository separato da qualche altra parte sul tuo disco fisso.)
• Uso le funzionalità di ramificazione facile per controllare le revisioni che ottengo da altre persone. Ad esempio, quando modifico un documento di 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, quindi usa git merge per unire le sue revisioni con qualsiasi cosa abbia fatto nel frattempo.

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

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é cambieresti?".

Ma, sì, anche se non c'è motivo per un cambiamento, trovo che usare DVCS in qualche modo è più semplice dei "vecchi modelli". Quanto segue vale per Mercurial , che uso di più, quindi il tuo chilometraggio può variare a seconda del sistema tu userai.

• veramente facile da usare - ho capito tutti i comandi di cui avevo bisogno in un'ora o giù di lì
• tutto è locale (non è necessario che il server remoto sia online)
• ramificazione / fusione molto semplice - non si pensa nemmeno più a queste cose
• easy cloning (anche, un tipo di branching) - e in generale un'interfaccia molto più user friendly (ho trovato più divertente di git's su windows, anche alcuni concetti sono più semplici, cioè non richiedono il pensiero da parte mia, quindi portando meno a giocherellare con VS e più lavoro svolto)
• funziona bene con svn

Passaggio da un'intro a Mercurial e un blog (bei colori ;-) con suggerimenti utili .