Comment organisez-vous votre référentiel de contrôle de version?

Question

Tout d'abord, je sais à ce sujet: http://stackoverflow.com/questions/51217/how-would-you-organize-a-subversion-repository-for-in-house-software-projects Ensuite, la question réelle: Mon équipe est la restructuration de notre référentiel et je suis à la recherche pour les conseils sur la façon de l'organiser. (SVN dans ce cas). Voici ce que nous est venu avec. Nous avons un référentiel, plusieurs projets et plusieurs svn:externals références croisées

\commonTools /*tools used in all projects. Referenced in each project with svn:externals*/
   \NUnit.v2.4.8
   \NCover.v.1.5.8
   \<other similar tools>
\commonFiles /*settings strong name keys etc.*/
   \ReSharper.settings
   \VisualStudio.settings
\thrash /*each member of the team has thrash for samples, experiments etc*/
   \user1
   \user2
\projects
   \Solution1 /*Single actual project (Visual Studio Solution)*/
      \trunk
         \src
             \Project1 /*Each sub-project resulting in single .dll or .exe*/
             \Project2
         \lib
         \tools
         \tests
         \Solution1.sln
      \tags
      \branches
   \Solution2
      \trunk
         \src
             \Project3 /*Each sub-project resulting in single .dll or .exe*/
             \Project1 /*Project1 from Solution1 references with svn:externals*/
         \lib
         \tools
         \tests
         \Solution2.sln
      \tags
      \branches

Pour effacer le vocabulaire: Solution de produit unique, le Projet est un Projet Visual Studio (qui résulte en une seule .dll ou unique .exe)

Voilà comment nous avons l'intention de jeter le dépôt. Le principal problème est que nous avons de multiples Solutions, mais nous voulons partager des Projets parmi des Solutions. Nous avons pensé qu'il n'y a pas de point réellement dans l'évolution de ces Projets partagés pour leurs propres Solutions, et au lieu de cela nous avons décidé d'utiliser svn:externals pour partager des Projets parmi des Solutions. Nous voulons aussi tenir ensemble commun d'outils et de 3ème partie les bibliothèques en un seul endroit dans le référentiel, et leur référence dans chaque Solution avec svn:externals.

Que pensez-vous de cette configuration? En particulier à propos de l'utilisation de svn:externals. Ce n'est pas une solution idéale, mais compte tenu de tous les avantages et les inconvénients, c'est le mieux que nous pouvions penser. Comment le feriez-VOUS?

Answer 1

