¿Qué control de revisión tiene el mejor motor de fusión? [cerrado]

8

Cuando se trata de fusionar, cada versión de control tiene su motor para hacerlo. Los conflictos son inevitables, pero la pregunta es: qué control de revisión tiene la mejor IA para evitar conflictos.

¿Es posible medir tal cosa?

Más específicamente, estamos pensando en pasar a GIT porque tiene una buena publicidad y rumores que manejan mejor los conflictos ...

Cualquier comentario es apreciado ...

version-control

— confiq
fuente

10

En última instancia, ningún VCS puede manejar bien las "combinaciones cercanas" sin hacer algo de otro mundo. Si una persona agrega lógica en una rutina que va en una dirección, y otra persona hace algo similar, pero completamente diferente, los humanos tienen que involucrarse.

— Peter Rowell

1

En teoría, los algoritmos de fusión podrían ser muy buenos si realmente compilaran el código fuente. Parece un poco por ahí, pero probablemente sea solo cuestión de tiempo.

— Karl Bielefeldt

1

@Karl: ¿eh? compilar qué código fuente: si cambio una línea para decir x = 1 y mi colega cambia la misma línea para decir x = 2, ¿cómo determinará el compilador cuál es 'correcta' dado el resto de las confirmaciones fusionadas?

— gbjbaanb

1

@gbj, nunca podrás evitar la intervención humana por completo, como demuestra tu ejemplo. Sin embargo, compilar el código fuente podría combinar más fácilmente cosas como el cambio de nombre de variables o métodos, o hacer un cambio de dos maneras funcionalmente idénticas pero textualmente diferentes.

— Karl Bielefeldt

Las pruebas no pudieron resolver algunos de los factores "humanos". Los humanos saben lo que están tratando de producir, por lo que el conflicto podría resolverse compilando y ejecutando pruebas. Las pruebas unitarias deben ser lo suficientemente pequeñas como para que un par de actualizaciones al mismo método sean factibles en unos pocos pasos, si la prueba es exitosa en ambos sentidos, los humanos deben participar, si el sistema de fusión determina que hay demasiadas variaciones que la compilación no es manejable, los humanos deberán participar.

— Quaternion

21

No creo que esta sea la pregunta correcta.

El problema es que hay muchos casos de esquina, y los algoritmos "inteligentes" para la fusión pueden engañarse a sí mismos y pensar que han hecho la fusión correctamente cuando de hecho han borrado completamente su código. Si tienes suerte, una fusión tan mala provoca un fallo en tiempo de compilación. Si no tienes suerte, puede introducir un error sutil que lleva años rastrear.

Git usa un algoritmo de fusión bastante sencillo y levanta las manos y pide ayuda si no puede hacer la fusión. En mi opinión, esto es exactamente lo que quieres que haga tu sistema de control de versiones. Vale la pena el tiempo que le lleva solucionar los conflictos manualmente. (Además, si hay conflictos en una fusión, git enumera los archivos en conflicto en su mensaje de confirmación autogenerado para usted; esto es muy útil para encontrar errores cuando revisa su historial de código).

— ebneter
fuente

6

Se ha dicho que el mejor algoritmo es el álgebra de parches de Darcs . Codeville también tiene un algoritmo interesante en desarrollo.
Sin embargo, por todas las razones prácticas, cualquier herramienta que utilice la combinación de tres vías funcionará . Esto incluye git (con variantes), mercurial, bazar y muchas herramientas externas (excepciones notables: opendiff y caleidoscopio en Mac), por lo que es muy probable que ya esté utilizando las mejores opciones; Como señaló @Peter, hay casos en los que ningún algoritmo puede ayudarlo.

— Agos
fuente

44

No hay diferencias sutiles entre los algoritmos de fusión de 3 vías, tales como los que se elige ancestro común, y en la calidad de las 2 vías diferenciaciones que utilizan en la adecuación de las líneas, pero tienes razón en que los casos en que se hace una diferencia práctica son relativamente raros

— Karl Bielefeldt

TMK Mercurial no tiene una verdadera combinación de 3 vías, tienes que hacer 2 combinaciones de dos vías

— TheLQ

@TheLQ los documentos dicen lo contrario: mercurial.selenic.com/wiki/MergeProgram pero son un poco escasos en los detalles

— Agos

@TheLQ: existe una gran diferencia entre una diferencia de tres vías y una fusión de tres vías . Una diferencia de tres vías son dos archivos que se fusionarán más un ancestro común, donde el ancestro común le permite ver cómo las dos fuentes han divergido. Una combinación de tres vías necesitaría una diferencia de cuatro vías , tres archivos divergentes más su antepasado común.

— Mark Booth

3

Uso git y mercurial pero tu pregunta recuerda la teoría del parche de darcs. Tendrás tarea de lectura para este fin de semana.

PD: No me pidas la teoría de los parches, es muy complejo para mí :)

— Rufo El Magufo
fuente

