Cerco di comprendere i vantaggi del sistema di controllo della versione distribuita (DVCS).

Ho trovato molto utile la rieducazione di Subversion e questo articolo di Martin Fowler .

Mercurial e altri DVCS promuovono un nuovo modo di lavorare sul codice con changeset e commit locali. Impedisce di fondere l'inferno e altri problemi di collaborazione

Non ne siamo interessati poiché pratico l' integrazione continua e lavorare da soli in un ramo privato non è un'opzione, a meno che non stiamo sperimentando. Usiamo un ramo per ogni versione principale, in cui correggiamo i bug uniti dal trunk.

Mercurial ti consente di avere tenenti

Capisco che questo possa essere utile per progetti molto grandi come Linux, ma non vedo il valore in team piccoli e altamente collaborativi (da 5 a 7 persone).

Mercurial è più veloce, occupa meno spazio su disco e la copia locale completa consente operazioni più veloci di registro e diff.

Nemmeno questo mi preoccupa, dato che non ho notato problemi di velocità o spazio con SVN anche con progetti molto grandi su cui sto lavorando.

Sto cercando le tue esperienze personali e / o opinioni da ex geek SVN. Soprattutto per quanto riguarda il concetto di changeset e l' aumento delle prestazioni generali che hai misurato.

AGGIORNAMENTO (12 gennaio) : ora sono convinto che valga la pena provare.

AGGIORNAMENTO (12 giugno) : ho baciato Mercurial e mi è piaciuto. Il gusto del suo locale ciliegio si impegna. Ho baciato Mercurial solo per provarlo. Spero che al mio server SVN non dispiaccia. Sembrava così sbagliato. Sembrava così giusto. Non voglio dire che sono innamorato stasera .

AGGIORNAMENTO FINALE (29 luglio) : Ho avuto il privilegio di rivedere il prossimo libro di Eric Sink chiamato Version Control by Example . Ha finito per convincermi. Vado per Mercurial.

Nota: consultare "MODIFICA" per la risposta alla domanda corrente

Prima di tutto, leggi la rieducazione di Subversion di Joel Spolsky. Penso che la maggior parte delle tue domande avranno una risposta lì.

Un'altra raccomandazione, il discorso di Linus Torvalds su Git: http://www.youtube.com/watch?v=4XpnKHJAok8 . Quest'altro potrebbe anche rispondere alla maggior parte delle tue domande ed è piuttosto divertente.

A proposito, qualcosa che trovo abbastanza divertente: persino Brian Fitzpatrick e Ben Collins-Sussman, due dei creatori originali di sovversione hanno detto in un discorso di Google "mi dispiace" riferendosi alla sovversione che è inferiore al mercuriale (e ai DVCS in generale).

Ora, IMO e in generale, le dinamiche di gruppo si sviluppano in modo più naturale con qualsiasi DVCS e un vantaggio eccezionale è che puoi impegnarti offline perché implica le seguenti cose:

• Non dipendi da un server e una connessione, il che significa tempi più rapidi.
• Non essere schiavo di luoghi in cui è possibile ottenere l'accesso a Internet (o una VPN) solo per essere in grado di impegnarsi.
• Ognuno ha un backup di tutto (file, cronologia), non solo del server. Ciò significa che chiunque può diventare il server .
• Puoi impegnarti compulsivamente, se necessario, senza fare confusione con il codice degli altri . Gli commit sono locali. Non ti calpesti le dita dei piedi mentre commetti. Non rompere le build o gli ambienti degli altri semplicemente impegnandosi.
• Le persone senza "accesso di commit" possono eseguire il commit (poiché il commit in un DVCS non implica il caricamento di codice), abbassando la barriera per i contributi, puoi decidere di eseguire le modifiche o meno come integratore.
• Può rafforzare la comunicazione naturale poiché un DVCS lo rende essenziale ... nella sovversione ciò che hai invece sono razze commesse, che forzano la comunicazione, ma ostacolando il tuo lavoro.
• I collaboratori possono unirsi e gestire la propria fusione, il che significa alla fine meno lavoro per gli integratori.
• I contributori possono avere i loro rami senza influenzare quelli degli altri (ma essere in grado di condividerli se necessario).