Si vous suivez mes recommandations ci-dessous (que j'ai depuis des années), vous serez en mesure de:

- mettre chaque projet n'importe où dans le contrôle de source, aussi longtemps que vous le préserver la structure à partir du répertoire racine du projet sur la baisse de l'

-- la construction de chaque projet n'importe où sur n'importe quelle machine, avec un minimum de risque, et le minimum de préparation

-- la construction de chaque projet complètement autonome, aussi longtemps que vous avez accès à ses dépendances binaires (locale "bibliothèque" et de "sortie" répertoires)

-- construire et de travailler avec n'importe quelle combinaison de projets, puisqu'ils sont indépendants

-- construire et de travailler avec de multiples copies/versions d'un même projet, puisqu'ils sont indépendants

-- évitez d'encombrer votre source référentiel de contrôle avec les fichiers générés ou les bibliothèques

Je recommande (le bœuf):

1. Définir chaque projet afin de produire une seule tâche principale, comme une .DLL, .EXE ou .JAR (par défaut par Visual Studio).

2. La Structure de chaque projet comme un répertoire de l'arbre avec une racine unique.

3. Créer une génération automatique de script pour chaque projet dans le répertoire racine de ce qui va construire à partir de zéro, avec PAS de dépendances sur un IDE (mais ne pas l'empêcher d'être intégré dans l'IDE, si c'est possible).

4. Envisager de nAnt .Projets NET sur Windows, ou quelque chose de similaire en fonction de votre système d'exploitation, la plate-forme cible, etc.

5. Faire de chaque projet, le script de construction de référence externe (3e partie) les dépendances à partir d'un seul local partagé "bibliothèque" de répertoire, avec tous ces binaire TOTALEMENT identifiés par version: %DirLibraryRoot%\ComponentA-1.2.3.4.dll, %DirLibraryRoot%\ComponentB-5.6.7.8.dll.

6. Faire de chaque projet, le script de construction de publier le premier résultat à un seul local partagé "sortie" du répertoire: %DirOutputRoot%\ProjectA-9.10.11.12.dll, %DirOutputRoot%\ProjectB-13.14.15.16.exe.

7. Faire de chaque projet, le script de construction de référence de ses dépendances via configurable et entièrement gérés chemins absolus (voir ci-dessus) dans la "bibliothèque" et de "sortie" des répertoires, ET PAS AILLEURS.

8. Ne laissez JAMAIS un projet directement référence à un autre projet ou de son contenu--d'autoriser uniquement les références à la primaire livrables de la "sortie" du répertoire (voir ci-dessus).

9. Faire de chaque projet de construction référence de script requise, construire des outils configurable et entièrement gérés chemin d'accès absolu: %DirToolRoot%\ToolA\1.2.3.4, %DirToolRoot%\ToolB\5.6.7.8.

10. Faire de chaque projet, le script de construction de référence de la source de contenu par un chemin absolu du répertoire racine du projet: ${project.base.dir}/src, ${project.base.dir}/tst (syntaxe varie selon l'outil de construction).

11. TOUJOURS besoin d'un projet de construction de script de référence de CHAQUE fichier ou répertoire via un absolu, configurable chemin (la racine d'un répertoire spécifié par une variable configurable): ${project.base.dir}/some/dirs ou ${env.Variable}/other/dir.

12. Ne permettez JAMAIS à un projet de construction de script pour faire référence à QUOI que ce soit avec un chemin relatif, comme .\some\dirs\here ou ..\some\more\dirs, TOUJOURS utiliser des chemins absolus.

13. Ne permettez JAMAIS à un projet de construction de script pour faire référence à quelque CHOSE en utilisant un chemin absolu qui n'est pas configurable répertoire racine, comme C:\some\dirs\here ou \\server\share\more\stuff\there.

14. Pour chaque configurable racine du répertoire référencé par un projet de construction d'un script, de définir une variable d'environnement qui sera utilisé pour ces références.

15. Tentez de réduire le nombre de variables d'environnement, vous devez créer la configuration de chaque machine.

16. Sur chaque machine, créer un script shell qui définit les variables d'environnement nécessaires, ce qui est spécifique à la machine (et éventuellement spécifique à l'utilisateur, le cas échéant).

17. Ne mettez PAS la machine à la configuration spécifique d'un script shell dans le contrôle de code source; au lieu de cela, pour chaque projet, de commettre une copie du script dans le répertoire racine du projet en tant que modèle.

18. EXIGER que chaque projet de construction de script pour vérifier chacune de ses variables d'environnement, l'abandon et la un message s'ils ne sont pas définis.

19. EXIGER que chaque projet de construction de script pour vérifier chacune de ses dépendante de l'outil de génération des exécutables, des fichiers de bibliothèque externes, et dépendant de livrables de projet fichiers, et abandonner un message si ces fichiers n'existent pas.

20. RÉSISTER à la tentation de commettre l'un QUELCONQUE de fichiers générés dans le contrôle de source--non livrables du projet, aucune source généré, génération de documents, etc.

21. Si vous utilisez un IDE, générer quel que soit le projet de contrôle des fichiers que vous pouvez, et ne pas les commettre à la source de contrôle (cela inclut les fichiers de projets Visual Studio).

22. Établir un serveur avec une copie officielle de tous les outils et de bibliothèques, d'être copié/installé sur les stations de travail des développeurs et de la construction des machines. En arrière, le long de avec votre référentiel de contrôle source.

23. Établir un serveur d'intégration continue (machine de compilation) avec AUCUN des outils de développement que ce soit.

24. Considérons un outil pour gérer vos bibliothèques externes et des livrables, telles que le Lierre (utilisé avec Ant).

25. Ne PAS utiliser Maven--il va d'abord vous rendre heureux, et éventuellement vous faire pleurer.

Notez que rien de tout cela est spécifique à la Subversion, et la plupart des il est generic à des projets ciblés pour tous les systèmes d'exploitation, le matériel, la plate-forme, la langue, etc. J'ai eu un peu d'OS et d'outil spécifique de la syntaxe, mais uniquement à des fins d'illustration--j'espère que vous allez traduire à votre système d'exploitation ou un outil de choix.

