Perché la ramificazione e la fusione sono più facili in Mercurial che in Subversion?

Question

Gestire più fusioni su rami in Subversion o CVS è solo una di quelle cose che devono essere sperimentate.È estremamente più semplice tenere traccia dei rami e delle fusioni in Mercurial (e probabilmente in qualsiasi altro sistema distribuito) ma non so perché.Qualcun altro lo sa?

La mia domanda nasce dal fatto che con Mercurial puoi adottare una pratica di lavoro simile a quella del repository centrale di Subversions/CVS e tutto funzionerà perfettamente.Puoi eseguire più unioni sullo stesso ramo e non avrai bisogno di infiniti ritagli di carta con numeri di commit e nomi di tag.

So che l'ultima versione di Subversion ha la capacità di tenere traccia delle fusioni con i rami in modo da non avere lo stesso grado di seccatura, ma è stato uno sviluppo enorme e importante da parte loro e ancora non fa tutto ciò che farebbe il team di sviluppo mi piace farlo.

Ci deve essere una differenza fondamentale nel modo in cui tutto funziona.

Answer 1

In Subversion (e CVS), il repository è prima di tutto.In Git e Mercurial non esiste davvero il concetto di repository allo stesso modo;qui i cambiamenti sono il tema centrale.

+1

Il problema con CVS/SVN deriva dal fatto che questi sistemi lo fanno nonricorda la genitorialità dei cambiamenti.In Git e Mercurial, non solo un commit può avere più figli, ma può anche avere più genitori!

Ciò può essere facilmente osservato utilizzando uno degli strumenti grafici, gitk O hg view.Nell'esempio seguente, il ramo n. 2 è stato biforcato dal n. 1 a commit A, e da allora è stato unito una volta (a M, unito al commit b):

o---A---o---B---o---C         (branch #1)
     \       \
      o---o---M---X---?       (branch #2)

Nota come A e B hanno due figli, mentre M ne ha due genitori.Queste relazioni sono registrato nel deposito.Supponiamo che il manutentore della filiale n. 2 ora vuole unire le ultime modifiche dalla filiale n. 1, possono emettere un comando come:

$ git merge branch-1

e lo strumento saprà automaticamente che il file base è b-perché è stato registrato in commit m, un antenato della punta del n. 2-e che deve unire qualunque cosa accadesse tra B e C.CVS non registra queste informazioni, né SVN prima della versione 1.5.In questi sistemi, il grafico sembrerebbe:

o---A---o---B---o---C         (branch #1)
     \    
      o---o---M---X---?       (branch #2)

Dove M è solo un gigantesco commit "schiacciato" di tutto ciò che è accaduto tra A e B, applicato in cima a M.Nota che dopo che l'atto è stato compiuto, c'è Non è rimasta traccia (tranne potenzialmente nei commenti leggibili dall'uomo) di dove M ha avuto origine, né di quanti I commit sono stati crollati insieme-la storia di produzione molto più impenetrabile.

Peggio ancora, eseguire una seconda unione diventa un incubo:Bisogna capire quale fosse la base di unione al momento della prima unione (e una ha A SapereChe c'è stata una fusione in primo luogo!), Quindi presentare tali informazioni allo strumento in modo che non provi a riprodurre A..B in cima a M.Tutto ciò è abbastanza difficile quando si lavora in stretta collaborazione, ma è semplicemente impossibile in un ambiente distribuito.

Un problema (correlato) è che non c'è modo di rispondere alla domanda:"X contiene b?" dove B è una correzione di bug potenzialmente importante.Quindi, perché non solo registrare queste informazioni nel commit, dato che lo è conosciuto al momento della fusione!

P.-S.- Non ho esperienza con le capacità di registrazione di SVN 1.5+, ma il flusso di lavoro sembra essere molto più inventato rispetto ai sistemi distribuiti.Se è davvero così, è probabilmente perché-come menzionato nel commento sopra-l'attenzione è messa sull'organizzazione del repository piuttosto che sui cambiamenti stessi.

Answer 2

Perché Subversion (almeno la versione 1.4 e precedenti) non tiene traccia di ciò che è stato unito.Per Subversion, l'unione è sostanzialmente la stessa di qualsiasi commit mentre su altri controlli di versione come Git, ciò che è stato unito viene ricordato.

Answer 3

Non toccato da nessuna delle risposte già fornite, Hg ha offerto capacità di unione superiori perché utilizza più informazioni durante l'unione delle modifiche (hginit.com):

Ad esempio, se cambio un po 'una funzione, quindi spostala da qualche altra parte, la sovversione non ricorda davvero quei passaggi, quindi quando arriva il momento di unire, potrebbe pensare che una nuova funzione sia appena apparsa all'improvviso blu .Mentre il mercuriale ricorderà quelle cose separatamente:La funzione è cambiata, la funzione mossa, il che significa che se hai anche modificato un po 'quella funzione, è molto più probabile che il mercuriale unirà con successo i nostri cambiamenti.

Naturalmente, anche ricordare cosa è stato unito per ultimo (il punto affrontato dalla maggior parte delle risposte fornite qui) è un'enorme vittoria.

Entrambi i miglioramenti, tuttavia, sono discutibili poiché subversion 1.5+ memorizza ulteriori informazioni di unione sotto forma di proprietà di subversion:tali informazioni sono disponibili, non c'è alcuna ragione ovvia per cui subversion merge non possa implementare l'unione con lo stesso successo di Hg o Git.Non so se è così, però, ma sembra certamente che gli sviluppatori di subversion siano sulla buona strada per aggirare questo problema.

Answer 4

Suppongo che ciò potrebbe in parte essere dovuto al fatto che Subversion ha l'idea di un server centrale insieme a una linea temporale assoluta di revisioni.Mercurial è veramente distribuito e non ha alcun riferimento ad una linea temporale assoluta.Ciò consente ai progetti Mercurial di formare gerarchie più complicate di rami per aggiungere funzionalità e cicli di test per sottoprogetto, tuttavia i team ora devono mantenersi molto più attivamente aggiornati sulle fusioni per rimanere aggiornati poiché non possono semplicemente premere l'aggiornamento e finire con esso .

Answer 5

In Subversion (e CVS), il repository è prima di tutto.In Git e in Mercurial non esiste realmente il concetto di repository allo stesso modo;Qui i cambiamenti sono il tema centrale.

Non ho nemmeno pensato molto a come implementare, ma la mia impressione (basata su un'amara esperienza e su molte letture) è che questa differenza è ciò che rende l'unione e la ramificazione molto più semplice nei sistemi non basati su repository.

Answer 6

Ho esperienza solo con Subversion ma posso dirti che la schermata di unione in TortoiseSVN è terribilmente complicata.Fortunatamente includono un pulsante di prova in modo che tu possa vedere se lo stai facendo bene.La complicazione sta nella configurazione di cosa vuoi unire e dove.Una volta impostata l'unione, l'unione generalmente va bene.Quindi è necessario risolvere tutti i conflitti e quindi eseguire il commit della copia di lavoro unita nel repository.

Se Mercurial può rendere più semplice la configurazione dell'unione, allora posso dire che renderebbe l'unione più semplice del 100% rispetto a Subversion.