Hmm, essendo stato un manager, ho subito due reazioni "istintive" a questo:

• Se non hai già dei buoni motivi per cui stai dando voce a qualcuno che non sia alla moda?
• Allo stesso modo, in che modo Subversion non funziona in modo tale da richiedere una sostituzione?

Non sono, in realtà, negativo - penso che ci sia probabilmente un caso da fare (dipende dalle circostanze) ma se il caso è semplicemente che git è "migliore" della sovversione, allora non ne hai davvero uno .

Devi anche essere in grado di enumerare gli svantaggi: hai già identificato il sovraccarico della migrazione e dei re-tooling - che altro è un problema? per esempio. Che cosa succede al tuo bel repository centrale, di riserva? Come ti integrerai con il tuo server di integrazione continua (se non ne hai uno, dimentica git e vai a ordinarlo per primo). Oh sicurezza e tracciabilità - SVN viene eseguito con login e permessi corretti.

A mio parere, i vantaggi sono nella flessibilità, nella fusione migliore, nella capacità di eseguire commit locali senza rompere la build e così via. Gli svantaggi sono nella mancanza di controllo e nella stessa flessibilità.

Può darsi che tutto ciò che si vuole fare sia eseguire git localmente sul proprio computer come client "migliore" di subversion (sto cercando di farlo usando mercurial).

Hmm, forse tutta questa risposta è davvero un commento? Devi rendere il tuo caso qui (nella domanda) per git su sovversione (nel tuo ambiente) per vedere se possiamo aiutarti a identificare il business case.

FWIW, so che si può facilmente designare un'istanza specifica del repository come trunk / fonte di riferimento e inoltre che è così che si collegano i fili nel proprio server di build - la differenza è che con DVCS è più di un decisione amministrativa rispetto a qualcosa inerente all'architettura.

Direi che la ramificazione e fusione rapida e indolore consentirebbe agli sviluppatori di essere più produttivi con il loro codice, poiché ogni nuova funzionalità potrebbe essere ramificata, quindi incorporata in seguito. Il processo di sviluppo procede molto più agevolmente. Inoltre, la natura distribuita, consentirebbe a ogni sviluppatore di avere un'intera copia del codice, quindi non ci si deve preoccupare di un errore del server centralizzato che stacchi tutto il codice. Probabilmente ci sono più motivi, questi due, tuttavia, sono i miei principali motivi per usare Git.

Suppongo che tu possa creare un caso per il controllo della versione aumentando la produttività (e quindi il profitto) anche quando uno sviluppatore sta lavorando da solo.

Un buon DVCS riconosce gli stessi vantaggi in termini di produttività anche quando si lavora come parte di un team - ogni sviluppatore può ottenere tutti i vantaggi di lavorare con il controllo della versione - può fare frequenti commit, rollback, giocare con le cose, ecc. preoccuparsi dei conflitti con ciò che gli altri sviluppatori stanno facendo fino a quando non sono pronti a spingere le proprie modifiche.

• Branch-per-bug
• Latenza ridotta sulle tue differenze.
• Essere in grado molto di navigare rapidamente in modo arbitrario attraverso la cronologia di un ramo durante la revisione da parte dei colleghi.
• Hai ancora accesso alla tua intera cronologia quando non hai accesso al server centralizzato: non sei in ufficio, il potere è appena uscito ma la batteria del tuo portatile continua a funzionare, ...

Queste cose ti permettono di lavorare in modo più efficiente, sia da solo che in gruppo. Lavoro più efficiente = tempo di sviluppo più veloce = time-to-market più rapido = profitto.

Perdonami per il collegamento al mio blog, ma ho scritto articoli su questo argomento:

• Perché il suggerimento dovrebbe sempre essere compilato
• Perché DVCS offre un controllo centrale migliore
• Perché la ramificazione è migliore con DVCS
• Perché i modelli di branching distribuiti possono non funziona bene sul tuo CVC .

Sentiti libero di votare a meno se non li trovi pertinenti.

In breve, DVCS semplifica i modelli di ramificazione che possono impedire a grandi gruppi di sviluppatori di pestarsi l'un l'altro, il che aumenta sia la produttività sia la qualità giornaliera della build. La parte di collaborazione disordinata del controllo della versione può essere eseguita nei repository locali, lasciando il repository centrale più pulito e di maggiore qualità. Inoltre, le decisioni relative a quando succedere possono avere un grande impatto sull'efficienza, ad esempio se un reparto è pronto per iniziare a lavorare su 2.0 quando 1.0 viene ancora ripulito da altri. DVCS consente di prendere tali decisioni a livello locale invece che da un comitato.

I miei argomenti per DVCS sono questi:

• La ramificazione non è interrotta, il che porta a una minore frizione nello sviluppo di funzionalità e alla manomissione dei prodotti esistenti. L'attrito costa denaro in tempo.

• Il passaggio a un sistema moderno attrae meglio gli sviluppatori all'avanguardia, che porteranno a una cultura di prodotti migliori, che consente all'azienda di vendere più prodotti.

• I commit non di rete sono più veloci , consentendo agli sviluppatori di impegnarsi spesso, portando a un'analisi e un rilevamento dei bug a grana fine.

Essenzialmente, si tratta di ridurre l'attrito. C'è un termine per questo: Muda . Più attrito, più dolore è fare le cose. Più dolore, meno guadagni, meno profitti.

