Comment gérer les dépendances externes qui sont constamment modifiées

Question

Notre développement utilise beaucoup de code open-source et j'essaie de trouver la meilleure façon de gérer ces dépendances externes.

Notre configuration actuelle:

• nous développons pour Linux et Windows
• Nous utilisons svn pour notre propre code
• dépendances externes (boost, log4cpp, etc.) ne sont pas stockés dans svn. Au lieu de cela je les mets sous ./extern (ou c: \ extern sur windows). Je ne veux pas les mettre dans notre dépôt parce que je ne pourrai pas les mettre à jour de cette façon. Certains d'entre eux sont constamment mis à jour.

Mes questions

• Que faire si je dois modifier le code externe? Actuellement, j'ai créé un dossier dans mon référentiel svn appelé extern_hacks et c'est là que j'ai mis le code externe modifié. Je lie ensuite (ou copie sur Windows) les fichiers dans la structure de répertoire externe. Cette solution est problématique car il est difficile de garder trace des fichiers, et très difficile à mettre à jour depuis svn quand les fichiers sont assis dans deux dépôts (le mien pour les fichiers modifiés, et le référentiel original dit sourceforge)

• Comment gérer les versions de dépendances externes?

Je suis curieux de savoir comment les autres traitent ces problèmes. Merci.

Answer 1

Je les garde dans svn, et les gère comme vendor branches. En les gardant lâches à l'extérieur, il est très difficile de revenir à une version précédente ou de corriger des bogues dans une version précédente (en particulier si le bogue provient d'une modification de la dépendance externe)

mal de tête, et vous permet également d'obtenir un nouveau poste de travail capable de travailler rapidement sur votre base de code.

Answer 2

Je ne comprends pas pourquoi vous dites

Je ne veux pas les mettre dans notre garde parce que je ne serai pas en mesure de les mettre à jour cette façon. Certains d'entre eux sont constamment mis à jour.

Vous avez vraiment besoin de

1. comprennent les dépendances externes dans votre contrôle de code source et les mettre à jour périodiquement et TESE, test, test.

2. Coordonnez votre processus de construction avec les mises à jour pour les dépendances externes.

Si votre code dépend de quelque chose, alors vous avez vraiment besoin de contrôler quand il est mis à jour/modifié. Coder dans un espace où ces dépendances peuvent être mises à jour à tout moment est trop douloureux comme vous le savez sans doute. Personnellement, je préfère l'option 1.

Answer 3

Avez-vous considéré Maven?C'est un système de construction qui a un excellent support pour la gestion des dépendances. Pour chaque projet, vous pouvez spécifier les dépendances requises dans un fichier xml dans le cadre de ce projet. Les bibliothèques externes sont conservées dans un référentiel de dépendances (dans notre cas, Artifactory). Ceci est distinct de votre système de contrôle de version et peut être simplement un lecteur réseau. Il permet également de gérer différentes versions de projets.

Answer 4

Lorsque j'ai dû faire quelque chose comme ça, j'ai ajouté la source externe comme externe, puis j'ai appliqué un patch. Le patch contient mes modifications à la source externe. Donc, en fait, seule la version contrôle mes patchs. La plupart du temps cela fonctionne, s'il n'y a pas de changements "dramatiques" dans le code externe.

Answer 5

Je serais prudent compte tenu Maven parce que:

• il est un autre dépôt dans un système où vous avez déjà un référentiel avec votre système de contrôle de version; (Maven) est basé sur le seul "contrôle de version commun" de chaque développeur, le système de fichiers (ce qui signifie pas de métadonnées, ou de propriétés attachées au fichier, pas d'historique de qui a modifié quoi et quand)

maintenant, lorsqu'ils traitent avec des tiers, vous pouvez envisager de les avoir dans votre système de contrôle de version, mais d'une manière conditionnée: qui est une manière très compacte, avec des sources et documentations zippées, afin de avoir le moins de fichiers possible.

De cette façon, vous allez gérer le déploiement de ces (nombreux) bibliothèques tierces facilement puisque le nombre de fichiers à déployer est faible. De plus, les avoir sous contrôle de source vous permet de créer une branche (par exemple, une branche 'hack'), dans laquelle vous allez stocker la version empaquetée (ou zippée) de la bibliothèque piratée. Ce que vous pouvez stocker de manière externe est l'ensemble complet non compressé des fichiers représentant ces bibliothèques, car il n'y a pas de développement réel sur eux, ou juste un hack ponctuel: normalement, votre travail n'est pas de développer des bibliothèques existantes , mais de les utiliser (même un peu modifié) pour implémenter plus rapidement certaines fonctionnalités de votre projet.

Si vous avez besoin de comparer une version piratée avec une version officielle, vous devrez simplement retirer de svn le numéro de version piraté approprié, décompressez-le et comparez-le avec l'officiel (et stocké en externe) version (avec winmerge par exemple)