Recuperaciones monolíticas frente a múltiples Mercurial para módulos dentro de un conjunto de aplicaciones relacionadas

Question

En mi organización, nos gustaría cambiar de usar CVS a Mercurial por una variedad de razones. Hemos investigado mucho al tratar de determinar cómo debemos organizar nuestros repositorios de Hg en función de lo que tenemos en nuestra base de código y cómo trabajamos. Hemos obtenido respuestas satisfactorias para la mayoría de nuestras preguntas, pero hay un punto que nos está afectando un poco, y me está volviendo loco porque la forma más conveniente de organizar el repositorio para nuestro flujo de trabajo parece ser la forma incorrecta de hacerlo. un punto de vista conceptual. Estoy tratando de averiguar si nuestra percepción de cómo se supone que "se supone" funciona es incorrecta, o si estamos simplemente tropezando con una brecha de características legítima en las herramientas disponibles.

Principalmente mantenemos una base de código de tamaño mediano que consiste en un conjunto de aplicaciones que obtienen todo liberado en el mismo paquete. Conceptualmente se puede dividir nuestro código en tres categorías:

1. de código compartido
código
2. Solicitud de nuestra suite principal (utiliza el código compartido)
3. pequeñas utilidades Varios que se mantienen con poca frecuencia (utiliza el código compartido)

Esto no me parece inusual, pero quiero enfatizar el hecho de que mantenemos el código de la aplicación y el código compartido al mismo tiempo y siempre queremos que estén a la última. Es decir, queremos que todas nuestras compilaciones de aplicaciones utilicen siempre la última versión y la misma versión del código compartido. Con frecuencia agregamos o modificamos el código de la aplicación y el código compartido al mismo tiempo. Actualmente, el código compartido está en un módulo CVS, y las aplicaciones están todas en sus propios módulos separados. El código compartido y los módulos de la aplicación están desprotegidos de manera que el código compartido se genera una vez y luego se vincula a cada aplicación. Frecuentemente hacemos cvs commits que incluyen cambios a través de módulos compartidos y de aplicaciones a la vez. Realmente nos gustaría mantener esa habilidad.

Entiendo que los commits en Hg son atómicos dentro de los repositorios, está bien, pero me gustaría ser capaz de diferenciar y comprometerme con una aplicación y una biblioteca compartida al mismo tiempo (es decir, no me importa) si es realmente atómico, pero no quiero tener que hacer manualmente dos diffs separados y dos acciones de commit separadas).

Conceptualmente, parece que sería correcto tener uno o unos repositorios para el código compartido, y un repositorio por separado para cada aplicación y cada pequeño programa de utilidad. Esto significa que deberías verificar múltiples repositorios para cada compilación, pero eso no es un problema para nosotros. El problema es que no parece haber ninguna herramienta que le permita ver las actualizaciones o los cambios en varios repositorios a la vez, o diferir varios repositorios a la vez y luego enviarlos secuencialmente por usted. Esto sería fácil de realizar, pero eso no ayudaría a los desarrolladores que desean usar varias interfaces GUI para complementar la línea de comando.

Parece que con el fin de ser capaz de comprometerse a través de múltiples bases de código a la vez (desde la perspectiva del usuario) y mantener todo en la punta de lanza en conjunto, las dos únicas soluciones son:

1. Usar un acuerdo de recompra monolítica con TODO en ella.
2. Crea algunos subrepos pero accede/confirma todo a través de un gran repositorio "principal" monolítico que contiene todos los subrepos para mantener todo en las últimas revisiones (que no me parece mejor que (1)).

No puede ser tan inusual querer trabajar con múltiples repositorios "pares" al mismo tiempo, incluso si las acciones no son realmente atómicas en todos ellos, y sin embargo, no estoy encontrando toneladas de artículos o publicaciones clamando por esta habilidad.

En resumen:

1. Nos gustaría organizar nuestro código de tal manera que podemos ver diferencias y comprometerse código de la aplicación y el código compartido al mismo tiempo, desde la perspectiva del usuario (que no necesitan realmente ser atómica).
2. Parece que deberíamos poner código de aplicación y código compartido en repositorios separados.
3. Subrepositorios vinculan repositorios principales a revisiones específicas, que no queremos.

¿Qué es lo que falta aquí?

Answer 1

En mi tienda, tenemos muchos proyectos que están simplemente en repositorios separados, pero el repositorio de la aplicación principal tiene otros 2 proyectos en él. Uno es un módulo que comparte una cantidad significativa de código con la aplicación principal, y el otro es para migraciones de bases de datos para la aplicación (incluso en un idioma diferente). Quería que los cambios relacionados tanto en la aplicación como en el migrador se cometieran juntos, de forma inseparable. En total, todos los archivos fuente en este repositorio tienen entre 10 y 11 MB.

Así que si poner todo en un repositorio es realmente lo que tiene sentido porque no quiere tratar con subrepositorios, entonces no hay nada de malo en poner todo en un repositorio. El mío es del lado pequeño del medio, en mi opinión. La fuente de TortoiseHg es de alrededor de 20 MB, OGRE tiene más de 100 MB.

Sin saber más acerca de sus proyectos y sus relaciones, la impresión que tengo es que un único repositorio funcionaría bien y que no está mirando esto incorrectamente.

Si cambia de opinión, hg convert puede ayudarlo a extraer proyectos en su propio repositorio, manteniendo el historial de esos archivos.

Si el enfoque de un solo repositorio no es para usted, entonces creo subrepos se debe dar una oportunidad, ya que es el único otro método que conozco para el tratamiento de múltiples repositorios cohesiva que se apoya en TortoiseHg (véase la sección Recommendations)

Sin embargo, no estoy seguro de cómo se manejaría el acceso entre departamentos, dado que no parece que exista un subconjunto ya establecido compartido con otros.