Comment organisez-vous votre référentiel de contrôle de version?
Tout d'abord, je sais à ce sujet: Comment voulez-vous organiser un dépôt Subversion pour les projets de logiciels?
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 renvois
\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
\trash /*each member of the team has trash 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)
C'est 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?
- Êtes-vous sûr que vous voulez dire "thrash" ? Ou plutôt "trash" ?
Vous devez vous connecter pour publier un commentaire.
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 des bibliothèques
Je recommande (le bœuf):
Définir chaque projet afin de produire une seule tâche principale, comme une .DLL, .EXE ou .JAR (par défaut par Visual Studio).
Structure de chaque projet comme un répertoire de l'arbre avec une racine unique.
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).
Envisager de nAnt pour .Projets NET sur Windows, ou quelque chose de similaire en fonction de votre système d'exploitation, la plate-forme cible, etc.
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
.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
.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.
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).
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
.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).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
.Ne JAMAIS permettre à 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.Ne JAMAIS permettre à 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
.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.
De tenter de réduire le nombre de variables d'environnement, vous devez créer la configuration de chaque machine.
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).
Ne PAS mettre 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.
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.
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.
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.
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).
É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. Retour vers le haut, le long de avec votre référentiel de contrôle source.
Établir un serveur d'intégration continue (machine de compilation) avec AUCUN des outils de développement que ce soit.
Envisager un outil pour gérer vos bibliothèques externes et des livrables, telles que le Lierre (utilisé avec Ant).
Ne PAS utiliser Maven--il va d'abord vous rendre heureux, et éventuellement vous faire pleurer.
Remarque 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
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.
Je crois que Pragmatique de Contrôle de Version à l'aide de la Subversion a tout ce dont vous avez besoin pour organiser votre référentiel.
Nous avons réglé le nôtre jusqu'à presque exactement ce que vous avez posté. Nous utilisons la forme générale:
Alors que je suppose que pas aussi complète que votre exemple, il a bien fonctionné pour nous et nous permet de garder les choses séparées. J'aime l'idée que chaque utilisateur d'avoir un "Thrash" dossier - à l'heure actuelle, ces types de projets ne se retrouvent pas dans le contrôle de Source, et j'ai toujours senti qu'ils le devraient.
Pourquoi tout avoir dans un seul référentiel? Pourquoi ne pas simplement avoir un référentiel pour chaque projet (je veux dire "Solution")?
Bien, au moins j'ai utilisé pour le projet-par-référentiel-approche. Votre structure de référentiel semble trop compliqué pour moi.
Et combien de projets avez-vous un plan pour les mettre dans ce grand dépôt? 2? 3? 10? 100?
Et que faites-vous lorsque vous annulez le développement d'un projet? Juste le supprimer à partir du référentiel de l'arbre, de sorte qu'il sera difficile de trouver à l'avenir. Ou de le laisser traîner à jamais? Ou si vous souhaitez déplacer un projet à un autre serveur?
Et le désordre de tous ces numéros de version? Les numéros de version d'un projet comme 2, 10, 11, tandis que l'autre va comme 1, 3, 4, 5, 6, 7, 8, 9, 12...
Peut-être que je suis fou, mais j'ai comme un projet par référentiel.
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 la libération), 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 tout solution.
Pour ajouter le chemin d'accès relatif question:
Je ne suis pas sûr que c'est un problème:
Juste la caisse Solution1/coffre sous le répertoire nommé "Solution 1", idem pour Solution2: l'objectif des "répertoires" en réalité représentant des branches est de ne pas être visible une fois importé dans un espace de travail. D'où les chemins relatifs sont possibles entre "la solution 1' (en fait la solution 1/trunk") et "Solution2' (Solution2/tronc).
RE: le chemin relatif et partagé problème de fichier -
Il semble que c'est svn spécifique, mais qui n'est pas un problème. Une autre personne a déjà mentionné distinct des référentiels et c'est probablement la meilleure solution je pense, dans le cas où vous avez différents projets se référant à l'arbitraire d'autres projets. Dans le cas où vous n'avez pas de fichiers partagés alors que l'OP solution (ainsi Que beaucoup d'autres) fonctionnent bien.
Nous sommes encore en train et j'ai 3 différents efforts (différents clients) que j'ai à résoudre maintenant puisque j'ai pris en charge la configuration soit inexistants, soit pauvres de contrôle de version.
J'ai une mise en page similaire, mais mon tronc, les branches, les balises tout le chemin en haut. Donc: /trunk/main/, /trunk/utils /branches/presse/, etc.
Cela a fini par être vraiment pratique quand nous avons voulu essayer d'autres systèmes de contrôle de version, car de nombreux outils de traduction qui a le mieux fonctionné avec le manuel de base SVN mise en page.