svn - Diseño de repositorio mercurial para múltiples sucursales.

version-control project-management (1)

Tengo una serie de proyectos cuasi relacionados que quiero controlar la versión. En SVN los configuraría como directorios múltiples 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 este diseño tiene ventajas:

Puedo copiar archivos entre ramas mientras preservo el historial
Solo puedo ver un subconjunto de proyectos, por ejemplo, svn co repo/project2; svn co repo/database svn co repo/project2; svn co repo/database . Esto ahorra una cantidad considerable de almacenamiento y tiempo si el proyecto 1 es grande.
Gestión sencilla del repositorio, ya que el acceso de los usuarios se define una vez para todos los proyectos

Este paradigma no se correlaciona bien con mercurial, ya que no se puede clonar un solo directorio de un repositorio mercurial . 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 el historial de archivos que se mueven entre proyectos
Forests - parece estancado, y no estoy seguro de cuán estable es esta extensión
Ramas nombradas con contenido mayoritariamente no relacionado
SubRepos - Desafortunadamente, estoy ejecutando Ubuntu 9.04, que solo se envía hg 1.1.2. De lo contrario esto parecería una buena opción.

Múltiples repositorios, Bosques y SubRepos son todas variantes en la misma idea. Forests y SubRepos simplemente facilitan la administración de proyectos que también utilizan versiones extremadamente recientes de otros proyectos, no resuelven el problema básico que tiene, que es la pérdida del historial de archivos al moverlos entre proyectos.

En mi opinión, lo mejor es colocar todos los directorios en el mismo repositorio y esperar a que la función Mercurial permita la verificación de los subdirectorios. La característica del subdirectorio es una que le importa al equipo de Mercurial, pero tampoco es trivial, por lo que aún no se ha hecho. Sin embargo, conozco los aspectos internos de Mercurial, y es definitivamente factible, solo un montón de trabajo.

La segunda mejor opción, aunque considero que es realmente fea, es la idea de las ramas nombradas que mencionaste. Aún así tendrás una operación de combinación muy extraña para realizar cuando quieras copiar archivos entre ramas. Va a realizar estos pasos:

Actualice al jefe de la rama en la que desea copiar el archivo en: hg update -C project1
Combine en la rama de la que desea copiar el archivo: HGMERGE=/bin/false hg merge -r project2
Vuelva al encabezado de la rama en la que desea copiar el archivo en: hg revert -a --no-backup -r project1
Revertir el archivo específico que desea copiar de la revisión de encabezado de la combinación en la rama: hg revert --no-backup -r project2 path/to/file/in/project2.txt
Mueva el archivo a su lugar en la rama en la que desea copiarlo: hg mv path/to/file/in/project2.txt project1/file/path/project2.txt
Marque la fusión como resuelta: hg resolve -am
Y finalmente confirme el resultado: hg commit -m "A merge to copy project2.txt to project1."

Como dije, muy feo. Y puede que solo funcione bien en hg 1.3, ya que sé que algunos errores importantes en la interacción de revertir, fusionar y resolver se solucionaron bastante recientemente. (En mi humilde opinión, sospecho que Ubuntu está atrasado a propósito en versiones de sistemas de control de versiones que no son bzr).

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

He hecho algo similar en Subversion para un par de proyectos propios, pero mi experiencia es que mi opinión inicial sobre a qué proyecto pertenecía realmente era correcta, y cuando no se conservaba la historia no era realmente tan grande un acuerdo, ya que la historia solo era relevante para el proyecto original en el que se encontraba el archivo.