Tener 2 productos de un proyecto SVN: ¿cómo mantener ciertos cambios solo para un producto?

Entonces tenemos la aplicación Plutón y una aplicación Goofy, ambos usan el mismo Proyecto SVN. De hecho, solo hay una pequeña diferencia de configuration.

Ahora me enfrento a este problema: el cliente de Plutón quiere algunos cambios nuevos: en detalle, quiere una funcionalidad adicional para Javascript y algunas tags xhtml que usamos en nuestro entorno JSF. Básicamente, se trata de una mejora que, en lo que respecta a JavaScript, él está pidiendo: la funcionalidad anterior aún debe existir. Pero: la nueva funcionalidad podría destruir partes de Goofy, ya que Goofy es una aplicación mucho más grande y difícil de probar. En realidad, Goofy es un superset de Plutón, por ejemplo, Goofy puede hacer lo que sea que haga Plutón, pero de hecho solo es para testings, el Producto final reside en Plutón.

Los files que requieren cambios son bastante estáticos, creo que el último cambio en uno de los files es hace más de medio año. Y ciertamente no hay más de un par de cambios en los últimos dos años.

Lo que pensé fue crear una sucursal para Plutón donde implemente todos los cambios a las tags javascript y xhtml. Los desarrolladores se desarrollarán en el enlace troncal y siempre fusionaré los cambios desde la sucursal antes de implementar (esto probablemente podría hacerse automáticamente). Pero: hay un problema sobre el desarrollo local: dado que es troncal y la nueva funcionalidad solo está en la twig, la nueva funcionalidad no estará disponible cuando se desarrolle localmente para Plutón.

Otro enfoque sería usar, por ejemplo, si la aplicación == Goofy carga javascript Goofy y viceversa.

O finalmente: testing y error, por ejemplo, solo fusiona todos los cambios y corrige errores 🙂

¿Cómo decidirían ustedes sobre esto?

Utilizaría diferentes twigs y aceptaría la inconveniencia de fusionar el uso de trucos especiales, como if application==Goofy cualquier día de la semana. Cuando aumente la complejidad de sus progtwigs y tal vez se agreguen más aplicaciones, la última implementación le devolverá la security.

Otro enfoque que puede funcionar mejor para usted, es refactorizar su código y dividir las partes centrales de las aplicaciones en sus propios proyectos. Luego, deje que cada aplicación haga reference al proyecto principal por separado. Por ejemplo, la parte central podría contener la lógica comercial mientras Goofy / Pluto maneja la GUI y / o implementaciones especiales en algunas de las partes centrales. Su tree SVN podría tener un aspecto similar a:

 trunk |--- Core stuff |--- Project Pluto |--- Project Goofy 

Un enfoque más complicado, pero muy flexible, sería mover las cosas del núcleo a su propio repository. Luego puede usar svn:externals para include las partes principales en sus proyectos. Esto le daría el beneficio de poder bloquear a Plutón y Goofy a ciertas revisiones de Core Stuff. Por lo tanto, puede actualizar las funciones principales para agregar más funcionalidades que se necesitan para un proyecto pero dañinas o no deseadas para el otro. Lo he visto en acción y funcionó muy bien. Teníamos un código henetworkingado que estaba muy desactualizado pero aún comstackdo y funcionando, a pesar de que las piezas principales se habían actualizado durante años desde que se detuvo el desarrollo de los proyectos henetworkingados.

 Core trunk |--- Core stuff (rev 123) Application trunk |--- Project Pluto (Core rev 111) |--- Project Goofy (Core head) 

El blog post svn: externals debería ser útil si quieres jugar con la última opción.