layout específico de repo de subversión en la empresa

Primero explicaré algunos antecedentes del uso de Subversion en nuestra empresa. Empezamos a usar Subversion hace unos 3 años. Lo usamos con TortoiseSVN como cliente.

Tenemos 3 repositorys con proyectos totalmente diferentes que no tienen nada en común.

Pero en 1 repository tenemos aproximadamente 6 productos / proyectos que comparten dll común (para comprimir, xml, types de línea, etc.) Tenemos alnetworkingedor de 20 de estos dll comunes (que aún se están actualizando).

Entonces estos 20 Dll comunes están en el maletero junto con los seis proyectos que los necesitan.

Ahora el tronco se está llenando y el inconveniente de esto es que todos los proyectos dependen el uno del otro. Entonces, si los cambios se realizan en 1 dll común para un proyecto, entonces todos los demás proyectos deben actualizarse y deben adaptarse y validarse.

Dado que esto no es tan útil (especialmente cuando desea lanzar un producto y luego vienen algunos nuevos cambios de otros productos), pensamos empalmar todo por proyecto. Aún manteniendo el gran tronco para sincronizar entre los diferentes proyectos.

Así que creamos la carpeta trunk / branches / tags por proyecto y hacemos una copy svn de solo la dll necesaria para ese proyecto.

Situación:

Antes de:

-branches -tags -trunk -Common DLL 1 -Common DLL 2 -Common DLL 3 -Common DLL 4 -Common DLL 5 -Project 1 -Project 2 -Project 3 

Ahora

  -Projects -Project1 -branches -tags -trunk -Common DLL 1 -Common DLL 2 -Project1 -Project2 -branches -tags -trunk -Common DLL 2 -Common DLL 3 -Common DLL 4 -Project2 

La ventaja de este enfoque es que tiene una mejor visión de set de los diferentes proyectos y puede ver cada proyecto por separado como totalmente recursivo en lugar de realizar un pago parcial. También tenemos más control cuando hacemos la synchronization de la dll común (importante para las versiones) y no tenemos compromisos de trabajo sin terminar de otros desarrolladores de proyectos.

SIN EMBARGO: tenemos muchos problemas para fusionar estos Common Dll. Con (último) TortoiseSVN tenemos constantemente "conflictos de tree". También una gran cantidad de problemas de fusión (a veces retrocediendo durante más de un mes y sin recordar lo que realmente cambió).

También cambiar el nombre de dll sale mal y Tortoise siempre agrega todos los files dll de tronco que aún no están en el proyecto a la copy de trabajo de este proyecto. Entonces siempre tiene que eliminarlos manualmente antes de registrarse.

Sé que nunca deberíamos usar "Reintegrar una sucursal", pero quedan dos opciones. ¿Alguien sabe cuál es el mejor?

¿Podemos mantener esta estructura de repos o deberíamos cambiarla? ¿Es mejor poner todo Common Dll en otro Repo y luego usar Externals?

Gracias

¿Es mejor poner todo Common Dll en otro Repo y luego usar Externals?

No necesariamente "otro repo", pero definitivamente debe tratarlo como un proyecto que se sostiene por sí mismo. Tu layout debería verse así:

  -Project1 -trunk -branches -tags -Project2 -trunk -branches -tags -CommonDLL1 -trunk -branches -tags -CommonDLL2 -trunk -branches -tags -... 

Entonces Project1/trunk probablemente tenga una propiedad svn:externals con este contenido:

 -r148 ^/CommonDLL1/trunk CommonDLL1 -r157 ^/CommonDLL2/trunk CommonDLL2 

Esta propiedad hace que Subversion cree automáticamente las carpetas CommonDLL1 y CommonDLL2 dentro de su copy de trabajo de Project1/trunk cada vez que realiza un pago o una actualización.

Observe cómo la definición externa contiene un número de revisión. Esto garantiza que si cambia algo en CommonDLL1, esto no afectará al Project1 hasta que cambie explícitamente el número de revisión en la definición externa. Esto es especialmente importante para la inmutabilidad de sus tags de proyecto.

Hay algunos inconvenientes en este enfoque que debe sopesar con respecto a los aspectos positivos:

  • Si realiza un cambio en CommonDLL1 mediante la CommonDLL1 través de una copy de trabajo de Project1 , es posible que se CommonDLL1 confundido cuando el cambio desaparezca misteriosamente después de una actualización. Esto se debe a que SVN no ajustará automáticamente el número de revisión en la definición externa. Tienes que cambiarlo explícitamente y comprometer ese cambio también. Eduque a su equipo sobre esto.

  • Su server de continuous integration no descubrirá automáticamente que el último Project1/trunk ya no se CommonDLL1/trunk el CommonDLL1/trunk más CommonDLL1/trunk . Solo lo sabrá cuando cambie el número de revisión en la definición externa.

La tendencia es dividir las cosas en unidades (lógicas) lógicas e independientes. Curiosamente, el DVCS de Git ha aumentado la conciencia: las personas que querían pagar solo / tronco / proyecto se enfrentaron con la imposibilidad de hacerlo, y la respuesta general ha sido cortar los proyectos (count como una unidad independiente) en su propio repository.

Si bien estos packages de granularidad fina (el enfoque "/ proyecto / troncal") implica un poco más de trabajo, la independencia de cada componente se juega para la gente al final. El desacoplamiento de proyectos / código lleva a las personas a pensar más acerca de las API y la interacción. En otras palabras, es posible que ya no necesite conocer toda la image y pueda concentrarse solamente en algunos componentes.

Ver Xorg que emplea este esquema de repositorys divididos (en el sentido de que cada uno tiene su propio maestro / troncal).

Para ti eso significa: tu estado "ahora" coincide con esta descripción. Sin embargo, es una pena que TSVN no pueda ocuparse del estado del repository; mala interacción de herramientas combinada con las decisiones de layout que SVN tomó hace unos años.

Creo que el segundo enfoque es mucho mejor que el primero. Pero un poco difícil de manejar en primer lugar.

    Intereting Posts