Sono un fanatico di Subversion, perché dovrei considerare o meno Mercurial o Git o qualsiasi altro DVCS?


300

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.


8
Sono anche molto interessato a questo. Subversion si adatta al modo in cui mi è stato insegnato a pensare al controllo della versione (proveniente da CVS e simili). Tuttavia, mentre ho dovuto usare Mercurial e Git per provare alcune correzioni di bug per progetti open source, non sono ancora stato convertito.
Berin Loritsch,

29
+1 per la domanda. Oggi è diventato un cult del carico che la distribuzione è semplicemente migliore, più veloce, più semplice, più naturale e senza problemi e più brillante del 90% rispetto a quella centralizzata. Solo che necessariamente non lo è. Sono strumenti diversi e ognuno può avere vantaggi in alcuni contesti e svantaggi in altri contesti.
Joonas Pulakka,

17
@Sharpie: Avendo utilizzato sia svn, gite hgper anni, sono abbastanza ben consapevoli dei loro pro e contro. Sebbene gitsia sicuramente il più potente di questi, è importante riconoscere che più potente non implica automaticamente meglio . Emacs è sicuramente più potente di qualsiasi editor di testo javascript in esecuzione nel browser web, ma, stranamente, sto scrivendo questo commento in un editor di testo del browser javascript in questo momento! La semplicità , anche la stupidità, ha valore in molti contesti. L'uso centralizzato svne qualcosa di simile a git-svnlivello locale offre il meglio di entrambi i mondi.
Joonas Pulakka,

9
@Sharpie: fa bene che ti piaccia. Ma il pro di un uomo è il truffatore di un altro uomo. Alcune persone considerano la chiarezza di un singolo repository centralizzato con un singolo tronco canonico incredibilmente prezioso. Ecco una presentazione di come Google conserva il codice sorgente di tutti i suoi progetti, oltre 2000, in un unico trunk di codice contenente centinaia di milioni di righe di codice, con oltre 5000 sviluppatori che accedono allo stesso repository. Preferiresti 5000 server e la storia di 2000 progetti sulla scrivania di tutti? -)
Joonas Pulakka,

21
-1 per il riferimento di Katy Perry. ;)
Amadiere

Risposte:


331

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

testo alternativo

Distribuito in medicina generale

testo alternativo

Distribuito al massimo

testo alternativo

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:

testo alternativo

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:

testo alternativo

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

testo alternativo

Dopo

testo alternativo

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:


18
Ottima risposta, ma solo una domanda per quelli di noi nella stessa barca di OP: puoi spiegare come non esiste la fusione dell'inferno? Un integratore o un collaboratore non devono svolgere le stesse azioni quando il loro fork è scaduto?
Nicole,

17
Buona risposta. Solo una nota a margine: mentre Spolsky può avere alcuni punti interessanti, tieni presente che sta anche cercando di vendere un prodotto usando quei punti come materiale di vendita, il che li rende un po 'di parte.
Martin Wickman,

5
Ho letto quella pagina di rieducazione e non l'ho trovata pertinente per molte ragioni. Modificherò la mia domanda con la mia visione personale sull'argomento.

