Alors, je connais déjà cela: http://svnbook.red-bean.com /en/1.5/svn.advanced.vendorbr.html
Ma question est de savoir comment gérez-vous une branche de fournisseur qui a à la fois une libération stable et une branche alpha / bêta que vous souhaitez intégrer?
Alors, dites-vous que vous suivez l'exemple original du livre SVN. Vous auriez:
svn: // localhost / home / svn / vendeur / libcomplex / actuel
svn: //localhost/home/svn/vendor/libcomplex/1.0
svn: //localhost/home/svn/vendor/libcomplex/1.1 (identique au courant)
Maintenant, dites que vous avez deux versions de votre propre application 'Calc' ':
calc (c'est essentiellement coffre == Calc 2.0)
CALC-1.0 (publié au public)
Disons que CALC-1.0 utilise LibComplex 1.0 et Calc (dans le coffre) utilisé libifflex 1.1, qui est toujours en cours de développement.
Il y a un bogue dans LibComplex 1.0 et une nouvelle version est libérée pour résoudre ce bogue: libifflex 1.0.1. Les responsables de la LibComplex ont également inclus ce bugfix dans LibComplex 1.1.
Vous n'êtes pas prêt à libérer Calc 2.0, vous devez donc intégrer libcomplex 1.0.1 dans votre branche de fournisseur, puis mettre à jour CALC-1.0 pour effectuer une version de bug-correction.
Où va-t-il?
Vous ne pouvez pas la mettre à svn: // localhost / home / svn / vendeur / libifflex / actuel car 1.1 vit actuellement là-bas.
Copiez-vous svn: //localhost/home/svn/vendor/libcomplex/1.0 à svn: //localhost/home/svn/vendor/libcomplex/1.0.1 puis apporter la nouvelle version? De cette façon, vous pouvez utiliser SVN pour fusionner le diff entre 1,0 et 1,0,0,1 à CALC-1.0.
3 Réponses :
La pratique recommandée est de créer une branche pour votre libération. De cette façon, peu importe les changements que vous faites dans le coffre à vos dossiers de fournisseurs. Vous pouvez ensuite mettre à jour la branche de la version 1.0 avec la version 1.0.1 de libcomplex, et qui ne serait pas affecté le tronc (calc 2.0).
Cela ne fonctionnera pas si calc 1.0 et 2.0 calc vivent côte à côte dans la même branche cependant. p>
La prochaine chose à faire est de ne pas avoir « courant ». Il suffit de se référer directement à la version que vous utilisez. par exemple, laisser votre structure de dossier que: p>
vendor/libcomplex/1.0 vendor/libcomplex/1.1 vendor/libcomplex/1.0.1
Dans mon exemple précédent, j'ai une succursale pour ma version: Calc 1.0. Les dossiers du fournisseur ne sont pas contenus sous Calc. Suggérez-vous que / fournisseur soit ramifié aussi? Pour être clair ici, c'est l'exemple que je décrivant: / Vendor / LibComplex / / Calc / coffre / / /calc/branches/1.0/ Votre suggestion ne doit pas utiliser "Courant" et utilisez simplement les structures de dossiers ne permettront pas de la fusionner. Changements entre les versions dans le tronc, vaincre ainsi le but. Vous avez besoin de cet historique de changement pour permettre la fusion de modifications dans le coffre où vous avez modifié la source du fournisseur d'origine.
Mon approche est pour des travaux lorsque tout ce que vous faites est d'utiliser des versions libérées. Si vous modifiez également la source, vous pouvez également être utile pour traiter le code du fournisseur comme votre propre code (c.-à-d. Inclure-la dans votre branche de réseau plutôt qu'un fournisseur de dossier séparé). Cependant, votre approche a du sens aussi bien. Créez la branche Vendor / LibComplex / 1.0.1, fusionner toutes les personnalisations et mettre à jour la version Calc 1.0 sur Point sur Vendor / LibComplex / 1.0.1, puis publiez CALC 1.0.1. Chaque fois que liberclex 1.1 est prêt, fusionnez des personnalisations, construisez CALC2.0 et vous êtes prêt à partir. Tronc ne pointe jamais à 1.0.1
L'idée derrière les branches de fournisseurs semble être qu'ils devraient refléter ce que le dépôt propre du vendeur pourrait ressembler. Donc, Compte tenu de cela, la réponse à la question devient assez claire. Afin d'avoir publié 1,0, 1.1 et ensuite 1.0.1, le fournisseur dispose probablement d'une branche pour les versions 1.0.x BugFixed tout en continuant de fonctionner sur des versions 1.1 et ultérieures sur leur tronc. Notre branche de fournisseur devrait refléter cette configuration.
C'est-à-dire que nous avons également besoin d'une succursale (dans notre branche de fournisseur) pour les versions 1.0.x BugFixed. Cela devrait être créé à partir de courant au moment où il contenait 1,0 et peut être nommé quelque chose comme actuel représente le coffre du fournisseur et les versions marquées représentent les étiquettes propres du fournisseur, créées lors de la publication de chaque version.
actuel-1.0.x . Cette branche peut ensuite être mise à jour pour tenir 1.0.1, qui peut ensuite être étiquetée et copiée dans notre propre arbre comme d'habitude.
Je travaille comme celui-ci avec des bibliothèques externes: où Diffusion maintenant Je suis probablement dans la minorité, mais j'aime fournisseur / SVN CP Vendor / Vendor / Libcomplex / 1.0 MyPatched-Vendor / LibComplex / 1.0 Code> devrait vous donner des correctifs à fusionner dans la version 1.0.1 Importés CODE> . P> PROJET DE CHECKET / MYPROJECTION / MYPROJECT / MYPROJECT / MYPROJEL CODE> Dans Vous Vérifiez Exécuter. P> libcomplex -r21 UPSTREAMURLTO/mypatched-vendor/libcomplex/trunk