Ho cercato e non ho trovato alcun motivo commerciale per cui i sistemi git / mercurial / bazzr siano migliori dei sistemi centralizzati (sovversione, perforce).

Se stessi cercando di vendere un DVCS a una persona non tecnica, quali argomenti forniresti per aumentare il profitto del DVCS .

Presto lancerò git al mio manager, ci vorrà del tempo per convertire i repository di sovversione e alcune spese per l'acquisto di licenze smartgit.

Modifica Ho cercato di trasformare questa domanda in una discussione generica su centralizzata e decentralizzata, ma inevitabilmente si è trasformata in git vs sovversione. Sicuramente esistono sistemi centralizzati migliori della sovversione.

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

• Se non hai già buone ragioni per cui stai lanciando git oltre a essere alla moda?
• Allo stesso modo, in che modo Subversion non funziona in modo tale da richiedere una sostituzione?

In realtà non sono negativo - penso che probabilmente ci sia 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 l'overhead della migrazione e del re-tooling - cos'altro è un problema? ad es. Cosa succede al tuo bel repository di backup centrale? Come ti integri con il tuo server di build a integrazione continua (se non ne hai uno, dimentica git e vai prima a quello). Oh sicurezza e tracciamento - SVN funziona con login e autorizzazioni adeguati.

A mio avviso, i vantaggi sono la flessibilità, una migliore fusione, la capacità di eseguire impegni locali senza interrompere la creazione e così via. Gli svantaggi sono la mancanza di controllo e la stessa flessibilità.

Può darsi che tutto ciò che vuoi fare sia eseguire git localmente sul tuo computer come un client di sovversione "migliore" (sto cercando di farlo usando mercurial).

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

FWIW, so che si può facilmente designare un'istanza specifica del repository come sorgente trunk / riferimento e inoltre è così che si collega al proprio server di build - la differenza è che con DVCS è più una decisione amministrativa che qualcosa di inerente all'architettura.

Direi che la ramificazione e l'unione rapida e indolore consentirebbe agli sviluppatori di essere più produttivi con il loro codice, poiché ogni nuova funzionalità potrebbe essere ramificata, quindi successivamente unita. Rendere il processo di sviluppo più fluido. Inoltre, la natura distribuita consentirebbe a ogni sviluppatore di disporre di un'intera copia del codice, quindi non c'è motivo di preoccuparsi che un errore centralizzato del server comprenda tutto il codice. Probabilmente ci sono più ragioni, quelle due, tuttavia, sono le mie ragioni principali per usare Git.

Suppongo che tu possa fare una richiesta per il controllo della versione aumentando la produttività (e quindi il profitto) anche quando uno sviluppatore lavora da solo.

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

• Branch-per-bug
• Latenza ridotta sulle differenze.
• Essere in grado di navigare molto rapidamente in modo arbitrario attraverso la cronologia di un ramo durante la revisione tra pari.
• Hai ancora accesso a tutta la tua storia quando non hai accesso al server centralizzato: non sei in ufficio, l'alimentazione è appena uscita ma la batteria del tuo laptop funziona ancora, ...

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

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

• Perché il suggerimento deve essere sempre compilato
• Perché DVCS offre un migliore controllo centrale
• Perché la ramificazione è migliore con DVCS
• Perché i modelli di diramazione distribuita potrebbero non funzionare bene sul CVCS .

Sentiti libero di votare se non li ritieni pertinenti.

In breve, DVCS semplifica i modelli di diramazione che possono impedire a grandi gruppi di sviluppatori di calpestarsi l'un l'altro, aumentando sia la produttività che la qualità di costruzione quotidiana. La parte disordinata della collaborazione del controllo della versione può essere eseguita nei repository locali, lasciando il repository centrale più pulito e di qualità superiore. Inoltre, le decisioni su quando diramare possono avere un grande effetto sull'efficienza, ad esempio se un dipartimento è pronto per iniziare a lavorare su 2.0 quando 1.0 viene ancora ripulito da altri. DVCS consente che tali decisioni vengano prese a livello locale anziché dal comitato.

Le mie argomentazioni per DVCS sono queste:

• La ramificazione non è interrotta, il che porta a un minore attrito nello sviluppo di funzionalità e nel mantenimento delle patch dei prodotti esistenti. L'attrito costa denaro nel tempo.

• Passare a un sistema moderno attira meglio 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 accurati dei bug.

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

Mi scuso se sono eccezionale, ma mi permetto di mettere il caso aziendale in termini incerti:

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

... in modi che molti non capiranno fino a quando non inizieranno a usare un DVCS. Questo è il caso aziendale più importante che può essere fatto . Perché? Bene, rispetto al costo di ricerca e mantenimento di buoni sviluppatori, il costo del passaggio a un DVCS è quasi inesistente .

