Mercurial "ramas de proveedores" de repositorios externos?

Question

Quiero almacenar un proyecto en Mercurial que contenga un código externo (que puedo modificar yo) proveniente de repositorios Git y SVN. En SVN resolvería esto con vendor branches y copiaría el código, pero lo entendí en Mercurial it's better to have different repositories for different projects, y lo interrumpo cuando es necesario.

diseño del proyecto será la siguiente:

 
- externalLibraryA [comes from a SVN repo] 
    - ...with some extra files from me 
- externalLibraryB [comes from a SVN repo] 
    - ...with some extra files from me 
    - externalPluginForExternalLibraryB [comes from a Git repo] 

En Subversion que crearía vendor dir y una dir trunk, copiar todas las bibliotecas externas por primera vez en vendor, y luego en el lugar correcto en trunk. (Creo) Puedo hacer esto en Mercurial también, con subrepositories, pero ¿es esta la mejor manera de hacerlo?

Intenté configurar diferentes repositorios para las bibliotecas externas, pero parece que no puedo extraer el externalLibraryARepo en el directorio externalLibraryA de mi repositorio principal. Va en el directorio principal, que no es lo que quiero. También puedo crear un repositorio espejo de Mercurial e incluirlo como un subrepo en mi repositorio principal, pero luego los cambios en este subdirectorio van al repositorio espejo, mientras que quiero que permanezcan en el repositorio principal.

Answer 1

Probablemente almacenara esto en un repositorio. Tenga en cuenta que en el enlace que da están utilizando su sistema de compilación al final para reunir la salida binaria de los diferentes repositorios. No tengo claro su razón de ser allí.

Si el problema subyacente que está tratando de resolver es cómo actualizar los elementos externos de una manera limpia, probablemente usaría anonymous branching para eso.

I.e. agregue la lib externa a su proyecto y sus modificaciones. Asegúrate de que funcione. Etiqueta con ExternalA-v1.0. Piratear en su proyecto real. Ahora ExternalA, Inc. tiene una nueva versión de sus cosas. Actualice su repositorio a la etiqueta ExternalA-v1.0. Importa su nueva versión y aplica tus modificaciones en la parte superior. Cometer. Ahora tiene dos cabezas: una con la última versión de su código (que funciona con ExternalA-v1.0) y otra con la última versión de ExternalA (que quizás no funcione con su código). Entonces fusionas y reconcilias los dos. Etiqueta nuevamente, ahora con ExternalA-v2.0. Repita según sea necesario.

Aún puede conservar sus externos en repositorios separados, pero asumo que el proyecto que los usa no tiene que estar actualizado con cambios todo el tiempo. Parece que el objetivo de las sucursales de proveedores es tener algún punto de aislamiento entre dependee y dependientes. Por supuesto, mover los cambios del proyecto externalA al proyecto que está usando eso será una aventura manual (bueno, una copia, como en SVN realmente).

Answer 2

Depende de si el código de su proveedor va a ser personalizado por su equipo o no. Nuestros equipos han tenido un gran éxito al mantener una sucursal denominada "proveedor" en repositorios con nuestras personalizaciones en sucursales nombradas por nombre de proyecto. Este código de proveedor se incluye fácilmente en un proyecto como un subrepositorio.

Una advertencia sobre este enfoque: si el desarrollo activo está sucediendo en el subrepositorio, lo mejor es editar directamente el subrepositorio como un clon por separado; de lo contrario, será necesario prestar mucha atención al repositorio de nivel superior para que Inadvertidamente topa con tu .hgsubstate hacia la revisión incorrecta y rompe tu compilación.

Tenga cuidado con las fusiones del repositorio de nivel superior (su proyecto) entre versiones que apuntan a diferentes ramas con nombre de su subrepositorio, ya que esto puede producir una fusión entre las ramas "proveedor" y "proyecto" en el subrepositorio como lo recuenta, que puede no ser deseable.

Tenga en cuenta que esta funcionalidad también puede cambiar en el futuro, ya que algunas discusiones "cálidas" han tenido lugar en los últimos meses en las listas de correo de desarrollo de mercurio sobre el futuro de la recursividad de subrepositorios.

edición: acabo de ver esta discusión en los enlaces relacionados, así, que parece relevante: https://stackoverflow.com/a/3998791/1186771