Plusieurs Dépôts SVN ou seul référentiel d'entreprise

Question

Devrions-nous avoir un référentiel unique pour l'ensemble de la société, qui contient de nombreux projets de développement, ou d'une base de projet par projet? Toutes les idées sur l'expérience et les meilleures pratiques?

Answer 1

J'ai trouvé que le fait d'avoir un seul référentiel Subversion sida dans:

1. La transparence: il est plus facile de suivre ce qui se passe, et trouver le code, même dans projets, vous pouvez ne pas être directement impliqué dans.
2. Entretien: il n'est pas nécessaire de créer des référentiels chaque fois que vous souhaitez créer un nouveau projet, et vous pouvez supprimer tous les projets sans avoir peur de perdre l'enregistrement de la Subversion.
3. Entretien: il est seulement nécessaire d'avoir un espace de stockage de sauvegarde.

EDIT: D'autres raisons:

• Révision globale id - en ayant la révision des id à l'échelle mondiale:
  1. Plus facile à communiquer (par exemple, dans une revue de code demande, il suffit de spécifier la révision id, sans avoir besoin de spécifier le projet).
  2. Plus facile de garantir l'atomicité lorsque les projets ont des dépendances les uns les autres.
  3. Plus facile de voir l' ordre de s'engage dans divers projets.

Answer 2

Personnellement, je préfère largement distincte référentiel par projet. Il y a plusieurs raisons:

1. Les numéros de révision. Chaque projet de référentiel de séparer les révisions de la séquence.

2. Granularité. Avec dépôt par le projet que vous juste ne pouvez pas faire un commit dans différents projets ayant le même numéro de révision. Je suppose qu'il est plus comme avantage, tandis que quelqu'un pourrait dire que c'est un défaut.

3. Référentiel de taille. Quelle est la taille de votre projet? A-t-elle binaires sous contrôle de code source? Je parie que c'est. Par conséquent, la taille est importante - à chaque révision de fichier binaire augmente la taille du dépôt. Finalement, elle devient maladroit et il est difficile à soutenir. Fine politique de fichiers binaires de stockage doit être pris en charge, et d'administration supplémentaires fournis. Quant à moi, je n'ai pas encore trouver comment pourrais-je les supprimer complètement de fichier binaire (commis par certains stupide d'utilisateur) et son contenu, l'histoire de référentiel. Avec dépôt par projet, il serait plus facile.

4. Intérieure référentiel de l'organisation. Je préfère fine, très organisé, autonome, structuré dépôts. Il est un diagramme illustrant général (idéal) approche du référentiel de processus de maintenance. Je crois que vous conviendrez qu'il n'est PAS POSSIBLE d'utiliser "tous les projets dans l'un des pensions de l' " approche. Par exemple, ma première structure de référentiel (chaque dépôt de projet devrait avoir) est:

   /project
       /trunk
       /tags
           /builds
               /PA
               /A
               /B
           /releases
               /AR
               /BR
               /RC
               /ST
       /branches
           /experimental
           /maintenance
               /versions
               /platforms
           /releases
   

5. Pensions de l'administration. 'Dépôt par projet' a plus de possibilités aux utilisateurs l'accès à la configuration. Il est plus complexe. Mais il est également utile de fonctionnalité: vous pouvez configurer les référentiels à utiliser le même fichier de configuration

6. Pensions De Soutien. Je préfère la sauvegarde des dépôts séparément. Quelqu'un dit que dans ce cas, il n'est pas possible de fusionner les informations à partir d'un repo dans l'autre. Pourquoi sur la terre, vous auriez besoin? Si cette fusion est nécessaire montre que l'approche initiale de la source de contrôle est mauvais. L'évolution du projet suppose ultérieure projet de séparation des submodules, pas dans l'autre sens. Et je sais qu'il y a de l'approche pour le faire.

7. svn:externals. 'Dépôt par projet" approche encourage la propriété svn:externals d'utilisation. C'est une situation saine lorsque les dépendances entre les projets et les submodules est établie à l'aide des liens souples, qui svn:externals.

   Conclusion. Si vous voulez garder le contrôle de source simple, l'utilisation d'un référentiel. Si vous voulez faire des logiciels de gestion de la configuration de la DROITE:

   1. L'utilisation de "référentiel par projet" approche
   2. Introduire rôle distinct de logiciel configuration manager et affecter les membres de l'équipe, il
   3. Location de bon administrateur, qui peut faire face à toutes subversion astuces :)

