Développement d'une bibliothèque dans un système de contrôle de version distribuée (bazar)

Question

Je suis relativement nouveau à bazaar (principalement utilisé cvs, puis subversion, et à mon travail actuel, nous utilisons SourceUnsafe). Mon environnement de développement actuel est structuré comme suit:

 
\dev     (shared repository) 
    \trunk 
    \project1  (branch) 
    \project2  (branch) 
    \branches 
    \proj1-bugfix123 (branch of \trunk\project1) 
    \proj1-featureA (branch of \trunk\project1) 

Maintenant, si je décide que certains aspects de project1 seraient mieux adaptés en tant que bibliothèque (ou assemblée, car il est le projet aC#) plutôt que des classes à l'intérieur du projet , quelle serait la meilleure approche pour structurer cela dans le bazar. J'ai trouvé deux possibilités qui me semblent viables. Le premier je pense est le "bon" chemin.

 
\dev     (shared repository) 
    \trunk 
    \project1  (branch) 
    \project2  (branch) 
    \libXXX 
    \branches 
    \proj1-bugfix123 
     \main   (branch of \trunk\project1) 
     \libXXX  (branch of \trunk\libXXX) 
    \proj1-featureA 
     \main   (branch of \trunk\project1) 
     \libXXX  (branch of \trunk\libXXX) 

Les problèmes avec ceci est que maintenant je dois me rappeler de mettre à jour le fichier de solution pour inclure les bons projets chaque fois que je fais une branche et de ne pas pousser ce retour, et aussi de se rappeler de pousser modifications à la fois le projet et la bibliothèque en même temps (par exemple, si featureA dans project1 nécessite des modifications de libXXX pour fonctionner).

 
\dev     (shared repository) 
    \trunk 
    \project1  (branch) 
    \project2  (branch) 
     \libXXX 
    \branches 
    \proj1-bugfix123 (branch of \trunk\project1) 
     \libXXX 
    \proj1-featureA (branch of \trunk\project1) 
     \libXXX   

Les problèmes avec cette approche sont que si un autre projet, par exemple projet3 voulait utiliser libXXX et dans le contrôle des sources, il aurait besoin d'être une branche hors de project1, avec les fichiers supprimés Projet1. Ce serait désordonné. Je suppose qu'il y a une troisième option pour que le tronc entier soit une branche comme dans subversion, mais cela semble être à l'opposé de la façon dont je pense qu'ils sont censés fonctionner dans le bazar.

Si cela était fait dans SourceSafe, je voudrais juste faire comme le deuxième exemple, mais ont les dossiers libxxx dans les deux endroits, mais partageais, puisque c'est le seul sourcesafe mécanisme doit le faire dans.

Answer 1

Ne voudriez-vous pas que de nouvelles bibliothèques aient leur propre solution et soient construites dans le cadre de cela et ensuite référencées par les autres projets. De cette façon, la bibliothèque n'a qu'une seule version en construction (au lieu d'une par solution)

Answer 2

Il n'y a pas encore de solution simple dans bzr. Vous avez besoin d'un support d'arbres imbriqués, mais ce n'est pas encore implémenté (http://bazaar-vcs.org/NestedTreeSupport), mais il le sera peut-être bientôt.

Il existe un ancien outil appelé config-manager (https://launchpad.net/config-manager).

De plus il y a un nouveau plugin pour bzr appelé scmproj (https://launchpad.net/bzr-scmproj), c'est alpha maintenant et en développement actif.

Answer 3

Jusqu'à ce que le support des arbres imbriqués dans Bazaar soit corrigé, ou Bazaar développe quelque chose comme Subversion 'Externals' (si je comprends bien), votre flexibilité dans l'inclusion des bibliothèques dans l'arborescence d'une branche Bazaar est limitée. D'ici là, maintenez la bibliothèque en tant que projet séparé dans une propre branche propre. Si vous avez besoin de la bibliothèque incluse dans un projet, par exemple si ses fichiers se trouvent dans l'arborescence du projet, copiez-les. Si vous apportez des modifications aux fichiers de la bibliothèque que vous voulez contribuer à la bibliothèque, ramenez les modifications dans votre branche locale de cette bibliothèque et fusionnez/commettez là.