diff - software - Extraiga los cambios relevantes para la revisión del código
software de codigo cerrado y libre (10)
Estoy trabajando en un proyecto con un equipo donde nos registramos temprano y con frecuencia. Los registros individuales se completan a satisfacción del desarrollador que realiza el cambio (incluidas las pruebas cuando sea posible), pero a veces la dirección del trabajo cambia ligeramente y los compromisos previos deben revertirse y realizarse de otra manera. O bien, el código auxiliar se completa en confirmaciones posteriores.
Cuando llega el momento de revisar el código, hay una secuencia de confirmaciones todas etiquetadas con el mismo número de identificación de seguimiento de errores. Es fácil obtener una lista de dichos cambios. Cuando un revisor revisa los cambios uno por uno, a veces habrá una confirmación A que se deshace o modifica por una confirmación posterior B como parte de la misma revisión. Esto puede hacer que la revisión sea más difícil.
Si solo un desarrollador estaba trabajando en el archivo durante el cambio, entonces es fácil hacer una diferencia entre el estado original del archivo y el estado final del archivo. El problema surge cuando otro desarrollador hace cambios no relacionados en el mismo archivo, o incluso en las mismas funciones.
¿Cómo manejas esta situación? ¿Existen herramientas que, dadas una secuencia de parches a un archivo, puedan dar el equivalente moral de una diferencia entre la primera y la última versión, pero solo incluye un subconjunto de esos parches?
Ahora que lo pienso, podría crear una sucursal temporal en git comenzando desde antes del primer cambio relacionado, y seleccionar cuidadosamente los cambios relevantes para la revisión. Con suerte, no habrá demasiados conflictos que deban resolverse (y si los hay, todo el lote debería revisarse de una vez). ¿Alguna otra idea?
Más información: Este es un gran sistema heredado en el que un solo cambio puede afectar a varios archivos. Los archivos son grandes y crudos, demasiado grandes para simplemente revisar el producto final sin una indicación de lo que podría haber cambiado.
Uh, solo mira el último estado del archivo.
(La ramificación para cada cambio es un PITA. No lo haga).
Resulta que puedes hacer esto bastante bien en IntelliJ IDEA si tienes esa herramienta:
Seleccionar control de versiones | Mostrar vista de cambios
En el lado izquierdo, selecciona el repositorio y haz clic en todas las revisiones que quieras revisar.
En el panel de la derecha, obtendrá una lista de todos los archivos que se ven afectados por las revisiones que ha seleccionado. Cuando eliges "diff", verás los cambios internos en los conjuntos de cambios seleccionados. Las revisiones internas que ocurren dentro de las confirmaciones no se muestran (como se puede esperar)
Un enfoque (utilizando la terminología de subversión, pero los enfoques similares también deberían funcionar con otros sistemas):
Verifique una copia de trabajo en una revisión justo antes de los primeros cambios. A continuación, combine todas las confirmaciones relacionadas en su copia de trabajo.
Ahora tiene una copia de trabajo que difiere de su base solo por los cambios relevantes. Puede revisar esto directamente o crear un parche para su revisión.
Si algún cambio no relacionado después de la revisión base se superpone con los cambios revisados, puede obtener un conflicto de fusión, pero esto debería ser raro.
Desde un punto de vista de Subversion
Teniendo en cuenta sus requisitos, correría las revisiones del código difiriendo de una etiqueta de la última revisión; es decir, dif entre dos etiquetas.
Si tiene la capacidad de cambiar los sistemas de control de fuente, puede considerar seriamente git (o mercurial u otra herramienta similar).
Cada desarrollador crea su propio repositorio local.
Para cada error en el que trabajan, crean una rama.
Cuando hayan terminado con los cambios, podrán jugar con su historial utilizando los comandos de rebase para agrupar los cambios en puntos de control coherentes.
El desarrollador luego envía el conjunto de cambios reubicados para su revisión.
El integrador o revisor puede entonces aceptar los cambios tal como están, seleccionarlos para captar lo que quieren conservar y / o hacer más reajustes para separar las confirmaciones que no deberían haber sido agrupadas.
El paquete patchutils contiene una herramienta combinada que puede "crear un parche unificado acumulativo a partir de dos parches incrementales".
Haría prácticamente lo que sugeriste. Crea una rama de revisión. Obtenga los desarrolladores cuyos cambios se están revisando para hacer el trabajo de selección en esa rama. Difiere la raíz de la rama con la cabeza.
Probablemente también crearé una pequeña herramienta para tomar todos los checkins que coincidan con una etiqueta de identificación de seguimiento de errores determinada y mezclarlos en un script aproximado para hacer la selección de cereza. Definitivamente le daría al usuario la oportunidad de editar este script antes de ejecutarlo, ya que apostaría a que algunas cosas se etiquetan mal.
Haz la revisión en la rama. Haga cualquier edición en la rama. Cherry recoge los cambios de nuevo en el maletero. Deseche la rama de revisión si ya no la quiere.
Consulte nuestra http://www.semdesigns.com/Products/SmartDifferencer/index.html para ver una herramienta que está parametrizada por la gramática del lenguaje, y produce deltas en términos de elementos del lenguaje (identificadores, expresiones, declaraciones, bloques, métodos, ... .) insertado, eliminado, movido, reemplazado o tiene identificadores sustituidos a través de él consistentemente. Esta herramienta ignora el reformateo de espacios en blanco (por ejemplo, diferentes saltos de línea o diseños) y valores semánticamente indistinguibles (por ejemplo, sabe que 0x0F y 15 tienen el mismo valor).
Esto no desenredará dos conjuntos de cambios realizados por razones fundamentalmente diferentes. Pero minimizará el tamaño de los deltas que tiene que inspeccionar, y eso seguramente ayudará.
Usted dice que los archivos tienen miles de líneas de longitud. Esto suena como COBOL. Existe una herramienta de diferenciación inteligente para C #, PHP, Java, C ++ ... y COBOL, con ejemplos para la mayoría de estos en el sitio web.
Si usted es un desarrollador de .NET, puede encontrar que las capacidades NDepend code diff son útiles para dicho escenario. Descargo de responsabilidad: soy uno de los desarrolladores de la herramienta
Básicamente, NDepend puede analizar una base de código y crear y luego conservar una instantánea del código. Se pueden comparar dos instantáneas, tomadas en dos momentos diferentes. A continuación, NDepende permite escribir consultas de códigos sobre LINQ (CQLinq) para solicitar nuevos métodos / clases, métodos / clases eliminados, métodos / clases donde se cambió el código ... tan fácilmente como escribir:
from m in Application.Methods where m.CodeWasChanged() select m
Luego puede refinar su consulta de código y solicitar ciertas propiedades, como si el nombre del método contiene la palabra Extraer y tiene más de 30 líneas de código:
from m in Application.Methods
where m.CodeWasChanged() && m.NameLike("Extract") && m.NbLinesOfCode > 30
select m
Además, NDepend puede conectarse a cualquier herramienta de diferencia de texto . El usuario puede comparar las 2 versiones del método o clase modificado.
Otra buena capacidad es conectar NDepend a RedGate Reflector , descompilar las 2 versiones del método / clase y comparar estas 2 versiones con una herramienta de diferencia de texto. Esta capacidad puede ser especialmente útil en su escenario , ya que de esta manera está haciendo diff de código solo en un único método o clase, incluso si está realmente anidado en un gran archivo fuente.
Además, para evitar escribir la consulta usted mismo, el panel Búsqueda por cambios genera dicha consulta de código en diff para usted:
Espero que este enfoque original pueda ayudar.
Creo que deberías estar ramificando para hacer tus cambios. Ver mi publicación aquí .