Quelle est la granularité de vos "projets" SVN : un grand projet contenant plusieurs applications connexes ou un "projet" par application ?

Question

Je définis un projet comme un répertoire SVN contenant le tronc, les branches, les sous-répertoires des tags.

Quels critères utilisez-vous pour déterminer s'il faut diviser un projet en deux ou regrouper plusieurs projets en un seul ? - Une application par "projet" avec un projet partagé pour une source et des ressources communes ? - Un grand "projet" contenant toutes les sources et ressources de l'application ?

Projet unique ou projet multiple, les deux ont leurs avantages et leurs inconvénients. Nous nous dirigeons plutôt vers un projet unique et j'essaie de savoir si c'est la bonne approche.

Les projets fractionnés permettent de mieux contrôler comment les différentes parties de la suite intègrent un changement. La bibliothèque commune peut être versionnée et les différentes applications peuvent choisir d'utiliser une version spécifique (approche de gestion des dépôts maven).

Les projets fractionnés créent également de multiples hiérarchies de classes, ce qui rend le code plus difficile à comprendre dans son ensemble et peut conduire à une duplication du code. Je suppose qu'une conception adéquate de la structure globale et des relations entre les composants est essentielle pour gérer ce coût.

Une approche unifiée du projet facilitera la tâche du développeur en termes de mise en place d'un espace de travail, et fournira une hiérarchie de classe unique. Il s'agit d'une arme à double tranchant, car le développeur recevra également beaucoup plus d'informations (trop de classes à comprendre).

Alors, quand vous essayez de décider où combiner et où diviser, quelles règles empiriques utilisez-vous ?

Answer 1

Nous avons placé tous les projets liés à une seule application dans un seul SVN Rep, simplement pour faciliter la maintenance, centraliser la base de code de l'application dans un seul dépôt et gérer les interdépendances entre les différentes ressources de l'application.

nous classons généralement nos ressources dans différents dossiers au sein de trunk. cette catégorisation est principalement basée sur le regroupement fonctionnel/modulaire ou le regroupement en couches [DAL, BLL, GUI, etc.]. cela dépend entièrement de la façon dont vous avez structuré le code. J'espère que cela vous aidera.

Answer 2

El Livre SVN propose une bonne discussion sur les deux approches.

Au final, je choisirais ce qui semble le plus naturel aux utilisateurs du référentiel.

Personnellement, j'ai privilégié une approche unique SVN trunk/tags/branches avec tous mes projets de code réels dans leurs propres dossiers à l'intérieur de ceux-ci.

Cependant, pour une base de code plus importante (je n'ai géré que 3 ou 4 petits projets qui faisaient partie d'une solution unique), j'envisagerais fortement de passer à une approche fractionnée.

Answer 3

J'utilise à la fois des projets séparés et des projets combinés en fonction de la taille du projet. Pour nos grands projets, chacun d'entre eux se trouve dans un référentiel distinct et dispose de procédures de construction et de déploiement indépendantes. Pour nos petits projets, nous avons un dépôt "tools" pour les contenir, avec chaque sous-projet comme sous-répertoire de la racine.

Je maintiens également un dépôt "personnel" où les gens peuvent stocker leurs programmes de test, des utilitaires ponctuels, ou d'autres choses qui pourraient bénéficier du contrôle de source et de sauvegardes centralisées, mais qui n'ont pas leur place en tant que projet indépendant.

Answer 4

J'utilise des projets séparés et je les combine pour former une solution via svn:externals.

Answer 5

Une application / un module qui est déployé indépendamment par projet. L'utilisation d'un seul projet rend difficile l'introduction de cycles de publication si vous découvrez que vous avez besoin d'une gestion des dépendances à la Maven avec un module dépendant d'implémentations stables d'autres modules. Cela peut également conduire à ce que les gens utilisent directement du code d'apparence utile provenant d'autres applications au lieu de le prendre en compte pour garder le graphe de dépendances sain (tm).

Vous devez effectuer des tests d'intégration en utilisant des suites de tests appropriées et des pratiques de CI clairement définies, et non pas vous fier à la moitié de votre code qui échoue soudainement si une partie se casse.

Un autre problème lié au fait d'avoir un seul uber-projet est que c'est plutôt onéreux pour les utilisateurs de git-svn qui ne travaillent que sur un seul module.