Je suis encore un autre utilisateur de Subversion qui a du mal à me rééduquer dans le Tao du contrôle de version distribué.
Lorsque j'utilisais Subversion, j'étais un grand fan de l'approche des projets mineurs et, avec la plupart de mes anciens employeurs, nous structurions nos succursales de référentiel; balises et tronc comme suit:
branches-+
+-personal-+
| +-alice-+
| | +-shinyNewFeature
| | +-AUTOMATED-+
| | +-shinyNewFeature
| +-bob-+
| +-AUTOMATED-+
| +-bespokeCustomerProject
+-project-+
+-shinyNewFeature
+-fixStinkyBug
tags-+
+-m20110401_releaseCandidate_0_1
+-m20110505_release_0_1
+-m20110602_milestone
trunk
Dans l'arborescence source proprement dite, nous utiliserions (quelque chose comme) la structure suivante:
(src)-+
+-developmentAutomation-+
| +-testAutomation
| +-deploymentAutomation
| +-docGeneration
| +-staticAnalysis
| +-systemTest
| +-performanceMeasurement
| +-configurationManagement
| +-utilities
+-libraries-+
| +-log-+
| | +-build
| | +-doc
| | +-test
| +-statistics-+
| | +-build
| | +-doc
| | +-test
| +-charting-+
| | +-build
| | +-doc
| | +-test
| +-distributedComputing-+
| | +-build
| | +-doc
| | +-test
| +-widgets-+
| +-build
| +-doc
| +-test
+-productLines-+
| +-flagshipProduct-+
| | +-coolFeature
| | +-anotherCoolFeature
| | +-build
| | +-doc
| | +-test
| +-coolNewProduct
+-project-+
+-bigImportantCustomer-+
| +-bespokeProjectOne
| +-bespokeProjectTwo
+-anotherImportantCustomer-+
+-anotherBespokeProject
L'idée était (et est toujours) d'utiliser la structure du référentiel pour aider à structurer la communication entre l'équipe d'ingénierie; la partie client de l'entreprise et divers autres intervenants et experts du domaine.
À savoir: les documents sources qui se trouvent dans l'un des répertoires "projet" ne sont utilisés (et gagnent de l'argent) qu'une seule fois. Les documents qui se trouvent dans l'un des répertoires "productLines" gagnent de l'argent autant de fois qu'un produit de cette ligne particulière est vendu. Les documents qui se trouvent dans l'un des répertoires des "bibliothèques" gagnent de l'argent autant de fois que n'importe lequel des produits qui les utilisent est vendu.
Il rend explicite la notion d'amortissement des coûts et aide à renforcer la prise en charge de la réutilisation des documents source dans toute l'entreprise.
Cela signifie également qu'il existe une structure commune sur laquelle nos outils d'automatisation de construction peuvent fonctionner. (Nos scripts de construction parcourent l'arborescence source à la recherche de dossiers "build" dans lesquels ils trouvent des fichiers de configuration spécifiant comment chaque composant doit être construit; un processus similaire se produit pour la génération et le test de la documentation).
De manière significative, les produits sur lesquels je travaille prennent généralement beaucoup de temps pour exécuter des tests de mesure et de caractérisation des performances; de 20 à 200 heures; générer quelque part entre plusieurs Go et plusieurs To de résultats de test / données intermédiaires traités (qui doivent être stockés et liés à une configuration de système particulière afin que l'amélioration des performances au fil du temps puisse être mesurée). Ce problème fait de la gestion de la configuration une considération importante et impose également une certaine exigence de centralisation, car généralement les ressources de calcul nécessaires pour exécuter les tests de mesure et de caractérisation des performances sont limitées; (un petit groupe de 64-128 cœurs).
Comme une dernière note; le système d'intégration continue sait qu'il doit déclencher une construction; analyse statique; test de fumée et test unitaire exécutés chaque fois que le tronc est modifié, chaque fois qu'une branche "tag" est modifiée, et chaque fois qu'une branche "AUTOMATISÉE" est modifiée. De cette façon, les développeurs individuels peuvent utiliser le système CI avec leurs branches personnelles, une capacité importante, à mon humble avis.
Maintenant, voici ma question: comment puis-je reproduire tout ce qui précède (et l'améliorer, si possible), avec Mercurial.
--Éditer:
Ma réflexion actuelle consiste à utiliser un référentiel Subversion central, à définir la structure globale, mais à autoriser l'utilisation de hg en tant que client afin que les développeurs puissent avoir des référentiels disponibles localement.