2009-05-06 36 views
8

Estoy usando Mercurial para uso personal y estoy contenplandolo para algunos proyectos distribuidos como una alternativa a SVN por varias razones.Mercurial: Cómo administrar el código común/compartido

Me siento cómodo con su uso para proyectos autónomos y puedo ver varias opciones para compartir; sin embargo, todavía no he encontrado ninguna guía para administrar bibliotecas comunes que se incluirán en proyectos múltiples de manera similar a la proporcionada por externos en subversión.

El bloque de código compartido más obvio es el manejo de errores y la generación de informes; queremos que sea prácticamente el mismo en todos los proyectos (está bastante bien desarrollado). También hay un código de utilidad, bibliotecas de control y similares que consideramos mejor tener como proyectos creados con cada solución que incorporarlos como clases compiladas (entre otras cosas, porque asegura que se mantienen actualizados, la integración continua nos ayuda a resolver los cambios). .

Pensamientos (Odio las preguntas abiertas, pero quiero saber qué hacen, en todo caso, otros).

Respuesta

3

Mercurial 1.3 ahora incluye nested repository support, que se puede usar para expresar dependencias. La otra opción es permitir que su sistema de compilación administre la descarga y el seguimiento de las dependencias usando algo como ivy o maven, aunque están más enfocados en extraer el código compilado.

+0

Ir a 1.3 funciona para mí (o al menos va a funcionar!) – Murph

0

Usa Forest Extension emula svn externals para HG, hasta cierto punto eso es.

+0

Gracias, volverán a revisar (no es exactamente lo que he leído es como hacer, pero por esa razón aún no he leído lo suficiente ...) – Murph

+3

La extensión de Forrest nunca fue compatible oficialmente, y ahora se obvió por completo con el soporte de submódulos en Mercurial 1.3. –

+3

Y esa es una razón para downmod me? La vez que escribí la respuesta, no había Mercurial 1.3. * suspiro * – ismail

1

El mundo ha cambiado desde que hice esa pregunta y la solución que ahora uso es diferente.

La respuesta simple ahora es usar paquetes (específicamente NuGet como lo hago .NET) para entregar el código común en lugar de anidar repos e incluir los proyectos en una solución.

Tengo un código común integrado en paquetes NuGet por y alojado usando TeamCity y donde anteriormente tendría un externo e incluyo el proyecto/fuente, ahora solo haría referencia al paquete.

0

Subrepository (con buena guide) o Guestrepo "para superar las limitaciones ..." (de subrepos) es de hoy independiente del idioma respuesta

Cuestiones relacionadas