Sui tuoi punti:

• La fusione dell'inferno non esiste in DVCSland; non ha bisogno di essere gestito. Vedi il prossimo punto .
• Nei DVCS, ognuno rappresenta un "ramo", il che significa che ci sono fusioni ogni volta che vengono apportate modifiche. I rami nominati sono un'altra cosa.
• Se lo desideri, puoi continuare a utilizzare l'integrazione continua. Non è necessario l'IMHO, perché aggiungere complessità? Basta continuare i test come parte della propria cultura / politica.
• Mercurial è più veloce in alcune cose, git è più veloce in altre cose. Non proprio ai DVCS in generale, ma alle loro particolari implementazioni AFAIK.
• Tutti avranno sempre il progetto completo, non solo tu. La cosa distribuita ha a che fare con il fatto che puoi impegnarti / aggiornare localmente, la condivisione / presa dall'esterno del tuo computer si chiama push / pull.
• Ancora una volta, leggi la rieducazione di Subversion. I DVCS sono più facili e più naturali, ma sono diversi, non provare a pensare che cvs / svn === sia la base di tutto il controllo delle versioni.

Stavo contribuendo con un po 'di documentazione al progetto Joomla per aiutare a predicare una migrazione ai DVCS, e qui ho realizzato alcuni diagrammi per illustrare centralizzato vs distribuito.

centralizzata

Distribuito in medicina generale

Distribuito al massimo

Vedi nel diagramma c'è ancora un "repository centralizzato", e questo è uno degli argomenti preferiti dai fan della versione centralizzata: "sei ancora centralizzato", e no, non lo sei, dal momento che il repository "centralizzato" è solo un repository tutti concordano (ad es. un repository github ufficiale), ma questo può cambiare in qualsiasi momento.

Ora, questo è il tipico flusso di lavoro per progetti open source (ad es. Un progetto con una massiccia collaborazione) che utilizzano DVCS:

Bitbucket.org è in qualche modo un equivalente github per mercurial, sappi che hanno repository privati ​​illimitati con spazio illimitato, se la tua squadra è più piccola di cinque puoi usarlo gratuitamente.

Il modo migliore per convincerti di usare un DVCS è provare un DVCS, ogni sviluppatore DVCS esperto che ha usato svn / cvs ti dirà che ne vale la pena e che non sanno come sono sopravvissuti per tutto il loro tempo senza di esso.

EDIT : Per rispondere alla tua seconda modifica, posso solo ribadire che con un DVCS hai un flusso di lavoro diverso, ti consiglio di non cercare motivi per non provarlo a causa delle migliori pratiche , è come quando le persone sostengono che OOP non lo è necessario perché possono aggirare complessi schemi di progettazione con ciò che fanno sempre con il paradigma XYZ; puoi beneficiare comunque.

Provalo, vedrai come lavorare in "una filiale privata" è in realtà un'opzione migliore. Uno dei motivi per cui posso dire perché l'ultimo è vero è perché perdi la paura di impegnarti , permettendoti di impegnarti in ogni momento che ritieni opportuno e lavorare in modo più naturale.

Riguardo a "fondere l'inferno", dici "a meno che non stiamo sperimentando", io dico "anche se stai sperimentando + mantenendo + lavorando contemporaneamente nella v2.0 rinnovata ". Come dicevo prima, la fusione dell'inferno non esiste perché:

• Ogni volta che ti impegni generi una filiale senza nome e ogni volta che i tuoi cambiamenti incontrano i cambiamenti di altre persone, si verifica una fusione naturale.
• Poiché i DVCS raccolgono più metadati per ogni commit, si verificano meno conflitti durante l'unione ... quindi potresti persino chiamarlo "unione intelligente".
• Quando ti imbatti in conflitti di unione, questo è ciò che puoi usare:

Inoltre, le dimensioni del progetto non contano, quando sono passato dalla sovversione in realtà stavo già vedendo i vantaggi mentre lavoravo da solo, tutto sembrava giusto. I changeset (non esattamente una revisione, ma un insieme specifico di modifiche per file specifici che includi un commit, isolato dallo stato della base di codice) ti consentono di visualizzare esattamente cosa intendevi facendo quello che stavi facendo a un gruppo specifico di file, non l'intera base di codice.

Per quanto riguarda il funzionamento dei changeset e l'incremento delle prestazioni. Proverò a illustrarlo con un esempio che mi piace fare: il passaggio al progetto mootools da svn è illustrato nel loro grafico di rete github .

Prima

Dopo

Quello che vedi è che gli sviluppatori sono in grado di concentrarsi sul proprio lavoro mentre commettono, senza il timore di infrangere il codice degli altri, si preoccupano di rompere il codice degli altri dopo aver premuto / tirato (DVCS: prima commetti, poi premi / tira, quindi aggiorna ) ma poiché la fusione qui è più intelligente, spesso non lo fanno mai ... anche quando c'è un conflitto di unione (che è raro), passi solo 5 minuti o meno a risolverlo.

La mia raccomandazione è di cercare qualcuno che sappia usare mercurial / git e di dirgli di spiegarglielo direttamente. Trascorrendo circa mezz'ora con alcuni amici nella riga di comando mentre usavamo mercurial con i nostri desktop e account bitbucket che mostravano loro come unirsi, persino fabbricando conflitti per loro per vedere come risolvere in un ridicolo ammontare di tempo, sono stato in grado di mostrare loro il vero potere di un DVCS.

Infine, ti consiglio di usare mercurial + bitbucket invece di git + github se lavori con Windows. Mercurial è anche un po 'più semplice, ma git è più potente per una gestione dei repository più complessa (ad esempio git rebase ).

Alcune letture consigliate aggiuntive:

• Sistemi di controllo di revisione distribuiti: Git vs. Mercurial vs. SVN
• Git vs. Mercurial: per favore, rilassati
• Distributed Version Control & Git [Part 1] & Distributed Version Control & Git [Part 2]
• Git / Mercurial vs. Subversion: Fight!
• Smackdown DVCS vs Subversion, round 3
• Perché mi piace Mercurial More Than Git ( parte 1 , parte 2 )
• Contribuire con Git: ridurre gli attriti della collaborazione Open Source con Git VCS
• "Come hanno funzionato i DVCS finora per te?" - pubblica un post su Joomla! Mailing list di Framework Development che richiede feedback dopo l'adozione sperimentale di mercurial e git per Joomla! Progetto di piattaforma
• Branching DVCS (con Mercurial) - Un'introduzione dettagliata e orientata all'esempio di come si presenta il branching in un DVCS, che è forse la caratteristica più importante in questi sistemi

Quello che stai dicendo è tra l'altro che se rimani essenzialmente su un singolo ramo, non hai bisogno del controllo della versione distribuita.

Questo è vero, ma non è una limitazione inutilmente forte al tuo modo di lavorare e uno che non si adatta bene a più posizioni in più fusi orari? Dove dovrebbe trovarsi il server centrale di sovversione e tutti dovrebbero tornare a casa se quel server per qualche motivo non funziona?

I DVCS sono Subversion, ciò che Bittorrent è ftp

(tecnicamente, non legalmente). Forse se ci pensi sopra, potresti capire perché è un grande balzo in avanti?

Per me, il nostro passaggio a git, è risultato immediatamente

• I nostri backup sono più facili da eseguire (basta "git remote update" e il gioco è fatto)
• È più facile eseguire piccoli passaggi quando si lavora senza accesso al repository centrale. Devi solo lavorare e sincronizzarti quando torni alla rete che ospita il repository centrale.
• Build Hudson più veloci. Molto, molto più veloce da usare git pull rispetto all'aggiornamento.

Quindi, considera perché bittorrent è meglio di ftp e riconsidera la tua posizione :)

Nota: è stato menzionato che ci sono casi d'uso in cui ftp è più veloce e bittorrent. Ciò è vero allo stesso modo in cui il file di backup gestito dall'editor preferito è più rapido da utilizzare rispetto a un sistema di controllo versione.