Cosas interesantes, tenga en cuenta que SVN se fusiona mediante la aplicación de parches, pero un algoritmo de parche completo que aplica tanto la letra r como la m a la misma palabra no le dará el resultado correcto: aún necesita intervención humana en este caso.

— gbjbaanb

3

Se llama Control de Revisión Humana. (Motor de fusión humana)

Utilizamos Seapine Surround y, en su mayor parte, hace un buen trabajo de fusión, pero la única forma de solucionar los conflictos de fusión que el control de fuente no puede hacer es a través de la intervención humana.

Entonces, mi consejo es:

Intenta fusionarte rápidamente. Una pesadilla fue tener una sucursal que no se unió a la línea principal durante casi 2 años. Cuando se fusionó, muchos conflictos debían resolverse. Un desarrollador se ganó el apodo de "maestro de fusión" después de pasar mucho tiempo arreglando problemas de fusión.

Tenga cuidado con el código generado automáticamente por los asistentes, etc. En algún momento, esto puede ser un verdadero problema para combinar, especialmente si dos ramas generan cambios automáticamente en el mismo archivo.

Intenta controlar el desarrollo. Si el desarrollador A está desgarrando los archivos de código X e Y, no tiene mucho sentido que el desarrollador B trabaje en X e Y en una rama diferente. Parte de la gestión de fusión es intentar controlar lo que se está modificando para evitar posibles conflictos de fusión.

Esto no quiere decir que 2 desarrolladores no puedan trabajar en el mismo archivo en 2 ramas diferentes. Si 1 desarrollador agrega el método A y otro agrega el método B, entonces la fusión debería ocurrir sin problemas.

Al final siempre habrá algunos conflictos que necesitarán intervención humana. Al mantenerlos al mínimo, obtendrá los mejores resultados de fusión.

— Jon Raynor
fuente

2

En mi humilde opinión, los archivos generados automáticamente no deberían estar en el control de versiones. Solo los archivos que se utilizan para generarlos.

— Calmarius

2

El motor de fusión perfecto comprendería la semántica del archivo que se está fusionando: por lo tanto, analiza y comprende el código fuente. Todavía tengo que ver ese motor de fusión / control de versiones ...

La mayoría de las herramientas de fusión combinan archivos como texto. Por lo tanto, nunca confiaría en ellos a ciegas, siempre es una buena idea revisar los cambios antes de enviarlos a su sucursal.

Estamos utilizando Perforce, que no se fusiona automáticamente. Siempre que el archivo de origen cambie en relación con la base común, dirá que el archivo de destino debe resolverse incluso si no hay conflicto. Así que abro la herramienta de combinación solo para pensar rápidamente en los trozos para verificar si encajan (y obtener una idea aproximada de lo que están haciendo otros compañeros), la mayoría de las veces encajarán y aceptarán el resultado.

También me suscribí a las notificaciones de cambio de la línea principal, así que combino los cambios en mi sucursal lo antes posible para poder evitar problemas más adelante.

— Calmarius
fuente

1

Erm ...

Cuando usas mercurial (y git también, estoy razonablemente seguro) eliges tu motor de fusión, por defecto es kdiff3 pero puedes usar lo que quieras (más allá de comparar, p4merge, etc.).

AFAIK, el motor de fusión y VCS a menudo están completamente separados , algo así como su compilador y editor de texto. Tome el código XML vs, por ejemplo, va a querer fusionar diferentes cosas, no funcionan de la misma manera y, por lo tanto, no se pueden fusionar de la misma manera.

Si está cambiando el control de versión porque necesita una mejor herramienta de combinación, lo está haciendo por razones equivocadas, solo debe cambiar el control de versión cuando el que está usando ahora no se ajusta bien a su proceso (u otro lo haría). Permitirle utilizar un mejor proceso).

— Ed James
fuente

1

Cada VCS tiene un algoritmo de fusión incorporado que utiliza: las herramientas de fusión a las que se refiere solo se usan cuando hay conflictos que el motor interno no puede resolver. La pregunta que se hace es qué algoritmo de fusión de VCS es el "mejor", aunque no estoy seguro de que sea una pregunta bien definida. Algunas personas lo definen como "produce la menor cantidad de conflictos que necesitan resolución"; Yo diría, da la menor cantidad de errores.

— ebneter

1

Estoy bastante seguro de que Mercurial realmente usa sus herramientas diff detrás de escena, hay una configuración para que pueda cambiarlo en algún lugar. Todas las herramientas de diferencias que mencioné tienen un modo de fusión de 3 vías (no solo un modo de diferencias), y p4merge es definitivamente la herramienta que la fuerza utiliza cuando detecta una colisión. Creo que el VCS en sí solo tiene un algoritmo de detección de colisión (es decir, si ha cambiado el mismo archivo en el mismo lugar), que es un precursor de la fusión.

— Ed James

