Quando si tratta di unire, ogni versione di controllo ha il motore per farlo. I conflitti sono inevitabili, ma la domanda è: quale controllo di revisione ha la migliore intelligenza artificiale per evitare conflitti.
È possibile misurare tale cosa?
Più in particolare, stiamo pensando di passare a GIT perché ha un bel clamore e voci che gestiscono meglio i conflitti ...
Ogni commento è apprezzato ...
Non penso che questa sia la domanda giusta da porre.
Il problema è che ci sono molti casi d'angolo, e gli algoritmi "intelligenti" per la fusione possono indurre a pensare di aver fatto l'unione correttamente quando in realtà hanno scrozzled completamente il codice. Se sei fortunato, una tale unione errata causa un errore in fase di compilazione. Se sei sfortunato, potrebbe introdurre un bug sottile che richiede anni per rintracciare.
Git usa un algoritmo di fusione abbastanza semplice e alza le mani e chiede aiuto se non riesce a fare l'unione. Secondo me, questo è esattamente quello che vuoi che faccia il tuo sistema di controllo della versione. La quantità di dolore risparmiata da questo valore vale il tempo necessario per risolvere manualmente i conflitti. (Inoltre, se ci sono conflitti in un'unione, git elenca i file in conflitto nel suo messaggio di commit generato automaticamente per te - questa è una cosa molto utile per trovare gli errori quando si esegue la spelunking attraverso la cronologia del codice.)
È stato detto che il miglior algoritmo è Darcs 'algebra delle patch. Codeville ha anche un algoritmo interessante in fase di sviluppo .
Tuttavia, per tutti i motivi pratici, qualsiasi strumento che utilizzi unione a tre vie funzionerà. Ciò include git (con varianti), mercurial, bazaar e molti strumenti esterni (eccezioni degne di nota: opendiff e caleidoscopio su Mac), quindi con buona probabilità si stanno già utilizzando le migliori opzioni; come notato da @Peter, ci sono casi in cui nessun algoritmo può aiutarti.
Si chiama Human Revision Control. (Motore di unione umana)
Usiamo Seapine Surround e per la maggior parte fa un buon lavoro di fusione, ma l'unico modo per risolvere conflitti di unione che il controllo del codice sorgente non può fare è attraverso l'intervento umano.
Quindi, il mio consiglio è:
Prova ad unire rapidamente. Un incubo stava avendo un ramo che non si ricongiungeva alla linea principale per quasi 2 anni. Quando fu unito, molti conflitti dovettero essere risolti. Uno sviluppatore si è guadagnato il soprannome di "merge master" dopo aver passato un bel po 'di tempo a risolvere i problemi di fusione.
Fai attenzione con il codice generato automaticamente dalle procedure guidate ecc. A volte questo può essere un vero problema da unire, specialmente se due rami generano modifiche automatiche sullo stesso file.
Prova a controllare lo sviluppo. Se lo sviluppatore A sta distruggendo i file di codice X e Y, non ha molto senso che lo sviluppatore B lavori su X e Y in un ramo diverso. Parte della gestione delle unioni consiste nel provare e controllare ciò che viene modificato per evitare potenziali conflitti di fusione.
Questo non vuol dire che 2 sviluppatori non possano lavorare sullo stesso file in 2 rami diversi. Se 1 sviluppatore aggiunge il metodo A e un altrometodo B, allora l'unione dovrebbe avvenire senza dolore.
Alla fine ci saranno sempre dei conflitti che richiedono l'intervento umano. Mantenendoli al minimo avrai i migliori risultati di unione.
Il motore di fusione perfetto comprenderà la semantica del file da unire: quindi analizza e comprende il codice sorgente. Devo ancora vedere un tale controllo di motore / versione di fusione ...
La maggior parte degli strumenti di unione unisce i file come testo. Quindi non farei mai affidamento su di loro ciecamente, è sempre una buona idea rivedere le modifiche prima di trasferirle alla tua filiale.
Usiamo Perforce, che non si fonde automaticamente. Ogni volta che il file sorgente cambia rispetto alla base comune, dirà che il file di destinazione deve essere risolto anche se non c'è conflitto. Così apro lo strumento di fusione solo per fare in fretta a pensare agli hunk per verificare se si adattano (e ottenere un'immagine approssimativa di ciò che fanno gli altri peer), più spesso si adattano e accettano il risultato.
Ho anche sottoscritto le notifiche di modifica della linea principale in modo da unire le modifiche al mio ramo il prima possibile in modo da poter evitare problemi in seguito.
Ehm ...
Quando usi mercurial (e git, ne sono ragionevolmente sicuro) scegli il tuo motore di fusione, di default è kdiff3 ma puoi usare qualsiasi cosa tu voglia (oltre il confronto, p4merge ecc.).
AFAIK il motore di fusione e VCS sono spesso completamente separati , un po 'come il tuo compilatore e l'editor di testo. Ad esempio, prendi il codice XML o il codice, vorrà qualcosa di diverso per unirlo, non funzionerà allo stesso modo e quindi non può essere unito nello stesso modo.
Se stai cambiando il controllo di versione perché hai bisogno di un migliore strumento di unione lo stai facendo per i motivi sbagliati, dovresti solo cambiare controllo di versione quando quello che stai utilizzando ora non si adatta bene al tuo processo (o un altro ti permetterebbe di usare un processo migliore).
Conflicts are unavoidable
Il modo in cui un VCS gestisce i conflitti all'interno di un file è nella mia mente un po 'sopravvalutato. Per prima cosa, il modo migliore per affrontare tali conflitti è non averli in primo luogo. Factoring del software bene e dividere i compiti con previdenza riduce notevolmente i conflitti all'interno di un cluster di file (figuriamoci all'interno di un file). Fai un brutto lavoro come lanciare troppe lezioni di Dio o un file di configurazione comune che tutti devono usare e tutti vogliono mettersi a fuoco e stai chiedendo conflitti a livello di file.
Per un altro, tutti usano praticamente lo stesso (pessimo) algoritmo. Un esempio: una versione alfa del nostro progetto ha avuto una piccola perdita di memoria. Era più una flebo piuttosto che una perdita e la perdita si fermava alla fine del tempo di inizializzazione. Degno di una correzione, non degno di una patch. Uno dei nostri clienti ha "risolto" il problema, inserendo la versione gratuita nel posto sbagliato. Il problema è stato risolto nella prossima versione. Questo cliente ha unito la nuova versione piuttosto che una sostituzione completa (WTF?). Non ci sono stati conflitti nella fusione a tre; le chiamate al free erano ben isolate l'una dall'altra. Così ora il software sta perdendo core a causa di un doppio libero.
Ciò che manca nella discussione è quanto sia difficile / dispendioso in termini di tempo / soggetto ad errori di unire il tuo lavoro alla linea principale del software.
In svn, tu
Si tratta di molti passaggi non atomici, troppi luoghi in cui gli errori possono insinuarsi (i conflitti degli alberi sono solo cattivi) e ci vuole troppo tempo. Ho visto più progetti che hanno abbandonato l'uso di rami con sovversione, grazie soprattutto al fatto che il processo di unione è così lungo e soggetto a errori. Ho visto ancora più progetti passare dalla sovversione in gran parte a causa di questo.
Esiste una piccola suite di test chiamata unione-questa che confronta il sistema di controllo di revisione con gli scenari di unione del mondo reale. Per ogni scenario, si assicura che un VCS possa fare correttamente quanto segue:
In base al numero di test superati su unire questo, sembra che ci siano due livelli di prestazioni:
A seconda dei linguaggi di programmazione che stai cercando di unire, i risultati esatti del test potrebbero essere importanti. Visita il sito web del progetto per una tabella comparativa dettagliata.
Ho usato IBM / Rational ClearCase e la sua fusione multi-ramo è semplicemente fantastica. Corre anelli attorno a sovversione. (Nessuna esperienza di Git o mercuriale.)
Leggi altre domande sui tag version-control