La caratteristica killer dei sistemi di controllo della versione distribuita è la parte distribuita. Non si esegue il checkout di una "copia di lavoro" dal repository, si clona un'intera copia del repository. Questo è enorme, in quanto offre potenti vantaggi:

• Puoi goderti i vantaggi del controllo della versione, anche quando non hai accesso a Internet come ... Questo è purtroppo abusato e sovrascritto come motivo per cui DVCS è fantastico --- non è solo un punto di forza come molti di ci troviamo a scrivere codice senza accesso a Internet ogni volta che inizia a piovere rane.

• La vera ragione per cui un repository locale è killer è che hai il controllo totale sulla cronologia del commit prima che venga trasferita al repository principale .

Mai corretto un bug e ho finito con qualcosa del tipo:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

E così via. La storia del genere è disordinata --- c'era davvero solo una correzione, ma ora l'implementazione è distribuita tra molti commit che contengono artefatti indesiderati come l'aggiunta e la rimozione di istruzioni di debug. Con un sistema come SVN, l'alternativa è di non eseguire il commit (!!!) fino a quando tutto funziona per mantenere pulita la cronologia. Anche allora, gli errori scivolano via e la Legge di Murphy è in attesa di brutalizzarti quando quantità significative di lavoro non sono protette dal controllo della versione.

Avere un clone locale del repository, di cui sei proprietario , risolve questo problema in quanto puoi riscrivere la cronologia eseguendo continuamente il "fix it" e "oops" si impegna nel commit "bug fix". Alla fine della giornata, un commit pulito viene inviato al repository principale che assomiglia a:

r321 Fixed annoying bug.

Qual è il modo in cui dovrebbe essere.

La capacità di riscrivere la storia è ancora più potente se combinata con il modello di ramificazione. Uno sviluppatore può fare un lavoro completamente isolato all'interno di un ramo e quindi quando è il momento di portare quel ramo nel trunk hai una serie di opzioni interessanti:

• Fai una semplice fusione di vaniglia . Porta tutto in verruche e tutto.

• Fai un rebase . Ti consente di ordinare la cronologia delle filiali, riorganizzare l'ordine dei commit, eliminare i commit, unire i commit insieme, riscrivere i messaggi di commit --- persino modificare i commit o aggiungerne di nuovi! Un sistema di controllo di versione distribuito ha un profondo supporto per la revisione del codice.

Una volta appreso come i repository locali mi permettessero di modificare la mia storia per motivi di sanità mentale dei miei colleghi programmatori e del mio sé futuro, ho appeso per sempre SVN. Il mio client Subversion è ora git svn.

Consentire a sviluppatori e manager di esercitare il controllo editoriale sui risultati della cronologia del commit in una migliore cronologia del progetto e avere una cronologia pulita con cui lavorare aiuta davvero la mia produttività come programmatore. Se tutto questo parlare di "riscrittura della storia" ti spaventa, non preoccuparti perché questo è ciò che serve per i repository centrali, pubblici o principali. La storia può (e dovrebbe!) Essere riscritta fino al punto in cui qualcuno la porta in un ramo in un deposito da cui altre persone stanno attingendo. A quel punto la storia dovrebbe essere trattata come se fosse scolpita su una tavoletta di pietra.

la risposta di dukofgamings è probabilmente la migliore possibile, ma voglio affrontarla da un'altra direzione.

Supponiamo che ciò che dici sia assolutamente vero e che applicando le buone pratiche puoi evitare i problemi che DVCS è stato progettato per risolvere. Questo significa che un DVCS non ti offrirebbe alcun vantaggio? La gente puzza di seguire le migliori pratiche. La gente sta andando a rovinare. Quindi perché dovresti evitare il software progettato per risolvere una serie di problemi, scegliendo invece di affidarti alle persone per fare qualcosa che puoi prevedere in anticipo che non faranno?

