Los problemas de siempre con merges en Openbravo ERP

Ya hablé en su día de porqué el sistema de módulos no aportaba nada nuevo al desarrollo de Openbravo ERP. Entre otras cosas hablaba del problema de los merges y como se trasladaba el problema del core a los módulos. Esta vez me ha tocado sufrirlo en un módulo de Philanthros ERP, pero hagamos un poco de historia.

Philanthros ERP es un desarrollo que se encargó a Openbravo para la versión 2.40. Openbravo también ha sido el encargado de migrarlo a la versión 2.50 y generar las plantillas y módulos actuales. Aunque digo que es Openbravo el que ha desarrollado Philanthros no os penséis que son los encargados del desarrollo del core, ni mucho menos, los encargados fueron los que pertenecen a lo que Openbravo llama Custom. Esto no es más que tener su propio equipo de consultoría y desarrollo dentro de casa, vamos lo mismo que puede hacer cualquier consultoría al uso de las que ya conocemos. De hecho se nota mucho que han sido estos quién han hecho el desarrollo por algunas chapucillas la baja calidad del código en muchos aspectos. Informes mal internacionalizados, estilo de código caótico y que no sigue la guía de estilo de Openbravo, código insertado a pelo (hard coded), etc.

Estos días se ha abierto una incidencia sobre el proceso de completar factura de compras en Philanthros ERP. Al revisar el código me he dado cuenta que en su día se personalizó el pl/sql que se ejecuta en este proceso y se renombró como CUS_INVOICE_POST (el original se llama C_INVOICE_POST), este a su vez se insertó en un módulo llamado sales. Pues bueno, cada vez que se ha ido actualizando el core se ha ido parcheando progresivamente el pl/sql orginal, pero el que se personalizó como es natural no ha estado afectado por estos cambios. ¿Qué he tenido que hacer? pues revisar los 33 parches que se han aplicado al archivo original desde septiembre de 2009, que es cuando se creó este fork por llamarlo de alguna forma, e ir integrándolos en la versión en uso.

No os podéis ni imaginar el trabajo de chinos que ha supuesto realizar todo este trabajo al estar tan desvirtuado el archivo personalizado que desarrolló Openbravo, pero bueno, parece que al final lo he conseguido.

Este es el problema de siempre, que cuando personalizas un archivo del core tienes que integrar manualmente los cambios que se le hagan.

Cheli

Diff/merge gráficos

Estaba intentando solucionar algunos problemillas en la actualización de OB, que todo sea dicho es un dolor, y subversion no me estaba ayudando demasiado con lo que no me ha quedado más remedio que hacerlo a manopla. Para esto necesitaba algo que me permitiera hacer diffs y merges de forma eficiente y qué mejor para esto que kompare.

Me gusta kompare porque te permite mirar la diferencia entre archivos de forma gráfica y muy intuitiva, navegar entre las modificaciones una a una y aplicar merges de izquierda a derecha o viceversa ya sea por cada cambio o por archivo. Otra cosa que necesitaba es que me mirara recursivamente los cambios entre dos árboles de directorios y esta herramienta para hacer esto es una maravilla.

Total, que en algún momento kompare se me ha quedado trabado en un archivo y su homólogo, y le ha costado un montón procesarlo, así que me he puesto a buscar más alternativas y he encontrado meld que es una herramienta similar pero para gnome. A meld también le ha costado bastante procesarlo pero al final más o menos lo he conseguido.

Lo suyo es que esto lo hiciéramos directamente desde el sistema de control de versiones pero mira, a veces hay que arremangarse las manos y hurgar en el fango.

Cheli