Disposición de depósito Mercurial para múltiples ramas

Question

Tengo un número de proyectos cuasi relacionados que deseo controlar la versión. En SVN Me instalarlas como varios directorios dentro de un solo proyecto

/scripts #updates in sync with project1 & project2 
/project1 #requires database 
/project2 #requires database 
/database 

Naturalmente otros diseños SVN son posibles para este ejemplo de juguete, pero esta disposición tiene ventajas:

• puedo copiar archivos entre ramas conservando el historial
• Puedo consultar solo un subconjunto de proyectos, por ej. svn co repo/project2; svn co repo/database. Esto ahorra una cantidad considerable de tiempo de almacenamiento & si project1 es grande.
• Fácil gestión del repositorio, ya que el acceso del usuario se define una vez para todos los proyectos

Este paradigma no mapa bien a Mercurial desde you can't clone a single directory of a mercurial repo. Entonces mi pregunta es: ¿cuál es la forma más común de almacenar grandes proyectos estrechamente relacionados en mercurial?

Mis ideas:

• múltiples repositorios - pierde historial de los archivos que se mueven entre los proyectos
• Forests - parece estancado, y no estoy seguro de la estabilidad de esta extensión es
• ramas nombradas con su mayoría contenido no relacionado
• SubRepos - Desafortunadamente estoy ejecutando Ubuntu 9.04, que solo envía hg 1.1.2. De lo contrario, esto se vería como una buena opción

Answer 1

Múltiples repositorios, Bosques y SubRepos son todas las variantes de la misma idea. Bosques y SubRepos solo facilitan la administración de proyectos que también usan versiones extremadamente recientes de otros proyectos, no resuelven el problema básico que usted tiene, que es que pierde el historial de archivos al moverlos entre proyectos.

En mi opinión, su mejor opción es colocar todos los directorios en el mismo repositorio y esperar a que la función Mercurial permita el pago de los subdirectorios. La función de subdirectorio es una de las que le importa al equipo de Mercurial, pero tampoco es trivial, por lo que aún no se ha hecho. Conozco las partes internas de Mercurial, y definitivamente es factible, solo un montón de trabajo.

La segunda mejor opción, aunque la considero realmente fea, es la idea de ramas nombradas que mencionaste. Sin embargo, aún tendrá una operación de fusión muy extraña para realizar cada vez que quiera copiar archivos entre sucursales.Se llevará a cabo los siguientes pasos:

1. actualización a la cabeza de la rama que desea copiar el archivo en: hg update -C project1
2. Combinar en la rama que desea copiar el archivo desde: HGMERGE=/bin/false hg merge -r project2
3. Revertir a la cabeza de la rama que desea copiar el archivo en: hg revert -a --no-backup -r project1
4. Revertir el archivo específico que desea copiar desde la revisión de cabecera de la fusionado en la rama: hg revert --no-backup -r project2 path/to/file/in/project2.txt
5. mover el archivo a su lugar en la rama que desea copiar eso a: hg mv path/to/file/in/project2.txt project1/file/path/project2.txt
6. Marque la fusión como resolvió: hg resolve -am
7. Y finalmente comprometer el resultado: hg commit -m "A merge to copy project2.txt to project1."

Como ya he dicho, muy feo. Y bien podría funcionar solo en hg 1.3 ya que sé que algunos errores importantes en la interacción de revertir, fusionar y resolver se arreglaron bastante recientemente. (En mi humilde opinión, sospecho que Ubuntu está deliberadamente atrasado en las versiones de los sistemas de control de versiones que no son bzr.)

¿Con qué frecuencia esperas estar copiando archivos entre proyectos? ¿Por qué sucedería? ¿Estás seguro de que perder historia sería tan malo?

He hecho algo similar en Subversion para un par de proyectos propios, pero mi experiencia es que mi sentimiento inicial sobre qué proyecto realmente pertenecía a algo era generalmente correcto, y cuando no preservaba la historia no era Es realmente un gran negocio ya que la historia realmente solo era relevante para el proyecto original en el que se encontraba el archivo.