Cada vez que veo un conflicto en importaciones o cambios de firma de método (por ejemplo, cambio de nombre de variables) en mi SCM me pregunto si hay algo así como un método diff/merge consciente del lenguaje que pueda manejar el más molesto pequeños cambios que pueden ocurrir en un proyecto compartido. ¿Hay algo que maneje los conflictos sin problemas, trabajando en un entorno Unix?Comando de fusión de Java consciente
Estoy de acuerdo en que sería increíble si existe tal herramienta, pero no hay ninguna que yo sepa. La razón por la que creo que no hay ninguno es porque el algoritmo de fusión para cada SCM (ya sea git, hg, bzr, svn, etc.) funciona en el mínimo común denominador, que es simplemente texto sin formato. Para que estas herramientas de SCM realmente comprendan la sintaxis y la semántica del lenguaje, deberían incluir la capacidad de analizar el idioma. Parece que esto es simplemente una tarea demasiado grande para que cualquier SCM incluya la capacidad de analizar Java, C#, Python, Ruby, Groovy, C, C++, etc., sin mencionar que cada uno de estos idiomas tiene diferentes sintaxis entre versiones. (Por ejemplo, los genéricos de Java no existían hasta 1.5). Por lo tanto, el SCM debería incluir la capacidad de detectar o configurar para saber qué idioma y versión del idioma está escrito en el código fuente.
Creo que sería más probable que cualquier característica de fusión dependiente del idioma se encuentra en una herramienta de fusión de terceros (por ejemplo, la combinación> configuración de herramienta en .gitconfig y la configuración de ui> fusión en .hgrc). Esta herramienta se puede configurar para saber que cualquier archivo .java en su proyecto está escrito en Java 1.6 y luego utiliza las características de análisis en el JDK para generar el AST y realizar un análisis "profundo" de si el cambio fue significativo en el contexto de ese idioma.
Sí, eso es lo que quiero decir con "comando de fusión". Pero la pregunta es si existe algo así. – Marcus
Es posible que desee considerar que todos en su equipo compartan la misma configuración IDE para cosas como el orden de las importaciones, el formateo, etc., para evitar conflictos como este en primer lugar.
Esto realmente no resuelve el problema.Considere, por ejemplo, algunos códigos Java "import a; import e;". Supongamos que agrego "import b"; y agrega "import c;", ambos en orden alfabético correcto. Cuando llegue el momento de fusionar, obtendremos un conflicto de fusión. Si acordamos poner las importaciones en orden alfabético, entonces no hay ambigüedad acerca de qué es la fusión correcta, pero las herramientas generan conflictos de fusión porque no conocen las convenciones de codificación. – Phil
La falla más común para fusionarse parece que cualquier adición de código entra en conflicto con cualquier otra adición de código, en el mismo lugar. Debería haber una solución general a esto "¡agregar todas las cosas!" estilo de fusión, que funciona bastante bien en todas las sintaxis. (Predeterminado para la inclusión de todas las inserciones, como combinación predeterminada cuando la fusión ocurre en un cierto bloque o rango). –
Estoy buscando exactamente lo mismo. Esos fabricantes de herramientas de combinación probablemente deberían abordar este tipo de fusión semántica, consciente del lenguaje ... si no, tendré que convertirme en uno :)
Por ahora, como truco de un pobre, a veces preprocesamos los 3 archivos (base, la nuestra, la de ellos) a su "forma canónica" al alimentarlos a través del Código Limpiar/Organizar Importaciones/Miembros de Eclipse.
Aunque limitado, esto funciona bien: la última vez redujo el número de conflictos a ~ 200 en 2. Estoy planeando incluir esto en un script, y conectarlo a la herramienta de combinación de git.
También escribí el script de autoresolver conflictos de importación java, que simplemente mantiene ambos lados de las importaciones y agrega comentarios para explicar lo que está sucediendo y qué hacer: 'organizar importaciones'.
En cuanto a los conflictos de importación de java, sugiero que se elimine la sección de importación en conflicto (o incluso todas las importaciones) y que el IDE vuelva a insertarlos. Obviamente tiene que acordar un pedido de importación común para que esto funcione. Algunas veces las importaciones no son únicas (por ejemplo, java.util.List vs. java.awt.List), pero los casos sin una solución obvia son bastante raros. * En realidad, hay una solución mejor: elimine solo los marcadores de conflicto, deje allí las importaciones posiblemente duplicadas y deje que finalmente el IDE lo limpie. * – maaartinus
Sí, eso es lo que hice (refiriéndose a "También escribí el guión autoresolve los conflictos de importación de Java") Gracias por aclarar de todos modos – inger
no git rebase ¿resuelve este problema? cualquier cambio de nombre de variables se contabilizará en las confirmaciones asociadas. git rebase te permite mantenerte sincronizado con los commit previos. siempre y cuando rebase con frecuencia (¿ish diario?) no debería estar teniendo conflictos estúpidos como ese, y si lo es, probablemente sean conflictos reales y no solucionables por un analizador gramatical de Java.
Buena idea. Suena como el concepto para su próximo proyecto de código abierto :) – Asaph
Bueno, los casos de "colgar la fruta" son tan fáciles que todavía creo que alguien debe haber pensado en eso antes de comenzar esta pregunta. – Marcus
Parece ser un dup para http://stackoverflow.com/questions/523307/semantic-diff-utilities – Marcus