Comment structurez-vous votre référentiel SVN? [fermé]

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 structure de référentiel utilisez-vous et POURQUOI?

Answer 1

Le chapitre Administration du référentiel du Le livre SVN comprend une section sur Planification de votre organisation de référentiel décrivant les différentes stratégies et leurs implications, en particulier les implications de la présentation du référentiel sur la création de branches et la fusion .

Answer 2

Nous utilisons A, car l’autre n’avait aucun sens pour nous. Notez qu'un " projet " En ce qui concerne SVN, ce n’est pas nécessairement un projet unique, mais plusieurs projets pouvant s’appartenir (c’est-à-dire ce que vous mettriez dans une solution dans Visual Studio). De cette façon, vous avez quelque chose de lié regroupé. Toutes les branches, les balises et le tronc d'un projet spécifique. Cela me semble parfaitement logique.

Au lieu de cela, le regroupement par branche / balise n'a pas de sens, car les branches de différents projets n'ont rien en commun, si ce n'est qu'elles sont toutes des branches.

Mais au final, les gens utilisent les deux méthodes. Fais ce que tu aimes, mais quand tu auras décidé, essaie de rester avec:)

En complément: nous avons des référentiels distincts par client, c’est-à-dire que tous les projets d’un client se trouvent 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 lui donner le code source de tout ce que le client lui possède sans se battre avec SVN.

Answer 3

Je suggérerais 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 conserver des projets distincts dans des référentiels distincts. L'utilisation de svn: externals facilite la gestion des projets de bibliothèque de code partagés. parmi deux ou plusieurs projets d'application.

Answer 4

Nous utilisons le paramètre B. Il est plus facile d'extraire / de marquer plusieurs projets à la fois. Dans svn 1.5, il est possible de passer par la caisse éparse, mais pas en un clic. Vous souhaitez utiliser le paramètre B si certains projets ont des dépendances masquées entre les deux.

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

Ce que je commence à regretter. Ça 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 éternellement. 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 assurent la maintenance de QUUX. L'année prochaine, il y aura deux grands projets d'expansion de QUUX.

Étant donné ce calendrier, QUUX doit-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 de la réalisation du travail, mais ne constituent pas l'objectif réel du travail. D'où le " projectX " des référentiels pour ce matériel - des choses dont personne ne se souciera plus après le projet

J'ai travaillé sur un produit comportant trois équipes. Gros problème de coordination du travail car chaque projet gérait son référentiel de manière indépendante. Il y a eu des libérations entre équipes et une coordination entre équipes. À la fin de la journée, il était supposé utiliser un logiciel. Cependant, comme vous pouvez le deviner, il s’agissait de trois logiciels avec des chevauchements et une redondance étranges.

Answer 6

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

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

Il existe également un diagramme illustrant l'utilisation de ces répertoires. . Il existe également une approche de numérotation des versions spécifique 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 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 les diapositives de présentation .

Il existe également ma réponse sur le question sur "Référentiels SVN multiples par rapport à un référentiel d'entreprise unique". Cela peut être utile tant que vous abordez cet aspect de la structuration du référentiel dans votre question.