PS. Par la façon dont, malgré que je travaille avec SVN tout le temps et je l'aime, 'dépôt par projet" l'approche est pourquoi je vois DCVS systèmes plus attrayants de l'organisation du dépôt de point de vue. Dans DCVS repo est le projet par défaut. Il n'est même pas question de "simples vs multiples" possible, il serait tout simplement absurde.

Answer 3

Je recommande fortement de ne pas utiliser un référentiel par projet. Au sein d'un seul référentiel subversion, vous pouvez déplacer et copier des données et de ce qu'il faudra retenir de son histoire. Si vous décidez qu'un morceau de code qui a commencé comme un backend outil est fusionnée à l'extrémité avant, et ceux qui sont dans des référentiels différents, ce n'est pas une opération de subversion savez rien à ce sujet. Ce sera comme si vous avez ajouté quelque chose à la fin de devant de pas. Cela signifie également que vous ne pouvez pas faire fusionne si vous avez besoin de maintenir temporairement les deux versions du code.

Il est à noter que tous les exemples dans le svn livre suppose que tout est dans un seul référentiel.

Il y a une question distincte de savoir si l'utilisation /trunk/projet1 /trunk/projet2, /branches/projet1-r1 ou à utiliser /projet1/tronc, /projet1/branches/r1 /projet2/tronc. Généralement, la deuxième est plus facile de garder une trace de.

La meilleure raison de ne pas tout mettre dans un seul référentiel, c'est que le contrôle d'accès est dur de faire plus finement grainé que dans le référentiel. Possible, oui, mais pas aussi facile. Nous avons actuellement deux principaux référentiels:

• svn/code pour tous les logiciels de développement, nécessite jira billet de commettre
• svn/ops pour toute config, configurer des scripts, troisième partie goudrons, que ce soit, pas de jira nécessaire

Answer 4

Cela dépend de la façon interdépendante vos applications/projets sont dans l'organisation, et aussi comment les grandes bases de codes sont.De sorte qu'il se résume à la façon dont on définit un "projet" au sein de votre organisation. Partagé base de code, pour les composants partagés partagés équipes, partagé des cycles de publication, peuvent influencer la façon dont vos dépôts besoin d'être structuré.

Pour des raisons de simplicité, je définir un projet comme avoir un organisme indépendant de la base de code, la libération de la timeline, et/ou appartenant à un outil/de l'application.Si c'est le cas, je préfère avoir un référentiel par projet. De cette façon, il n'y a plus de liberté pour définir et mettre en œuvre des politiques/des restrictions d'accès par projet.

Si j'avais un référentiel unique des ballonnements au fil du temps ..j'ai peut-être également besoin de vous soucier de l'espace de travail le temps de validation, etc., surtout si le code pour tous les projets sont mixtes. Si une application/outil/projet est terminé/abandonné/obsolète/migré, il peut y avoir plus de contrôle sur l'administration des aspects si il y a séparation au niveau du projet.

La structuration d'un projet de référentiel basé sur ses besoins uniques peuvent également être plus facile si il ya un référentiel par projet. Chaque projet peut avoir des besoins spécifiques, qui peuvent influer sur la gestion de la configuration des politiques (ramification, l'étiquetage, les conventions de nommage, CI, etc inclus), suivi pour chaque projet. Ce n'est pas à dire que vous ne pouvez pas faire tout ce dossier-sage au sein d'un référentiel unique. Vous pouvez. On ne conserve que les choses les plus simple d'avoir un nettoyeur de séparation - c'est tout.

Vous pouvez tenir compte de tous ces facteurs afin d'évaluer les frais administratifs généraux, vous pouvez vous retrouver avec, basé sur votre installation spécifique.

Cela dit, si tous les projets sont de petite taille, et sont interdépendants , exigeant des références croisées, de la croix de suivi, le mouvement à l'intérieur de chaque d'autres, etc., alors, vous êtes mieux avec un seul repo et un seul dossier par le référentiel.

Answer 5

Je voudrais avoir un référentiel pour le projet, juste pour le plaisir de la révision numéros par projet. Vous pouvez d'installation de SVN pour être servi, de sorte que tous les projets peuvent être accessibles à partir d'un point d'accès unique à l'aide d'Apache et DAV SVN (avec SVNParentPath la directive).