Rendre les définitions externes de SVN infaillibles?

Question

J'ai un ensemble d'applications qui reposent toutes sur une bibliothèque multi-plateforme (développement interne), et tout est stocké dans subversion. Maintenant, cette bibliothèque fait partie de chaque application et en tant que telle une copie de celui-ci doit être dans le répertoire de travail de chaque application. Afin de pouvoir revenir à n'importe quelle version d'une application et d'avoir la version correcte de la lib, une option serait de conserver une copie de la lib dans le projet, mais c'est un cauchemar à maintenir.

Plus élégant semble être d'utiliser la fonctionnalité externals definitions de subversion. Cependant, il semble nécessaire d'utiliser des numéros de révision explicites pour s'assurer à 100% que la révision correcte est affectée (par exemple, si le tronc ou une balise ou une branche ont été spécifiés sans numéro de révision, il semble que vous ne pouvez pas être 100% Assurez-vous que vous obtiendrez EXACTEMENT la même révision que par exemple il y a un an, car les gens peuvent toujours commettre sur le tronc/branche/tag).

Maintenant, cette bibliothèque est en développement constant, car elle est fondamentalement le cœur de notre application multi-plateforme. Donc, maintenir les révisions dans le svn: accessoire externe nécessitera une mise à jour constante. Il est également fréquent que les développeurs apportent des modifications à leur copie locale (corrections de bogues, nouvelles fonctionnalités), puis les commettent. Je crains maintenant que si je le configure en utilisant des révisions, il sera plus difficile de savoir où va exactement ce commit (par exemple, les devs peuvent perdre la trace que le dep est sur une branche, aussi en commit, il sera engagé en haut) du tronc/branche, en sautant éventuellement d'autres commits par d'autres développeurs). Fondamentalement, il semble que même avec des définitions externes, les devs qui travaillent avec cela auront encore besoin de maintenir une certaine quantité de contrainte et de contrôle pour gérer ceci (voir par exemple example on SO). Idéalement, ils devraient être assez intelligents pour le faire, mais (à en juger par moi-même) l'oubli de ces petits détails est assez commun et peut causer beaucoup de maux de tête plus tard. Donc, ce que je cherche est une solution vraiment infaillible (s'il y en a une) à ce problème de garder cette lib synchronisée avec plusieurs projets d'une manière que je puisse remonter dans le temps et obtenir toujours le corriger les versions ensemble sans avoir à être constamment à l'affût.

Answer 1

Ce qui peut aider est de restreindre l'accès écriture/validation au dossier des étiquettes et d'utiliser des étiquettes dans svn: externals au lieu des numéros de révision. (c'est-à-dire avec svnperms)

Ainsi, les utilisateurs ne peuvent pas commettre accidentellement à de mauvais endroits mais doivent choisir consciemment la branche/le tronc où le changement appartient.

Answer 2

En utilisant svn: externals est très bien (avec des révisions), mais il semble que si vous avez besoin d'utiliser un serveur de build (comme Hudson) qui construit automatiquement quand les choses sont vérifiées dans ce détectera directement lorsque les développeurs font. changements locaux et oublier de mettre à jour les externals.

Answer 3

Vous pouvez utiliser Vendor Branches.

Answer 4

Le problème avec votre problème est que votre bibliothèque n'est pas une bibliothèque, du moins pas dans le sens strict de l'expression.

Votre «bibliothèque» est mieux décrite comme un projet qui est partagé par les équipes qui travaillent sur les différentes applications qui dépendent de ce noyau. Dans ce contexte, le plus gros problème n'est pas la technique de subversion que vous pouvez choisir d'utiliser, mais la façon dont vous organisez votre équipe afin de réaliser une collaboration utile sur ce composant de base.

Et le genre de problèmes qui peuvent survenir sont au moins deux. Premièrement, comme les différentes applications peuvent avoir besoin de comportements différents de votre noyau, si elles ne se coordonnent pas bien, un commit parfaitement valide d'une équipe va casser les autres (l'intégration continue devrait aider ici).

Mais le deuxième problème est plus difficile à résoudre, même avec une bonne communication inter-équipe, et il est lié à la gestion des versions. Si les applications dépendant de ce noyau sont lancées à des moments différents, vous aurez du mal à obtenir un noyau stable suffisant pour la sortie de l'une des applications sans interrompre le développement du reste.

Ma suggestion, avoir quelqu'un dédié à s'occuper de la bibliothèque de base. Utilisez une branche dans chaque projet et laissez les développeurs d'applications s'y engager tout en veillant à ce qu'ils discutent des changements avec tout le monde, en particulier le superviseur de la bibliothèque. Enfin, faites en sorte que ce superviseur de bibliothèque soit chargé de coordonner les fusions des modifications apportées par les différentes équipes au tronc de la bibliothèque, générant ainsi des versions stables et testées qui seront utilisées par les versions stables de vos applications. . Et après chaque lancement du noyau, générer la prochaine génération de branches dans le reste des projets.

Cela ressemble à beaucoup de travail par rapport à la définition d'un externe et que tout le monde y s'engage. Mais en réalité, il ne sert à rien de cacher le fait que vous devez faire des efforts pour garder votre bibliothèque centrale cohérente. Si vous ne le faites pas dès le départ, il vous poursuivra plus tard.