Mi compañía está cambiando de Subversion a Mercurial. Estamos usando .NET para nuestro producto. Tenemos una solución con aproximadamente una docena de proyectos que son módulos separados sin dependencias entre ellos. Estamos utilizando un repositorio central en un servidor con push/pull para nuestra compilación de integración.Configuración de mercurial: ¿un depósito central o varios?
Estoy tratando de averiguar si debo crear un repositorio central con todos los proyectos en él, o si debería crear un repositorio por separado para cada proyecto. Un argumento para repositorios separados es que la ramificación de los módulos individuales sería más fácil, pero un argumento para un repositorio único es una gestión y un flujo de trabajo más sencillos.
Soy muy nuevo en hg y DVCS, por lo que se agradece mucho la orientación.
ETA: En hginit.com, Joel dice:
[S] i que está acostumbrado a tener un gran repositorio de gigantesca para toda la empresa , donde algunas personas sólo verifican a cabo y el trabajo en los subdirectorios que les importa, esta no es una muy buena forma de trabajar con Mercurial -usted está mejor teniendo muchos repositorios más pequeños para cada proyecto.
Sería genial si alguien pudiera ampliar esto o dirigirme a más documentación.
Los desarrolladores de mi equipo son todos usuarios de SVN, por lo que están pensando en la línea de "pago y envío". Ellos piensan: "Si estoy trabajando en el código del programador y un desarrollador confirma el código de las tablas, necesito el código de las tablas. ¿Cómo lo obtengo?" Con un repositorio, eso es fácil. Pero con repos múltiples y en mantenedores, ¿cuál es el flujo de trabajo? –
Esto puede ser un problema de descubrimiento, es decir, ¿cómo sabe un desarrollador qué repositorio clonar y dónde está? Agregué un enlace a mi publicación con información sobre cómo configurar y publicar múltiples repositorios. – TwentyMiles
Para nosotros (java con maven) los repos mercuriales funcionaron mejor, cuando se dividieron en la unidad lógica más pequeña posible. Entonces, en la práctica, si teníamos una API para un proyecto, eso se colocaba en su propio repositorio. El código Impl entró en su propio repositorio. Este flujo de trabajo requiere un uso inteligente de subrepos y/o el hábito de atraer a los repositorios con frecuencia. El flujo de trabajo fue beneficioso en términos de CI, ya que la configuración es fácil y el ciclo de retroalimentación es rápido. Hicimos nuestro descubrimiento de cambios, p. por RSS de la CI. Siempre se podía ver fácilmente si algo había cambiado, porque luego pasó por el ciclo de CI. –