15
Vale anche la pena sottolineare che Git può agire come client Subversion, il che significa che non è necessario convertire tutti in Git contemporaneamente; alcuni membri del team possono semplicemente usare Git se lo desiderano e il loro flusso di lavoro individuale migliora (in particolare perché l'unione è molto più semplice).
Greyfade

6
@Pierre, i DVCS si occupano di unire le modifiche del software dai singoli programmatori, ma non di far effettivamente compilare il software o superare i test unitari esistenti. Hai ancora bisogno di altro software per farlo ogni volta che cambia la fonte, e la scommessa migliore che abbiamo in questi giorni è usare un motore CI (e farlo correttamente)

59

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.


Ho quasi deciso di provarlo con un vero progetto.

Buona idea. Ricordati di approfondirlo con la mentalità di "Mi piace davvero questo!" invece di "Non voglio farlo!". C'è molto da imparare. Se scegli git, github ha un ottimo aiuto online. Se scegli hg, Joel ha scritto del buon materiale online. Se scegli bzr, Canonical ha molto probabilmente molto materiale online valido. Altri?

3
Hmm che presume che tu pensi che bittorrent sia meglio di FTP ...
Murph

2
@Murph, lo so, e anche Blizzard (su chi credo che possiamo essere d'accordo sa come gestire la sincronizzazione online di massa?). wowwiki.com/Blizzard_Downloader

2
@Murph, si avvia un server torrent sul server e un client torrent sul client. Non difficile. Dovresti immediatamente comprarti che solo i file che sono stati modificati devono essere aggiornati. Inoltre, hai considerato quale rsync invece di ftp potrebbe acquistarti per aggiornamenti incrementali?

46

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.


6
Riscrivere la storia: è solo una cosa di Git? O è facile anche in Mercurial? (Se lo è, ho davvero bisogno di iniziare a farlo.)
Paul D. Waite,

3
Bisogna essere consapevoli della disciplina del kernel Linux quando si fa questo - vale a dire, non rifare mai (o riscrivere la storia) un ramo che hai pubblicato pubblicamente. Se hai rami che sono pubblici per un uso a breve termine (per unirli in rami che vengono gettati via frequentemente come Linux-Next, o per qualcuno da rivedere e quindi buttare via le loro copie locali), allora puoi ribattere quei rami - ma il tuo gli altri utenti dovrebbero essere chiari sul fatto che la convenzione per quella filiale è che può essere riformulata e non dovrebbe essere unita nelle filiali a lungo termine di altre persone.
Ken Bloom,

4
potresti benissimo avere accesso a Internet senza avere accesso completo alla rete interna. Mi capita spesso di viaggiare.

5
Non richiedere l'accesso a Internet è un grosso problema, perché è da lì che viene la velocità del DVCS. Non appena devi inviare pacchetti su una rete, stai rallentando il processo di un ordine di grandezza o giù di lì, indipendentemente da quanto sia buona la tua connessione.
Adam Lassek, il

6
@Paul, capisco che in Mercurial può essere fatto, ma non è la funzionalità o la filosofia di base.
Benjol

18

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?


2
In realtà proporrei questo argomento contro DCVS. Di recente la mia azienda è passata a Mercurial da CVS. Le persone stanno cancellando i cambiamenti di altre persone durante le fusioni molto più spesso quando sono in CVS.
Juozas Kontvainis,

@JuozasKontvainis: Non conosco molto bene mercurial, ma in git puoi impedire push che includono fusioni che non hanno HEAD come genitore, il che impedisce agli utenti di spingere modifiche che non hanno le modifiche più recenti da master incluse. Sono sicuro che c'è qualcosa di simile in Mercurial.
naught101

@ naught101: in realtà, la mia azienda ha quell'impostazione abilitata. Quello che succede è che il programmatore commette i suoi cambiamenti localmente, quindi prova a spingere. Riceve una risposta dal server che deve unire prima di poter eseguire il push. Riceve aggiornamenti dal server e tenta di eseguire un commit di unione. A questo punto non so esattamente come quelle persone abbiano effettuato un commit di merge ma in diverse occasioni che uniscono il commit fondamentalmente hanno cancellato le modifiche che hanno ricevuto dal server.
Juozas Kontvainis,

1
Sembra che le persone abbiano apportato le modifiche, quindi abbiano effettivamente eliminato le modifiche apportate dal server durante l'unione (che è possibile). Naturalmente, il changeset dal server è ancora lì, quindi è possibile ripristinare il repository allo stato in cui si trovava prima delle loro modifiche.
philosodad,

1
in realtà, suona così: randyfay.com/content/avoiding-git-disasters-gory-story articolo carino e non critico su cosa può andare storto con un repository git se non sai cosa stai facendo.
gbjbaanb,

9

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.


2
Git è stato progettato per il lavoro distribuito in tutto il mondo e incoraggia le persone a lavorare sui propri progetti e creare le proprie forcelle. E 'stato non specificamente progettato per l'integrazione continua in "piccole e altamente collaborativi squadre", che è ciò che il PO sta chiedendo.
Martin Wickman,

4
Indovina un po ', ottieni conflitti più piccoli / più facili da risolvere. Ma se due persone stanno cambiando le stesse parti del codice, hai un problema di pianificazione nel tuo team e questo non può essere risolto da nessun VCS. Distribuito o no.
Martin Wickman,

4
L'OP fa parte di un team co-ubicato che utilizza CI. Ciò significa che effettuano spesso piccoli check-in (più volte al giorno). Detto questo, non vedo alcun motivo per cui l'uso di un dvcs dovrebbe dare qualche vantaggio particolare e non vedo alcun motivo per cui si dovrebbero verificare enormi fusioni e quindi nessun inferno di fusione. Non consiglierei svn per un team distribuito, ma non è questo il caso.
Martin Wickman,

2
@MartinWickman - Mercurial è stato progettato per impegnarsi, ramificarsi e fondersi in modo rapido ed economico. Sembra perfetto per l'integrazione continua. Personalmente, penso che avere la possibilità per Alice di ramificare le sue modifiche e suggerire che Bob le tira e unisca le sue modifiche su quella succursale per verificare la presenza di problemi - tutto senza toccare il server centrale o spingere le modifiche ovunque - sembra un ottimo modo per far lavorare team piccoli e altamente collaborativi.
Philosodad,

2
I miei $ 0,02. Ho usato Subversion, Mercurial e Git ora per vari progetti. Subversion sembra davvero essere la scelta migliore per un gruppo strettamente integrato che fa l'integrazione continua. Mercurial è la soluzione migliore per i gruppi che potrebbero eseguire una sola build al giorno con molte più modifiche al codice ogni volta (ciò creerebbe problemi di unione in SVN). Git sembra la strada da percorrere per le persone che hanno squadre che possono andare giorni / settimane senza realmente mettere insieme il codice per creare una build.
Brian Knoblauch,

8

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.


In verità, sperimentare alternative dovrebbe essere automatico.

git usa una certa euristica per determinare se un file è stato spostato, è buono ma non perfetto.
gbjbaanb,

Concordo con questo, anche se odi il nuovo strumento che i dannati bambini usano, penso che sia importante forzarti a provare almeno cose nuove, specialmente se queste cose stanno facendo ondate enormi.
Tjaart

7

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!


D'accordo, il checkout git è estremamente veloce.

+1 per
dirlo

3

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.)


Non capisco il tuo primo punto. Hai dei riferimenti? Per quanto riguarda l'ultimo, dividerei invece il progetto in componenti separati. Non ho mai lavorato su un progetto così grande, il numero massimo di sviluppatori che ho ottenuto nello stesso progetto è di due dozzine.

@Pierre. È certamente ragionevole dividere il progetto in componenti separati. Poiché Linux è un kernel monolitico, ciò significa (essenzialmente) che tutti i driver di dispositivo devono essere sviluppati nello stesso repository, anche se ognuno di essi è essenzialmente un progetto separato. Allo stesso tempo, vogliono che l'agilità per i loro architetti più esperti apporti cambiamenti ad ampio raggio che tocchino tutti questi driver, quindi dividerli in diversi repository sarà una seccatura. Quindi git (e i tenenti) si adattano bene a loro per gestire queste diverse preoccupazioni.
Ken Bloom,

Potresti anche essere interessato a leggere ciò che Martin Fowler ha da dire sui flussi di lavoro SVN contro Git e Mercurial. martinfowler.com/bliki/VersionControlTools.html
Ken Bloom

2
Faccio regolarmente bisection su SVN per trovare bug. L'unica differenza con Git è che non è tutto automatico. Ma questo da solo non ci basterebbe per cambiare.
Xavier Nodet,

1
La rilevanza di git bisect per le piccole squadre è quasi nulla. Lo capisco per il kernel in cui centinaia di modifiche da persone diverse vengono unite in una sola volta e stanno rompendo le cose, ma quando hai una squadra di 5, di solito puoi eliminare tutte tranne 2-3 potenziali patch colpevoli con una rapida occhiata al log.
Blucz,

2

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.


Ma puoi semplicemente creare un repository centrale con un DVCS (e puoi controllare le autorizzazioni esattamente come con un CVCS. Quindi quali sono i vantaggi?
nought101

Vero, ma i repository git centrali potrebbero essere difficili da configurare se ci si trova in un ambiente Windows. Immagino che sia praticamente l'unico a cui potrei pensare. Siamo stati costretti a utilizzare CVS a livello aziendale, quindi non avevamo molta scelta.
Vadim,

1

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.

Non penso che lo sviluppo isolato sia in realtà il modello funzionante del DVCS. Una caratteristica importante di un DVCS è che gli altri membri del team possono eseguire le modifiche locali o clonare il repository locale. Ti impegni quando vuoi, le tue modifiche sono sempre disponibili e i tuoi bug non possono causare il caos di massa.
Philosodad,

@philosodad: se altri estraggono il codice dal mio repository senza conoscere lo stato di quel codice, può comunque causare il caos. L'unica differenza è nella responsabilità di chi è. E il mio codice non è sempre disponibile. Ciò dipende ancora se i miei sistemi sono configurati per l'accesso esterno.
Bart van Ingen Schenau,

Se le persone estraggono il codice dal proprio repository e lo uniscono con il proprio, possono eseguire il rollback, in modo indipendente, senza problemi di massa . In secondo luogo, se prendi la decisione di rifiutare l'accesso alla tua base di codice e paralizzare una delle principali funzionalità del sistema, puoi forzare l' isolamento su te stesso. È molto diverso da un sistema modellato per lo sviluppo isolato. DVCS no. La tua comprensione del modello di lavoro di DVCS è semplicemente sbagliata.
Philosodad,

1
@philosodad: Penso che sto iniziando a capirlo sempre meglio: tutti possono ottenere il tuo pasticcio, come in un CVCS, ma non è più colpa tua, perché non l'hai spinto su di loro. :-)
Bart van Ingen Schenau,

Beh ... una specie di. Ma in genere, Alice clonerebbe o ramificherebbe prima e quindi unire le modifiche, il che rende più semplice fingere di non aver mai visto il tuo codice buggy in primo luogo!
Philosodad,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.