Sì, fa male quando devi unire grandi commit in sovversione. Ma questa è anche un'ottima esperienza di apprendimento, che ti fa fare tutto il possibile per evitare la fusione di conflitti. In altre parole, impari a fare il check-in spesso . L'integrazione precoce è un'ottima cosa per qualsiasi progetto condiviso. Fintanto che lo fanno tutti, l'uso della sovversione non dovrebbe essere un grosso problema.

Git, ad esempio, è stato progettato per il lavoro distribuito e incoraggia le persone a lavorare sui propri progetti e creare le proprie forcelle per una (eventuale) fusione in un secondo momento. E 'stato non specificamente progettato per l'integrazione continua in un "piccolo e altamente collaborativi squadre", che è ciò che il PO sta chiedendo. È piuttosto il contrario, vieni a pensarci. Non avrai alcuna utilità per le sue fantasiose funzioni distribuite se tutto ciò che stai facendo è seduto nella stessa stanza, lavorando insieme sullo stesso codice.

Quindi, per un team co-localizzato che utilizza CI, non penso davvero che importi molto se usi un sistema distribuito o meno. Si riduce a una questione di gusto ed esperienza.

Perché dovresti sfidare continuamente le tue conoscenze. Sei appassionato di sovversione, e posso capire perché l'ho usato per molti anni, e ne sono stato molto contento, ma ciò non significa che sia ancora lo strumento più adatto a te.

Credo che quando ho iniziato a usarlo, era la scelta migliore al momento. Ma altri strumenti escono nel tempo, e ora preferisco git, anche per i miei progetti di tempo libero.

E sovversione ha alcune carenze. Ad esempio, se si rinomina una directory su disco, questa non viene rinominata nel repository. Lo spostamento dei file non è supportato, facendo spostare un file un'operazione di copia / eliminazione, apportando modifiche quando i file sono stati spostati / rinominati difficili. E il monitoraggio delle fusioni non è realmente integrato nel sistema, ma implementato sotto forma di soluzione alternativa.

Git risolve questi problemi (incluso il rilevamento automatico se un file è stato spostato, non è nemmeno necessario dirlo che è un dato di fatto).

D'altra parte, git non ti consente di diramare su singoli livelli di directory come fa sovversione.

Quindi la mia risposta è che dovresti indagare sulle alternative, vedere se si adatta meglio alle tue esigenze rispetto a ciò che conosci, e quindi decidere.

Per quanto riguarda le prestazioni, Git o qualsiasi altro DVCS ha un grande vantaggio rispetto a SVN quando si deve passare da un ramo all'altro o passare da una revisione all'altra. Poiché tutto è archiviato localmente, le cose sono molto più veloci rispetto a SVN.

Questo da solo potrebbe farmi cambiare!

Invece, basandosi sull'idea che "applicando le migliori pratiche non è necessario un DVCS", perché non considerare che il flusso di lavoro SVN è un flusso di lavoro, con un insieme di migliori pratiche e il flusso di lavoro GIT / Hg è un flusso di lavoro diverso, con una serie diversa di migliori pratiche.

git bisect (e tutte le sue implicazioni sul tuo repository principale)

In Git, un principio molto importante è che puoi trovare bug usando git bisect. Per fare questo, prendi l'ultima versione che hai eseguito che era noto funzionare, e la prima versione che hai eseguito che era noto per fallire, ed esegui (con l'aiuto di Git) una ricerca binaria per capire quale commit ha causato il bug. Per fare ciò, l'intera cronologia delle revisioni deve essere relativamente libera da altri bug che possono interferire con la ricerca dei bug (che ci crediate o no, in realtà funziona abbastanza bene nella pratica e gli sviluppatori del kernel Linux lo fanno sempre).

Per raggiungere la git bisectcapacità, sviluppi una nuova funzionalità nel suo ramo di funzionalità , la riformuli e ripulisci la cronologia (quindi non hai revisioni non funzionanti conosciute nella tua cronologia - solo un mucchio di modifiche che ciascuna ti porta a metà strada per risolvere il problema) e, una volta terminata la funzionalità, la si unisce al ramo principale con la cronologia di lavoro.

