Meilleure pratique pour créer des dépôts de subversion ?

Question

Notre équipe (5-10 développeurs) prévoit adopter Subversion pour nos projets/solutions .NET (Visual Studio) (VisualSVN Server, TortoiseSVN / VisualSVN).

Quelle est la meilleure façon de organiser une nouvelle arborescence de référentiel ? Est-il possible d'utiliser un grand dépôt ou est-il préférable de créer différents référentiels pour chaque solution / ligne de produits, etc.

Nos projets peuvent être catégorisés de cette façon (exemple) :

• Ligne de produits principale
  • Application Web principale
    • Bibliothèque 1
    • Bibliothèque 2
    • ...
  • Client Windows
  • Un autre client Windows
  • Service Windows
• Outils
  • Outil A
  • Outil B
• Ligne de produits 2
  • Logiciel 1
  • Logiciel 2
• Ligne de produits 3
  • App 1
  • App 2

Answer 1

Ma source d'inspiration :

• Contrôle de version avec Subversion
• Présentation du référentiel Subversion
• Un seul référentiel ou plusieurs
• Plusieurs dépôts Subversion

Answer 2

En règle générale, il convient d'utiliser un référentiel distinct dans tous les cas où vous attendez des autorisations d'accès différentes (par exemple, certains développeurs devraient avoir un accès de validation à un projet, mais pas à un autre, ou un projet a une interface anonyme publique en lecture seule, mais un autre n'en a pas).

Si vous n'avez pas besoin de ce niveau de contrôle d'accès, il est préférable de tout regrouper dans un seul référentiel, en particulier si vous devez pouvoir copier ou déplacer des fichiers entre les projets (c'est-à-dire que les projets peuvent partager du code).

Placez votre division trunk/tags/branch au niveau qui correspond à un morceau de code que vous pourriez publier en tant que paquet unique (c'est-à-dire pensez à l'endroit où vous mettriez les tags). Il n'est pas essentiel de bien faire les choses au début, puisque ces dossiers ne sont pas différents en interne de n'importe quel autre dossier, donc vous pouvez simplement déplacer les choses plus tard, bien qu'il soit bien sûr préférable de ne pas avoir ce problème.

Answer 3

• Point de vue gestion SVN Je préfère 1 dépôt.
• Point de vue du programmeur Je préfère 1 dépôt.
• Administrateur de serveur Je préfère 1 réorganisation.
• Point de vue sécurité, c'est de ne pas mettre tous ses œufs dans le même œufs dans le même panier.

La structure de votre référentiel sera en quelque sorte unique à votre entreprise et à ses produits. Nous conservons les nôtres dans un seul référentiel. Notre structure est à peu près la suivante.

• /
  • Projets
    • Nom du projet
      • coffre
      • branches
      • étiquettes
  • Documentation
    • Projet 1
  • Bibliothèques partagées
    • Super classe de chaîne de caractères
  • Petits services publics
    • vim amélioration X

Answer 4

Nous utilisons un grand référentiel, et tout est structuré dans des sous-dossiers (/projet1, /projet2, etc.) et cela semble bien fonctionner.

Le projet Apache dispose d'un énorme dépôt svn et cela semble leur convenir ! :)

En termes d'organisation, la structure que vous avez donnée semble tout à fait raisonnable. Je pense que tout est permis, tant que c'est rationnel (par exemple, mélanger chaque outil avec chaque projet est probablement une mauvaise idée, etc.) Choisissez donc quelque chose qui vous convient (outils/, projets/, etc.). Subversion a un très bon support pour déplacer les choses dans le dépôt, aussi, vous pouvez toujours changer si nécessaire.

Answer 5

Nous avons un repo unique qui est structuré de la sorte. Tout ce qui est travaillé par plus de quelques personnes et/ou en développement actif est mis en place avec trunk/ tags/ branch/ sous le dossier principal.

Nous mettrions probablement le jeu de dossiers trunk-tags-branch sous chaque sous-dossier que vous avez listé, sauf peut-être une ou deux bibliothèques qui ne sont pas en développement actif.