Desarrollo de una biblioteca en sistema de control de versiones distribuidas (bazar)

Soy relativamente nuevo en bazar (principalmente cvs, luego subversión, y en mi trabajo actual estamos usando SourceUnsafe). Mi entorno de desarrollo actual está estructurado de esta manera:

 \ dev (repository compartido)
   \el maletero
     \ project1 (twig)
     \ project2 (twig)
   \ twigs
     \ proj1-bugfix123 (twig de \ trunk \ project1)
     \ proj1-featureA (twig de \ trunk \ project1)

Ahora, si decido que ciertos aspectos del proyecto1 serían más adecuados como una biblioteca (o un ensamblaje, ya que es un proyecto de CA) en lugar de classs dentro del proyecto, ¿cuál sería el mejor enfoque para estructurar esto en el bazar? He encontrado dos posibilidades que creo que son viables. El primero, creo que es el path "correcto".

 \ dev (repository compartido)
   \el maletero
     \ project1 (twig)
     \ project2 (twig)
     \ libXXX
   \ twigs
     \ proj1-bugfix123
       \ main (twig de \ trunk \ project1)
       \ libXXX (twig de \ trunk \ libXXX)
     \ proj1-featureA
       \ main (twig de \ trunk \ project1)
       \ libXXX (twig de \ trunk \ libXXX)

El problema con esto es que ahora tengo que recordar actualizar el file de solución para include los proyectos correctos cada vez que hago una sucursal y no retroceder, y también para recordar llevar los cambios al proyecto y a la biblioteca al mismo time hora (por ejemplo, si la característica A en el proyecto 1 requiere cambios en libXXX para que funcione).

 \ dev (repository compartido)
   \el maletero
     \ project1 (twig)
     \ project2 (twig)
       \ libXXX
   \ twigs
     \ proj1-bugfix123 (twig de \ trunk \ project1)
       \ libXXX
     \ proj1-featureA (twig de \ trunk \ project1)
       \ libXXX        

Los problemas con este enfoque son que si otro proyecto, digamos project3 quería usar libXXX y estar en control de fuente, necesitaría ser una twig de project1, con los files de project1 eliminados. Sería desorderado

Supongo que hay una tercera opción para que todo el baúl sea una bifurcación como en la subversión, pero eso parece estar en contra de la forma en que las cosas que creo que se supone que deben funcionar en el bazar.

Si esto se hiciera en SourceSafe, simplemente lo haría como el segundo ejemplo, pero tengo las carpetas libxxx en ambos lugares, pero compartido, ya que ese es el único mecanismo en el que sourcesafe tiene que hacerlo.

¿No le gustaría que las nuevas bibliotecas tengan su propia solución y que se construyan como parte de eso y luego se refieran a los otros proyectos? De esta forma, la biblioteca solo tiene una versión en construcción (en lugar de una por solución)

Todavía no hay una solución simple en bzr. Necesita soporte para treees nesteds, pero aún no está implementado ( http://bazaar-vcs.org/NestedTreeSupport ), pero puede que lo esté pronto.

Hay una herramienta antigua llamada config-manager ( https://launchpad.net/config-manager ).

También hay un nuevo complemento para bzr llamado scmproj ( https://launchpad.net/bzr-scmproj ), ahora es alfa y está en desarrollo activo.

Hasta que se arregle el soporte de treees nesteds en Bazar, o Bazaar desarrolla algo parecido a 'Externos' de Subversión (si los entiendo correctamente), su flexibilidad para include bibliotecas en el tree de una twig de Bazar es limitada.

Hasta entonces, mantenga la biblioteca como un proyecto separado en una bonita 'sucursal' limpia. Si necesita la biblioteca incluida en un proyecto, como sus files están dentro del tree propio del proyecto, cópielos. Si realiza algún cambio en los files de esa biblioteca que desea contribuir de nuevo a la biblioteca, vuelva a colocar los cambios en su twig local de esa biblioteca y fusione / confirme allí.