Inoltre, per far funzionare tutto questo, devi avere una disciplina su quale versione del ramo principale inizi la tua funzione. Non puoi semplicemente iniziare dallo stato corrente del masterramo perché potrebbe avere bug non correlati - quindi il consiglio nella comunità del kernel è di iniziare a lavorare dall'ultima versione stabile del kernel (per grandi funzionalità), o di iniziare a lavorare dall'ultimo candidato alla versione con tag.

Puoi anche eseguire il backup dei tuoi progressi intermedi spingendo nel frattempo il ramo della funzione su un server e puoi spingere il ramo della funzione su un server per condividerlo con qualcun altro ed ottenere un feedback, prima che la funzione sia completa, prima che tu debba trasforma il codice in una caratteristica permanente del codebase che tutti * nel tuo progetto devono affrontare.

La pagina man di gitworkflows è una buona introduzione ai flussi di lavoro per cui Git è progettato. Anche perché Git è migliore di X discute i flussi di lavoro di git.

Grandi progetti distribuiti

Perché abbiamo bisogno di luogotenenti in un team altamente collaborativo con buone pratiche e buone abitudini di progettazione?

Perché in progetti come Linux, ci sono così tante persone coinvolte che sono così geograficamente distribuite che è difficile collaborare come un piccolo team che condivide una sala conferenze. (Sospetto che per lo sviluppo di un prodotto di grandi dimensioni come Microsoft Windows, anche se le persone si trovano tutte nello stesso edificio, il team è troppo grande per mantenere il livello di collaborazione che fa funzionare un VCS centralizzato senza sostituti.)

Perché non usarli in tandem? Nel mio attuale progetto siamo costretti a usare CVS. Tuttavia, manteniamo anche repository git locali per lo sviluppo delle funzionalità. Questo è il migliore di entrambi i mondi perché puoi provare varie soluzioni e mantenere le versioni di ciò su cui stai lavorando, sulla tua macchina. Ciò consente di ripristinare le versioni precedenti della funzionalità o provare diversi approcci senza problemi quando si incasina il codice. Avere un repository centrale ti offre quindi i vantaggi di avere un repository centralizzato.

Non ho esperienza personale con DVCS, ma da ciò che raccolgo dalle risposte qui e da alcuni documenti collegati, la differenza fondamentale tra DVCS e CVCS è il modello di lavoro utilizzato

DVCS

Il modello funzionante di DVCS è che stai facendo uno sviluppo isolato . Stai sviluppando la tua nuova funzionalità / correzione di bug in isolamento da tutte le altre modifiche fino al momento in cui decidi di rilasciarla al resto del team. Fino a quel momento, puoi fare qualsiasi check-in che ti piace, perché nessun altro ne sarà disturbato.

CVCS

Il modello di lavoro di CVCS (in particolare Subversion) è che stai facendo uno sviluppo collaborativo . Stai sviluppando la tua nuova funzionalità / correzione di bug in collaborazione diretta con tutti gli altri membri del team e tutte le modifiche sono immediatamente disponibili per tutti.

Altre differenze

Altre differenze tra svne git/ hg, come le revisioni contro i changeset sono secondarie. È molto ben possibile creare un DVCS basato su revisioni (come hanno Subversion) o un CVCS basato su changeset (come hanno Git / Mercurial).

Non consiglierò alcun particolare strumento, perché dipende principalmente dal modello di lavoro con cui tu (e il tuo team) siete più a vostro agio.
Personalmente, non ho problemi a lavorare con un CVCS.

• Non ho paura di fare il check-in, poiché non ho problemi a portarlo in uno stato incompleto, ma compilabile.
• Quando ho sperimentato il merge-hell, era in situazioni in cui si sarebbe verificato in entrambi svne git/ hg. Ad esempio, V2 di alcuni software veniva gestito da un team diverso, utilizzando un VCS diverso, mentre sviluppavamo V3. Occasionalmente, le correzioni di bug dovrebbero essere importate dal VCS V2 al VCS V3, il che in pratica significava fare un check-in molto ampio sul VCS V3 (con tutti i bugfix in un singolo changeset). So che non era l'ideale, ma è stata una decisione di gestione utilizzare diversi sistemi VCS.