Mi scuso se sono grato, ma consentitemi di mettere il caso aziendale in termini incerti:

SVN rende le vite degli infelici degli sviluppatori. E questo rende un business del software infelice.

... in modi che molti non si renderanno conto fino a quando non inizieranno a utilizzare un DVCS. Questo è il caso aziendale più importante che può essere fatto . Perché? Beh, rispetto al costo di trovare e mantenere buoni sviluppatori, il costo di passare a un DVCS è quasi inesistente .

Considera quanto segue:

• Tutti tranne le operazioni più banali in SVN (e nella maggior parte degli altri CVC) richiedono l'accesso alla rete. Nella maggior parte dei DVC, l'accesso alla rete si verifica solo quando si esegue un'operazione push o pull . Ciò significa che i comandi non banali sono lenti . Cosa fai quando un comando sta prendendo per sempre? Io personalmente vado a sfogliare notizie di programmers.se o di hacker mentre sto aspettando. In poche parole, DVCSes consente ai programmatori di concentrarsi sul fare ciò che amano: scrivere il software della società .
• SVN ha il supporto per la ramificazione più o meno allo stesso modo in cui le prigioni hanno il supporto per far cadere il sapone sotto la doccia: puoi farlo, ma quando lo fai ti incasini. Pertanto, SVN costringe i tuoi sviluppatori a combattere costantemente l'uno sull'altro per apportare modifiche .
• Quando SVN non funziona, è inattivo. Diventa estremamente difficile per gli sviluppatori fare il proprio lavoro se possono farlo affatto. Pertanto, SVN costringe i tuoi sviluppatori a fare affidamento sulla tua infrastruttura che è al 100% priva di errori .
• In questi giorni, git sta rapidamente guadagnando mindshare mentre SVN lo sta rapidamente perdendo. Se non ci sono benefici nell'uso di DVCS su SVN, perché la comunità di programmazione sta cambiando più velocemente possibile?

A cosa ammonta tutto questo? Devo ancora incontrare uno sviluppatore che abbia dato a DVCS una prova onesta che preferirebbe SVN in seguito. Se potessi fare una dichiarazione più noiosa e sfacciata, SVN è un "male necessario" che gli sviluppatori si costringono a usare. Git è uno strumento che rende gli sviluppatori più produttivi e più felici .

(Dovrei sottolineare che le affermazioni in grassetto sono quelle particolari su cui dovresti concentrarti. Il resto di loro fornisce solo il contesto.)

L'unica cosa che posso pensare è che git funziona senza una connessione di rete. Tutto il resto è spesso difficile da vendere agli utenti tecnici che usano la sub-versione o la perforazione per un po 'di tempo.

La differenza mostra quando c'è un problema

Siamo passati a git 6 mesi fa dopo aver trasferito il nostro repository decennale.

Finora ho trovato quanto segue, dopo un po 'di sperimentazione:

• la ramificazione e la fusione sono quasi indolori. Questo rende molto più facile lavorare su funzionalità e correzioni di bug separate senza pestare le dita degli altri. Inoltre rende molto semplice applicare una determinata correzione anche altrove.

• più robusto di progettazione - non ti puoi fidare del 100% su un server centrale disponibile, e se non lo sei puoi usare promuovere clone temporaneamente come sostituzione a caldo. Ciò rimuove un punto cruciale di insuccesso: se il server SVN si arresta per qualsiasi motivo, nessuno può eseguire il lavoro SVN. Se il repository git centrale si ferma per qualsiasi motivo, è ancora possibile lavorare e spingere / tirare localmente per garantire che i commit vengano replicati. Puoi persino avere più repository fuori sede esattamente per questo scopo.

L'interazione tra repository

• è semplificata. Per CVS hai essenzialmente bisogno di accedere continuamente ogni volta che hai bisogno di qualche informazione. Per git l'intero repository è disponibile localmente e consente molte cose per andare più velocemente.

Quindi, il vantaggio non è tanto nella routine quotidiana, ma è molto chiaro nel momento in cui qualcosa non funziona correttamente!

Quindi, suggerisco che per il tuo caso aziendale, guarda cosa farai quando il disastro colpisce ...

La facilità di ramificazione e fusione è la ragione più concreta, ma per convincere qualcuno dovrai dare loro un esempio concreto di come questo migliori le cose.

Supponiamo che alcuni programmatori stiano lavorando su miglioramenti delle prestazioni per un'app e che siano nella fase sperimentale e non sappiano se il codice che stanno scrivendo sarà mai parte del ramo master / trunk. Tuttavia, hanno bisogno di condividere frequentemente codice tra loro e provare idee che potrebbero essere vicoli ciechi. Come gestisci una ramificazione così frequente e la fusione in sovversione? La risposta breve è che non lo fai. Con un dvcs è davvero facile, e i programmatori possono provare rapidamente nuove idee nei rami e condividerle con gli altri prima di decidere se questa idea resterà attiva.

Il business case per l'ammaraggio di SubVersion è che il supporto alla ramificazione è una barriera alla stabilizzazione e manutenzione del prodotto. Se è necessario rilasciare un prodotto e quindi continuare lo sviluppo, è necessario un ramo. Con subversion, gli sviluppatori non useranno la branching in modo corretto, quindi non riuscirai a mantenere lo sviluppo sul tunk, e assicurati che le correzioni di bug effettivamente lo facciano sia sul trunk che sul ramo.