De forma predeterminada, Mercurial utiliza un algoritmo de fusión simple de tres vías. Sin embargo, sí, puede anular eso. Puede anular la fusión integrada en la mayoría de las herramientas de VCS, para el caso. Sin embargo, AFAIK, todos ellos usan algún algoritmo de fusión interno para buscar conflictos, y ese es realmente un punto clave aquí: si el algoritmo de fusión interno de su VCS es demasiado inteligente, es posible que no encuentre un conflicto donde debería.

— ebneter

En un DVCS, espero que cada vez que una rama se fusione, ejecute cualquier archivo que se edite en ambas ramas a través de la herramienta de fusión principal. No necesitaría buscar un conflicto de fusión, solo suponga que hay uno, si no lo hay, entonces no ha perdido nada. Me imagino que lo mismo se aplica a un VCS estándar.

— Ed James

¿Qué quiere decir con "herramienta de fusión principal"? ¿El algoritmo predeterminado o el que has especificado? Si te refieres a esto último, por lo que sé, ninguno de ellos funciona de esa manera. Cada VCS con el que estoy familiarizado utiliza su algoritmo interno para fusionarse y solo invoca la herramienta seleccionada por el usuario si hay un conflicto. Tenga en cuenta que algunos VCS como git le permiten elegir entre varias estrategias integradas, y algunos VCS tienen algoritmos internos bastante sofisticados, pero eso lleva al problema que describí en mi respuesta.

— ebneter

1

Los conflictos son inevitables.

En mi opinión, qué tan bien un VCS maneja los conflictos dentro de un archivo está un poco sobrevalorado. Por un lado, la mejor manera de lidiar con tales conflictos es no tenerlos en primer lugar. Factorizar bien su software y dividir las tareas con previsión reducirá enormemente los conflictos dentro de un grupo de archivos (y mucho menos dentro de un archivo). Haga un mal trabajo, como agregar demasiadas clases de dios, o un archivo de configuración común que todos tengan que usar y todos quieran entrometerse y esté pidiendo conflictos a nivel de archivo.

Por otro lado, todos usan el mismo algoritmo (pésimo). Un ejemplo: una versión alfa de nuestro proyecto tuvo una pérdida menor de memoria. Fue más un goteo que una fuga, y la fuga se detuvo al final del tiempo de inicialización. Digno de una solución, no digno de un parche. Uno de nuestros clientes "solucionó" el problema, colocando la versión gratuita en el lugar equivocado. El problema se solucionó en la próxima versión. Este cliente fusionó la nueva versión en lugar de hacer un reemplazo completo (WTF?). No hubo conflictos en la fusión a tres bandas; Las llamadas a la libertad estaban bien aisladas unas de otras. Así que ahora el software está cayendo núcleo debido a un doble libre.

Lo que se está perdiendo en la discusión es cuán difícil / lento / propenso a errores es fusionar su trabajo nuevamente en la línea principal del software.

En svn, tu

Confirma los cambios en tu sucursal.
Combina el tronco en tu rama.
Si tiene un gran proyecto, es posible que desee pensar en tomar un café o ir a almorzar.
Ore para que no vea ningún conflicto de árboles cuando regrese.
Compromete los resultados de la fusión en tu sucursal.
Combina tu rama en el tronco.
Toma otro descanso para tomar café.
Una vez más, ore para que no vea ningún conflicto de árboles cuando regrese.
Confirma tus cambios en el maletero.
Cierre la puerta para evitar conflictos con su compañero de trabajo que intentaba hacer lo mismo.

Son muchos pasos no atómicos, demasiados lugares donde los errores pueden colarse (los conflictos de los árboles son desagradables), y lleva demasiado tiempo. He visto múltiples proyectos que renunciaron al uso de ramas con subversión gracias en gran parte al proceso de fusión que es tan lento y propenso a errores. He visto incluso más proyectos pasar de la subversión en gran parte debido a esto.

— David Hammen
fuente

1

Hay un pequeño conjunto de pruebas llamado merge, que compara el sistema de control de revisión con escenarios de fusión del mundo real. Para cada escenario, se asegura de que un VCS pueda hacer lo siguiente correctamente:

fusionar la rama sin conflictos
producir código que compila
producir código que se comporte correctamente

Según el número de pruebas aprobadas en la combinación, parece que hay dos niveles de rendimiento:

Darcs, Git
Bazar Mercurial

Según los lenguajes de programación que intente fusionar, los resultados exactos de la prueba pueden ser importantes. Consulte el sitio web del proyecto para obtener una tabla de comparación detallada.

— mndrix
fuente

1

Cómo no ser un spammer

— mosquito

0

He usado IBM / Rational ClearCase y su fusión de múltiples sucursales es simplemente increíble. Ejecuta anillos alrededor de la subversión. (Sin experiencia de Git o mercurial).

— rápidamente_ahora
fuente

La fusión de hg es igual o mejor que cc. He usado los dos.

— Paul Nathan