Ces messages semblent liés, mais mon cerveau commence à fondre, essayant d'y réfléchir: P
Mon employeur vient de commencer à utiliser le contrôle de code source, principalement parce qu'avant d'embaucher plus de développeurs, le «référentiel» était le disque dur du seul développeur, qui travaille principalement à domicile. Tout le code .NET qu'il avait écrit a été vérifié en masse , et il y a beaucoup de fonctionnalités dupliquées (lire: copier-coller). En ce moment, notre système SCM est une sauvegarde glorifiée.
Je voudrais extraire une partie du code dupliqué dans des bibliothèques partagées. Je laisse le dépôt d'origine seul pour ne rien casser - nous pouvons déplacer et / ou refactoriser le code existant au fur et à mesure des besoins. J'ai donc mis en place un dépôt uniquement pour le nouveau code, y compris les bibliothèques.
Mon problème tourne autour de la version des bibliothèques sans nous refléter dans un processus excessif: ayant reconnu que nous avons besoin d'une approche plus cohérente, avec plus de développeurs écrivant tous du code très similaire, la direction et les autres développeurs sont ouverts à la réorganisation des choses, mais ce ne sera probablement pas le cas descendez bien si la solution commence à affecter la productivité.
La solution idéale dans mon esprit obsessionnel est de construire les bibliothèques séparément, chaque projet dépendant étant construit contre des versions compatibles délibérément choisies. De cette façon, nous savons exactement quels clients ont quelles versions de quelles bibliothèques, peuvent reproduire de manière plus fiable les bogues, maintenir des branches de publication indépendantes pour les produits et les bibliothèques, et ne pas casser les projets les uns des autres lors du changement de code partagé.
Cela rend cependant la mise à jour des bibliothèques fastidieuse, en particulier pour le développeur qui travaille à domicile. Je m'attends à ce que les bibliothèques changent rapidement, au moins au début alors que nous (enfin) rassemblons les bits communs. Il est tout à fait possible que j'y réfléchisse complètement et nous serions bien de tout construire en fonction des commits de bibliothèque les plus récents, mais j'aimerais au moins être prêt pour le jour où nous déciderons que certains composants doivent être indépendamment versionnés et distribué. Le fait que certaines bibliothèques devront être installées dans le GAC rend le contrôle de version particulièrement important.
Alors ma question est: qu'est-ce qui me manque? J'ai l'impression d'avoir fixé une solution et j'essaie maintenant de trouver des variantes qui faciliteront les changements. Quels types de stratégies avez-vous utilisés pour résoudre ce genre de problème auparavant? Je me rends compte que cette question est partout; Je ferai de mon mieux pour nettoyer et clarifier tout point d'incertitude.
Et autant que j'aimerais utiliser Mercurial, nous avons déjà dépensé de l'argent sur un SCM commercial centralisé (Vault) et la commutation n'est pas une option. En outre, je pense que le problème ici va plus loin que le choix de l'outil de contrôle de version.