SVN Organisation (s) de projet: per-module or per-project

Question

J'ai un dépôt subversion qui contient un nombre donc des sous-dossiers, correspondant aux diverses applications, fichiers de configuration, DLLs, etc (je les appellerai 'modules') qui composent mon projet. Maintenant, nous commençons à "branchez" dans plusieurs projets connexes. Autrement dit, chaque projet de haut niveau utilisera un certain nombre de modules, éventuellement légèrement modifiés d'un projet à l'autre. Le nombre de projets est plus petit (~ 5) que le nombre de modules (~ 20)

Maintenant j'essaie de comprendre comment organiser le repo. Est-il logique de conserver les sous-dossiers de niveau supérieur module par module, avec des sous-sous-dossiers pour chaque projet? Ou si le niveau supérieur est pour chaque projet, chaque projet ayant ses propres sous-module:

repo:

module 1 
    Project 1 
    Project 2 
    ... 

    Project 5 
module 2 
    Project 1 
    .... 
    Project 5 
.... 
module 20 
    Project 1 
    ... 
    Project 5 

-ou-

repo:

Project 1 
    module 1 
    module 2 
    ... 
    module 20 
Project 2 
    module 1 
    module 2 
    ... 
    module 20 
... 
Project 5 
    module 1 
    module 2 
    ... 
    module 20 

Answer 1

Je pense que votre utilisation de «haut niveau» pour décrire ce qu'est un projet suggère que vous devriez avoir une configuration Projets/modules. Cependant, vous pouvez configurer un module et un projet, c'est-à-dire qu'ils sont au même niveau dans le dépôt SVN. Vos projets peuvent s'appuyer sur des modules, et si possible les projets peuvent fournir des implémentations spécifiques d'actions, en transformant le module en un module de base avec des implémentations par défaut mais remplaçables.

Answer 2

Je m'organiserais par projets ALORS par modules (votre deuxième exemple). La raison principale en est parce qu'il y a plus de frais généraux dans la gestion d'un projet, du moins pour moi, que la gestion des modules.

Chaque projet a besoin d'autre sa propre configuration de script de compilation, fichier de propriétés, etc., et il est beaucoup plus facile de garder une trace de 5 copies de travail sur votre ordinateur que 20.

Answer 3

Je préfère la 1ère.

Bien que chaque référentiel nécessite un effort supplémentaire, je préfère que mes numéros de révision aient un sens pour le projet. Par exemple, notre produit phare a une révision de 48123, notre nouveau projet a une révision de 31. Si vous avez des dépendances inter-référentiel, vous pouvez utiliser svn externals.

Answer 4

Il semblerait préférable d'organiser par le projet au plus haut niveau, puisque vous allez vouloir extraire une branche entière et avoir une copie de travail pour le projet. Si vous organisez par module, vous devrez effectuer plusieurs extractions (une pour chaque module que vous utilisez) afin de construire votre projet à un point où il est utilisable.

Il serait logique de garder les deux projets et modules distincts, par exemple:

Projects 
    Project 1 
    Project 2 
    ... 
Modules 
    Module 1 
    Module 2 
    ... 

Si vous utilisez qui, en combinaison avec svn externals et/ou vendor branches, vous pouvez soutenir différentes branches pour vos projets qui ont besoin de différents versions de module, mais toujours bénéficier de la source unique d'un module lorsque les projets partagent la même version d'un module.

Answer 5

J'aurais tendance à organiser par projet, mais maintenant toujours.Si vous avez des aspects de contrôle d'accès de votre code, alors organisez à minimiser les permissions-administration; cela pourrait également entraîner une organisation par équipe du référentiel. A propos: Vous semblez vouloir travailler dans un seul grand dépôt - ce qui, je pense, est intelligent, car cela signifie une meilleure gestion de l'historique: dès que vous déplacez des données entre des référentiels, vous perdez l'historique. En d'autres termes, je ne suis pas d'accord avec l'avis de Ben Scheirman à ce sujet.