Considera quanto segue:

• Tutte le operazioni tranne quelle banali in SVN (e la maggior parte degli altri CVCS) richiedono l'accesso alla rete. Nella maggior parte dei DVCS, l'accesso alla rete avviene solo quando si esegue un'operazione pusho pull. Ciò significa che i comandi non banali sono lenti . Cosa fai quando un comando prende per sempre? Vado personalmente a consultare programmers.se o le notizie sugli hacker mentre aspetto. In poche parole, i DVCS consentono ai programmatori di concentrarsi sul fare ciò che amano: scrivere il software dell'azienda .
• SVN ha il supporto per la ramificazione più o meno allo stesso modo in cui le carceri hanno il supporto per far cadere il sapone sotto la doccia: puoi farlo, ma quando lo fai ti fai scopare. Pertanto, SVN obbliga i tuoi sviluppatori a lottare costantemente l'uno contro l'altro per apportare modifiche .
• Quando SVN è inattivo, è inattivo. Diventa terribilmente difficile per gli sviluppatori svolgere il proprio lavoro se possono farlo. Pertanto, SVN obbliga i tuoi sviluppatori a fare affidamento sul fatto che l'infrastruttura sia al 100% priva di bug .
• In questi giorni, Git sta rapidamente guadagnando la condivisione della mente mentre SVN lo sta rapidamente perdendo. Se non ci sono vantaggi nell'uso di DVCS su SVN, perché la comunità di programmatori sta cambiando il più velocemente possibile?

A cosa ammonta tutto questo? Devo ancora incontrare uno sviluppatore che ha dato un DVCS un tentativo onesto che preferirebbe SVN in seguito. Se potessi fare un'affermazione più noiosa e audace, SVN è un "male necessario" che gli sviluppatori si costringono a usare. Git è uno strumento che rende gli sviluppatori più produttivi e più felici .

(Devo sottolineare che le affermazioni in grassetto sono quelle particolari su cui dovresti concentrarti. Il resto fornisce solo un contesto.)

L'unica cosa che mi viene in mente è che git funziona senza una connessione di rete. Tutto il resto è spesso difficile da vendere agli utenti tecnici che usano la sovversione o la perforce per un po 'di tempo.

La differenza mostra quando ci sono problemi

Siamo passati a git 6 mesi fa dopo il porting del nostro repository vecchio di dieci anni.

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

• ramificarsi e fondersi è quasi indolore. Ciò rende molto più semplice lavorare su funzioni separate e correzioni di bug senza calpestare le dita dei piedi. Inoltre, rende molto semplice applicare un determinato bugfix anche da qualche altra parte.

• più robusto in termini di progettazione: non si fa affidamento al 100% sulla disponibilità di un server centrale e, in caso contrario, è possibile utilizzare la promozione temporanea di qualsiasi clone come sostituzione a caldo. Ciò elimina un punto cruciale di errore: se il server SVN si arresta per qualsiasi motivo, nessuno può svolgere il lavoro SVN. Se il repository git centrale non funziona per qualsiasi motivo, puoi comunque lavorare e spingere / tirare localmente per assicurarti che i commit siano replicati. Puoi anche avere più repository fuori sede proprio per questo scopo.

• l'interazione con il repository è semplificata. Per CVS avevi essenzialmente bisogno di accedere in qualsiasi momento ogni volta che avevi bisogno di alcune informazioni. Per git l'intero repository è disponibile localmente, consentendo a molte cose di andare più veloce.

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 si verifica un disastro ...

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

Supponiamo che alcuni programmatori stiano lavorando per migliorare le prestazioni di un'app, e sono in fase sperimentale e non sanno se il codice che stanno scrivendo farà mai parte del ramo master / trunk. Tuttavia, devono condividere frequentemente il codice tra loro e provare idee che potrebbero essere vicoli ciechi. Come gestite ramificazioni e fusioni così sovversive così frequenti? La risposta breve è che non lo fai. Con un dvcs è davvero facile e i programmatori possono rapidamente provare nuove idee nei rami e condividerle con gli altri prima di decidere se quell'idea rimarrà.

Il business case per abbandonare SubVersion è il supporto delle ramificazioni che ostacola la stabilizzazione e la manutenzione del prodotto. Se è necessario rilasciare un prodotto e continuare lo sviluppo, è necessario un ramo. Con la sovversione, gli sviluppatori non useranno correttamente la ramificazione, quindi non riuscirai a mantenere lo sviluppo sul tunk e assicurerai che le correzioni dei bug si realizzino anche sul trunk e sul branch.