Remarque supplémentaire concernant les solutions Visual Studio: ne les mettez pas dans le contrôle de source! Avec cette approche, vous n'en avez pas besoin ou vous pouvez les générer (tout comme les fichiers de projets Visual Studio). Cependant, je trouve qu'il vaut mieux laisser les fichiers de la solution pour les développeurs à créer/utiliser comme ils l'entendent (mais pas vérifié à la source de contrôle). Je garde un Rob.sln le fichier sur mon poste de travail à partir de laquelle je référence mon projet actuel(s). Depuis mes projets tous les stand-alone, je peux ajouter/supprimer des projets à volonté (ce qui signifie pas de projet basée sur la dépendance des références).

S'il vous plaît ne pas utiliser Subversion des alias (ou similaires dans d'autres outils), ils sont un anti-modèle et, par conséquent, inutile.

Lorsque vous mettez en place de l'intégration continue, ou même si vous voulez juste pour automatiser le processus de diffusion, créer un script pour ça. Faire un simple script shell qui: prend en paramètres le nom du projet (telles que listées dans le référentiel) et le nom de la balise, crée un répertoire temporaire dans un configurable répertoire racine, vérifie la source pour le nom du projet et le nom de la balise (par la construction de l'URL appropriée dans le cas de la Subversion) pour que le répertoire temporaire, effectue une nouvelle version qui exécute les tests et les paquets du livrable. Ce script shell doit travailler sur un projet et doit être vérifiée dans le contrôle de code source dans le cadre de votre "outils de construction" du projet. Votre serveur d'intégration continue pouvez utiliser ce script comme sa fondation pour les projets de construction, ou il pourrait même fournir (mais vous pourriez encore envie de votre propre).

@VonC: Vous ne voulez PAS tout le temps avec "ant.jar" plutôt que de "ant-a.b.c.d.jar" après vous êtes brûlé lors de votre script de génération des pauses parce que vous sans le savoir, il a couru avec une version incompatible de Fourmi. Ceci est particulièrement commun entre Ant 1.6.5 et 1.7.0. En généralisant, on a TOUJOURS envie de savoir quelle version spécifique de CHAQUE composant est utilisé, y compris votre plate-forme (Java A. B. C. D) et votre outil build (Ant E. F. G. H). Sinon, vous finirez par rencontrer un bug, et votre premier GRAND problème sera de traquer quelles sont les versions de vos différents composants sont impliqués. Il est tout simplement mieux de résoudre le problème de front.

Answer 2

Nous avons mis les nôtres pour correspondre presque exactement à ce que vous avez posté. Nous utilisons la forme générale:

 \Project1
   \Development (for active dev - what you've called "Trunk", containing everything about a project)
   \Branches (For older, still-evolving supported branches of the code)
       \Version1
       \Version1.1
       \Version2
   \Documentation (For any accompanying documents that aren't version-specific
 

Bien que je suppose pas aussi complet que votre exemple, cela a bien fonctionné pour nous et nous permet de garder les choses séparées. J'aime l'idée que chaque utilisateur dispose également d'un dossier "Thrash" - actuellement, ces types de projets ne se retrouvent pas dans le contrôle des sources, et j'ai toujours pensé qu'ils le devraient.

Answer 3

Je crois que Pragmatic Version Control utilisant Subversion a tout ce dont vous avez besoin pour organiser votre référentiel.

Answer 4

Je pense que le principal inconvénient de la structure proposée est que les projets communs ne seront versionné avec la première solution qu'ils ont été ajoutés (à moins que la propriété svn:externals est plus sophistiqué que je m'imagine). Par exemple, lorsque vous créez une branche pour la première version de Solution2, Projet1 ne sera pas ramifiée car il vit dans la solution 1. Si vous avez besoin pour construire à partir de cette branche à une date ultérieure (QFE), il va utiliser la dernière version de Projet1 plutôt que la version de Projet1 au moment de la branche.

Pour cette raison, il peut être avantageux de mettre les projets en commun dans une ou plusieurs solutions partagées (et donc les répertoires de niveau supérieur dans votre structure) et puis la branche avec chaque version de toute solution.