SVN – Proyecto para el cual la ramificación tiene un impacto para que se haga la próxima sucursal

Context

He configurado un process simple cuando lo uso en mi empresa para un proyecto, es decir, cada vez que una nueva característica está en desarrollo y aún no se ha probado, debe permanecer en su twig, solo cuando se pasa la validation, la twig se puede fusionar al maletero Esta parte funciona muy bien, pero desde ahora un segundo desarrollador también está trabajando en el proyecto, y debido a un formatting de datos específico en el proyecto.

En la carpeta del proyecto, tenemos un file "dictionary" que contiene pares key = valor, pero la key es simplemente un dígito (esto es henetworkingado y no se puede cambiar). Luego, las keys de este file "dictionary" se utilizan en muchos otros files de fonts / datos. Por lo general, los valores key se utilizan y se agregan secuencialmente.

Ejemplo

Digamos en el tronco r100, la última input en el dictionary es 1000.

Dev A crea una twig A desde la troncal r100, y luego en esta twig agrega 200 inputs en el dictionary, la última input del dictionary es ahora 1200. Dev A usa las inputs 1001 a 1200 para desarrollar nuevos files de fuente o de datos.

Entonces Dev B crea la twig A desde la troncal r100 (ya que la twig A no está validada aún no se ha reintegrado), y así en este momento, en la twig B, la última input del dictionary es 1000. Dev B agrega 300 inputs en el dictionary en esta twig, la última input del dictionary es ahora 1300. Dev B utiliza las inputs 1001 a 1300 para desarrollar nuevos files de fuente o de datos.

Dev. A finalizar la ramificación Una validation, y fusionar / reintegrar su twig A al tronco, no hay problema, el dictionary en el tronco es ahora el mismo que el de la twig A y, por lo tanto, contiene 1200 inputs.

El problema ahora es que si Dev B desea actualizar la twig B desde la línea troncal (o fusionar la twig B directamente hacia atrás la línea troncal), habrá MUCHO conflicto en el file de dictionary, ya que habrá 200 inputs con keys comunes. (1001 a 1200) pero diferentes valores. Resolver el conflicto en este momento es molesto y un poco doloroso para el equipo de desarrollo.

Soluciones posibles ?

Pensé en lo siguiente:

  1. Cada vez que el dictionary se ha comprometido en una twig, Dev responsable de esta twig debe fusionar el dictionary en el tronco. Luego, cuando otro desarrollador en otras sucursales actualice su propia twig desde el enlace troncal, obtendrá el contenido del dictionary que se está modificando en otra twig solamente.
  2. Los desarrolladores se comunican juntos cuando crean una twig y se asignan un range de key del file de dictionary,

El problema de la Solución 1 es que, en mi entender, rompe un poco el concepto del aislamiento de la twig en sí.

El problema de la solución 2 es que no es confiable ni eficiente.

Me falta algo, ¿es la forma de usar branch en este caso irrelevante? Tal vez el file de dictionary no debe estar ramificado en la twig y solo debe savese en el tronco (¿ramificación parcial ?!).

Gracias de antemano por su ayuda e ideas sobre esto.

Veo al less dos forms posibles

  1. Extensión lógica de su solución 1: el dictionary no se fusionó permanentemente en todas las twigs, sino que existe y se utiliza como único recurso común compartido. SVN: externos, tipo de nivel de file (requiere Subversion 1.6+, sugeriré 1.8. *). Implementación: existe un file de dictionary real fuera del tree de / trunk, el dictionary dentro de trunk es externo con una ruta de acceso absoluta al file (no relativa, para tener un objective inalterado en la bifurcación). De esta forma, todas las twigs en cualquier momento usarán un dictionary común (en el caso de dos ediciones paralelas, el segundo committer tendrá que actualizar el file antes de la confirmación real y fusionar los cambios con la resolución de conflictos en las keys)
  2. Cada desarrollador usa no secuencial, sino una numeración dispersa (numeración basada en acuerdos). Es decir, en el supuesto de que no existan más de 10 desarrolladores en cada momento: Dev 0 usa solo 0, 10, 20 … Dev 1 – 1, 11, 21 … Dev 9 – 9, 19, 29 … y los cambios del dictionary no se cruzan en las teclas de fusión