mercurial - tortoise - subversion ramas desarrollo

¿Un subrepositivo mercurial debe ser un subdirectorio del repositorio principal? (2)

Si la Biblioteca B y C deben ser subdirectorios del Proyecto A, ¿qué debo hacer si quiero iniciar un Proyecto D que usa la Biblioteca B pero que no está relacionado con el Proyecto A?

Cualquier proyecto puede existir de forma independiente y como subrepositivo de otro proyecto al mismo tiempo. Te lo explicaré sugiriendo un flujo de trabajo.

En primer lugar, cada uno de sus proyectos (A, B, C) debe tener un repositorio bendecido que se publique en algún lugar:

Puede ejecutar hgwebdir en su propio servidor, o hacer uso de un servicio de alojamiento Mercurial como Bitbucket o Kiln . De esta manera, los desarrolladores tienen un punto de autoridad central para extraer / impulsar cambios, y usted tiene algo para hacer copias de seguridad.

Ahora puede hacer clones de estos repositorios para trabajar de dos maneras diferentes:

Clona directamente tu proyecto. Por ejemplo:
hg clone http://bitbucket.org/LachlanG/LibraryB C:/Lib/LibraryB
y / o cree definiciones de subrepositores colocando un archivo .hgsub en la raíz de ProjectA con el siguiente contenido:
libraries/libraryB = http://bitbucket.org/LachlanG/LibraryB libraries/libraryC = http://bitbucket.org/LachlanG/LibraryC

Estas definiciones subrepositivas le dicen a Mercurial que siempre que se clona el Proyecto A, también tiene que poner clones de la Biblioteca B y la Biblioteca C en la carpeta de libraries .

Si está trabajando en el Proyecto A y confirma, los cambios en las libraries/LibraryB y libraries/LibraryC también se confirmarán. Mercurial registrará qué versión de las bibliotecas está utilizando el Proyecto A en el archivo .hgsubstate . El resultado es que si hg update versión anterior del proyecto para ver cómo funcionaron las cosas la semana pasada, también obtendrá la versión correspondiente de sus bibliotecas. Ni siquiera necesitas hacer etiquetas :-)

Cuando hg push los cambios del Proyecto A al repositorio bendecido, Mercurial también se asegurará de empujar los cambios subrepositivos primero a su propio origen. De esa manera, nunca publicará accidentalmente cambios de proyecto que dependan de cambios de biblioteca no publicados.

Si prefiere mantener todo lo local, aún puede utilizar este flujo de trabajo utilizando rutas relativas en lugar de direcciones URL en las definiciones del subrepositivo.

Mi proyecto se compone de código en las siguientes ubicaciones

C:/Dev/ProjectA C:/Lib/LibraryB C:/Lib/LibraryC

Actualmente cada una de estas carpetas es un repositorio Mercurial completamente independiente. El proyecto A cambia todo el tiempo, la biblioteca B y la biblioteca C cambian raramente.

Actualmente etiqueto cada versión del Proyecto A a medida que se publica y (cuando recuerdo) pongo una etiqueta correspondiente en los repositorios de la Biblioteca B y C.

¿Puedo mejorar esto usando subrepositorios? ¿Requeriría eso que haga de la Biblioteca B y C un subdirectorio del Proyecto A?

Si la Biblioteca B y C deben ser subdirectorios del Proyecto A, ¿qué debo hacer si quiero iniciar un Proyecto D que usa la Biblioteca B pero que no está relacionado con el Proyecto A?

De hecho, puede declarar B y C subreposiciones del proyecto A (aparecerán como subdirectorios, como se describe en Mercurial Subrepository ).
Eso mejoraría su mecanismo de liberación, ya que le permitiría:

obtener todos los repos en un solo lugar ( A y debajo)
referencia una etiqueta exacta de B y C debajo de A
etiqueta cada sub-repo s primero si tenían alguna modificación
etiqueta A con la información sobre las etiquetas B y C en ella (cualquier clon de A podrá obtener las etiquetas exactas de B y C utilizadas por A )

También puede declarar B como un subrepo de D , independientemente de A Lo que haga en A (con respecto a B ) no tendrá consecuencias por B usado en D