Comment structurez-vous votre référentiel SVN?

Question

Quoi de mieux?

A:

server:1080/repo/projectA/trunk/... 
          branches/branch1 
          branches/branch2 
          branches/branch3 
          tags/tag1/... 
          tags/tag2/... 
server:1080/repo/projectB/trunk/... 
          branches/branch1 
          branches/branch2 
          branches/branch3 
          tags/tag1/... 
          tags/tag2/... 

B:

server:1080/repo/trunk/projectA/... 
       branches/projectA/branch1 
       branches/projectA/branch2 
       branches/projectA/branch3 
       tags/projectA/tag1/... 
       tags/projectA/tag2/... 
server:1080/repo/trunk/projectB/trunk/... 
       branches/projectB/branch1 
       branches/projectB/branch2 
       branches/projectB/branch3 
       tags/projectB/tag1/... 
       tags/projectB/tag2/... 

Quelle est la structure du référentiel utilisez-vous et pourquoi?

Answer 1

Le chapitre Repository Administration du SVN book comprend une section sur Planning Your Repository Organization décrivant différentes stratégies et leurs implications, en particulier the implications of the repository layout on branching and merging.

Answer 2

Nous utilisons A, parce que l'autre n'a pas de sens pour nous. Notez qu'un "projet" en ce qui concerne SVN n'est pas nécessairement un seul projet, mais peut être plusieurs projets qui appartiennent ensemble (c'est-à-dire ce que vous mettriez dans une solution dans Visual Studio). De cette façon, vous avez tout ce qui est lié ensemble. Toutes les branches, étiquettes et le tronc d'un projet spécifique. Cela me semble parfaitement sensé.

Le regroupement par branche/balise n'a pas de sens pour moi, parce que les branches de différents projets n'ont rien en commun, sauf qu'elles sont toutes des branches. Mais à la fin, les gens utilisent les deux façons. Faites ce que vous voulez, mais quand vous avez décidé, essayez de rester avec :) :)

En plus: Nous avons des dépôts séparés par client, c'est-à-dire que tous les projets pour un client sont dans le même référentiel. De cette façon, vous pouvez, par exemple, faire des sauvegardes d'un seul client à la fois, ou donner le code source de tout ce que le client lui possède sans se battre avec SVN.

Answer 3

je suggère une option C:

server:1080/projectA/trunk/... 
        branches/branch1 
        branches/branch2 
        branches/branch3 
        tags/tag1/... 
        tags/tag2/... 
server:1080/projectB/trunk/... 
        branches/branch1 
        branches/branch2 
        branches/branch3 
        tags/tag1/... 
        tags/tag2/... 

Je préfère garder des projets séparés dans des dépôts séparés. L'utilisation de svn:externals facilite la gestion des projets de bibliothèque de codes partagés entre deux projets d'application ou plus.

Answer 4

Nous utilisons le réglage B. Il est plus facile de vérifier/étiqueter plusieurs projets à la fois. Dans svn 1.5, il est possible de passer par la caisse, mais pas en une seule opération. Vous voulez utiliser le paramètre B si certains projets ont des dépendances cachées entre eux.

Answer 5

Nous utilisons

/repos/projectA/component1/trunk - branches - tags 
/repos/projectA/component2/trunk - branches - tags 
/repos/projectB/component3/trunk - branches - tags 
/repos/projectB/component4/trunk - branches - tags 

qui je commence à regretter. Cela devrait être plus plat. Ce serait mieux.

/repos/projectA/trunk - branches - tags 
/repos/projectB/trunk - branches - tags 
/repos/component1/trunk - branches - tags 
/repos/component2/trunk - branches - tags 
/repos/component3/trunk - branches - tags 
/repos/component4/trunk - branches - tags 

Pourquoi? Les produits (composants, logiciels finis) durent pour toujours. Les projets vont et viennent. L'année dernière, une seule équipe de projet a créé le produit QUUX. L'année prochaine, cette équipe est dispersée et une ou deux personnes maintiennent QUUX. L'année prochaine, il y aura deux grands projets d'expansion de QUUX.

Étant donné cette chronologie, QUUX devrait-il apparaître dans trois référentiels de projet? Non, QUUX est indépendant de tout projet particulier. Il est vrai que les projets ont des produits de travail (documents, arriérés, etc.) qui font partie du travail à faire, mais qui ne sont pas l'objectif réel du travail. D'où les dépôts «projectX» pour ce matériel - des choses dont personne ne se souciera après le projet.

je travaillais sur un produit qui avait trois équipes. Gros problème de coordination du travail car chaque projet gère son référentiel de manière indépendante. Il y a eu des libérations inter-équipes et une coordination inter-équipes. À la fin de la journée, c'était censé être un logiciel. Cependant, comme vous pouvez le deviner, il s'agissait de trois logiciels avec chevauchement et redondance étranges.

Answer 6

Personnellement, j'utiliser la structure suivante référentiel:

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

Il y a aussi un diagram illustrant la façon dont ces répertoires sont utilisés. Il y a aussi une approche spécifique de numérotation des versions que j'utilise. Il joue un rôle important dans la structuration du référentiel. Récemment, j'ai développé une formation dédiée à la gestion de la configuration logicielle où je décris l'approche de la numérotation des versions et pourquoi exactement cette structure de référentiel est la meilleure. Voici presentation slides.

Il y a aussi mes answer sur le question à propos de 'Référentiels SVN multiples vs référentiel mono-entreprise'. Cela peut être utile tant que vous abordez cet aspect de la structuration du référentiel dans votre question.