Mantenga el parche sincronizado con la fuente cambiante

¿Hay alguna opción estándar para crear 'parche' P que funcione en el file F de tal manera que siga funcionando correctamente cuando el file F se convierta en F '.

Entonces tendré algún mecanismo que cambie P en P 'de modo que P' (F ') produzca el mismo cambio que P (F), o, preferiblemente, tendré P elástica para que pueda usarse tanto para F Y F '.

Actualmente estoy usando la búsqueda de expresiones regulares y reemploop para crear dicho parche, pero me pregunto si existe alguna forma estándar de hacerlo.

Este problema se conoce como fusión. Tiene un file original A y dos versiones modificadas B y C, y desea crear una versión D que combine ambas modificaciones. Esto solo funciona si los cambios son independientes; de lo contrario, la fusión es un process manual. Manejar las fusiones de cambios concurrentes al código fuente es una tarea frecuente en la ingeniería de software.

En casos simples, un parche producido por diff ya funcionará si el file fuente ha cambiado. La utilidad de patch permite algunos "fuzz": si usted hace un diff de A a B, y las áreas afectadas por ese diff son idénticas (pero posiblemente en diferentes desplazamientos en el file) en A y C, entonces el parche se aplicará limpiamente en C. Esto funciona bien siempre que las áreas modificadas en B y C no estén en las mismas ubicaciones (tiene que haber un par de líneas de separación).

Cuando los parches no se aplican de forma limpia, la fusión es un problema difícil y específico del dominio. Por ejemplo, considere estos dos cambios:

 ABC a=2 a=3 b=2 x=ax=ax=b 

Los seres humanos tienden a detectar el patrón de que B ha cambiado 2 a 3 y C ha renombrado a a b , por lo que el resultado de la combinación debe ser b=3 , x=b . Pero es probable que las herramientas automatizadas marquen la primera línea como un conflicto, porque se ha modificado de dos maneras diferentes.

Escribir un parche que "haga algo sensible" tanto a B como a C es un problema difícil (AI-completo). En casos prácticos, para muchas situaciones típicas, usar diff -u AB como parche tiende a funcionar y producir el D deseado de C, o falla con un error que indica que el parche no se aplica limpiamente.

Realmente no recomendaría usar sed para tal cosa. El problema es que, incluso si se aplica un parche, a menudo puede tener "fuzz", lo que significa que algunas de las líneas de context no coinciden perfectamente. Si bien esto a menudo significa que el código subyacente subyacente cambió ligeramente, también puede significar que el parche se aplicó en un lugar equivocado (he visto que esto sucedió, no fue agradable ni fácil de depurar).

Además, incluso si el parche se aplica limpiamente, es probable que ya no tenga sentido semánticamente. Para captar esto, sin embargo, debe conocer los cambios que tuvieron lugar en el código parcheado.

Por las razones expuestas, se considera una buena práctica revisar al less todo lo que se aplica con una fuzz (y probablemente también verificar superficialmente lo que corresponda con una compensación). Tener más de las 3 líneas de context pnetworkingeterminadas también podría ser una buena idea.

Habiendo pasado por la gran advertencia de grasa, una de las forms de hacerlo es relativamente sin dolor utilizando un sistema de control de versiones, probablemente un distribudet avanzado como eg mercurial o git . Las opiniones sobre la elección entre estos dos varían, Mercurial es un poco más similar al CVS anterior y al SVN que Git, y podría decirse que también tiene una mejor curva de aprendizaje (mientras que se dice que Git es más rico en características).

En Mercurial tiene la extensión Mercurial Queues (MQ) exactamente para estos casos. La publicación del blog de Steve Losh es una buena introducción al uso de MQ y otra buena lectura es esta guía para MQ en el website para desarrolladores de Mozilla.

A veces, los patchutils pueden ser útiles también.