Structure de répertoire de travail pour le référentiel SVN Visual Studio

Question

Je viens de présenter SVN dans notre société pour nos projets Visual Studio et j'ai créé un dépôt qui ressemble à ceci ("solution" est une solution Visual Studio, contenant des projets 1..n):

/solution1/trunk/projectA/... 
       /projectB/... 
/solution2/trunk/projectC/... 
/customerX/solution3/trunk/projectD/... 
      /solution4/trunk/projectE/... 
          /projectF/... 

maintenant, j'ai deux options pour structurer les répertoires de travail locaux:

Option a: Laissez votre commande utilisateur chaque solution séparément en utilisant AnkhSVN, conduisant à une structure comme celle-ci:

/solution1/projectA/... 
      /projectB/... 
/solution2/projectC/... 
/solution3/projectD/... 
/solution4/projectE/... 
      /projectF/... 

ou cela, si je dis à l'utilisateur de créer manuellement un sous-répertoire client X:

/solution1/projectA/... 
      /projectB/... 
/solution2/projectC/... 
/customerX/solution3/projectD/... 
/customerX/solution4/projectE/... 
        /projectF/... 

Avantage: L'utilisateur peut checkout que les solutions qu'il a vraiment besoin. Inconvénient: Chaque solution doit être vérifiée/mise à jour séparément.

Option B: Dites à l'utilisateur de la caisse du référentiel entier en utilisant TortoiseSVN, conduisant à une structure qui est exactement le même que le dépôt:

/solution1/trunk/projectA/... 
       /projectB/... 
/solution2/trunk/projectC/... 
/customerX/solution3/trunk/projectD/... 
      /solution4/trunk/projectE/... 
          /projectF/... 

Avantage: Il est très facile de « mettre à jour svn tout ". Inconvénient: L'utilisateur a également une copie locale de toutes les branches et étiquettes.

---

QUESTION: Étant donné que certains projets sont partagés entre les solutions (disons, par exemple, que projectA est une bibliothèque qui est également utilisé par solution3), nous devons fixer une structure de répertoire, pour vous assurer que les chemins relatifs dans les fichiers de solution sont corrects. Quelle option recommandez-vous et pourquoi?

---

EDIT: Merci pour toutes vos excellentes réponses, notamment pour mentionner svn:externals et pour souligner l'importance d'une bonne conception de référentiel. J'ai fini par mettre à jour mon référentiel Structure:

/trunk/solution1/projectA/... 
       /projectB/... 
     /solution2/projectC/... 
     /customerX/solution3/projectD/... 
          -svn:external to projectA 
       /solution4/projectE/... 
          /projectF/... 

qui assure qu'un développeur travaillant sur solution3 seulement besoins de vérifier solution3 (et non solution1) et la solution peut être vérifié dans un répertoire c'est-à-dire que le répertoire de travail n'a pas besoin d'une structure fixe.

Answer 1

Hehe, ce qui est probablement pas très utile, mais ... non plus.:)

Je voudrais trunk au niveau le plus élevé, avec les projets et les solutions organisées en dessous de côte à côte dans une structure plate. Ensuite, j'utiliser la propriété svn:externals dans les répertoires de la solution pour insérer les projets appropriés à l'emplacement correct dans la copie de travail de chaque développeur.

La raison pour laquelle j'organiserais les choses de cette façon est que cela vous donne les avantages de votre option A et de votre option B. Donc, si les développeurs ne veulent qu'une seule solution, ils sont libres de le faire. De même, ils peuvent également consulter le tronc entier s'ils préfèrent le faire à la place (et ils sont capables de le faire sans avoir de balises et de branches).

En outre, cette approche consistant à avoir un seul tronc facilite grandement l'étiquetage ou la dérivation de l'intégralité du dépôt, si jamais vous en avez besoin.

Answer 2

Pour ce qui est l'option vaut la peine, nous utilisons B.

Nous utilisons aussi tortoisesvn plutôt que Ankh SVN parce que nous avons un peu plus de flexibilité à la structure de notre dépôt si elle est pas liée à la même structure de répertoire Visual Studio attend. J'ai d'abord été farouchement opposé à cela parce que j'aimais l'intégration IDE que j'avais avec TFS, mais après quelques jours de travail, j'ai été convaincu que le compromis entre une plus grande flexibilité est des milliers de fois plus important que l'intégration avec l'IDE.

Modifier - Ajout

Il est également intéressant de noter que, avant de passer à nos processus actuels, nous avons cartographié exactement comment nous voulions exposer tous nos contrôle de code source. Il nous a fallu plusieurs semaines pour le planifier exactement, l'analyser à mort avant de faire le changement, mais cela a porté ses fruits en termes de facilité d'utilisation et de maintenance.

Nous avons une structure globale comme ce qui suit:

\ internes Applications Web

\ Internet Web Apps

\ entreprise WinForms Apps

\ Veuves Services intégrés

\ Retail Location WinForms Apps

\ Services détaillant

\ Shared

\ fichiers multi plate-forme Solution.

Chacun des dossiers principaux contient de nombreux projets et solutions différents. Ceux-ci ont chacun leurs propres branches, étiquettes et troncs. Ainsi, par exemple, si nous avons un outil de recherche de magasin Internet, il pourrait être dans

\Internet\<our company name>.com\Store Finder\Trunk 

La partie importante de c'est partagée, car il contient du code qui est utilisé dans toutes les autres branches. La raison pour laquelle l'intégration IDE ne fonctionne pas pour nous est que nous aurions besoin d'une solution au niveau racine pour y parvenir. Au lieu de cela, nous avons nos fichiers Sln le cas échéant et puisque nous avons tous une copie complète du référentiel, nous pouvons nous assurer que les chemins relatifs à tous les projets dans le répertoire \ Shared sont les mêmes sur tous les PC du développeur.

J'ai fourni ce qui précède, pas pour vous dire comment structurer votre code, mais juste pour vous donner des idées et pour souligner combien il est important de bien planifier avant de continuer.

Vous avez besoin de passer du temps à poser des questions comme "Si je le pose comme Y, serai-je capable de faire X?". Votre situation sera unique pour votre équipe et votre entreprise.

Answer 3

Option A - vous ne voulez pas retirer le dépôt dans son ensemble (tous les tags et branches) à chaque fois et cela encouragera vos utilisateurs à considérer l'ensemble du référentiel comme une entité unique qui n'est pas vraiment - vous voulez qu'ils pensent en termes de solutions et d'étiquetage/branchement dans ce contexte.

Vous adressez des projets partagés en les référençant en tant qu'extérieurs dans la «racine» des solutions appropriées. Cela signifie que vous pouvez avoir le même projet apparaître plusieurs fois sur votre disque dur, mais c'est gérable.

Il y a un peu Teeny plus sur le sujet ici: HowTo: Reference external SLN files with TeamCity

Answer 4

Je voudrais fortement seconder Phil Booths solution d'utiliser une structure de répertoire plat et en utilisant la propriété svn:externals dans inclure des projets partagés.

La principale raison est que cela vous donne la liberté de découpler la mise à jour de différents projets clients utilisant un projet partagé, tel qu'une bibliothèque. Avec la structure proposée, il n'y a qu'une seule copie du projet de bibliothèque partagée utilisée par tous les autres projets clients: tous les projets utilisant le projet partagé doivent donc voir la même version. Ce n'est pas toujours souhaitable. Parfois, les modifications apportées à une bibliothèque partagée nécessitent des modifications correspondantes dans le code client à l'aide de cette bibliothèque. Avec la structure proposée, un tel changement vous obligerait à mettre à jour tous les projets clients de la bibliothèque en même temps, ou à vivre avec le fait que de nombreux projets clients pourraient être cassés. L'utilisation de svn:externals pour chaque projet client utilisant une bibliothèque signifie que chacun des clients aura sa propre copie de la bibliothèque dans une copie de travail (mais l'espace disque est bon marché). Toutefois, il existe toujours une copie du projet de bibliothèque dans le référentiel (les projets clients en réorganisent une version différente.) Ainsi, un projet client particulier peut continuer à utiliser l'ancienne version de la bibliothèque partagée, ou il peut être mis à jour (par mise à jour du svn:externals propriété) d'utiliser une version plus récente

en résumé:.

Dans votre mise en page proposée. commettre un changement à un projet de bibliothèque de changements immédiats tous les projets qui utilisent la bibliothèque tous les projets clients reçoivent des mises à jour à la bibliothèque, qu'ils le veuillent ou non

Avec svn:externals, la modification d'un projet de bibliothèque n'affecte que la bibliothèque projet ary seul. Chaque projet client nécessite une validation supplémentaire pour mettre à jour la propriété svn:externals pour faire référence à la version la plus récente de la bibliothèque (qui peut être validée avec les modifications correspondantes apportées au code du projet client). Tous les projets client peuvent avoir des mises à jour de la bibliothèque, mais ils ne les obtiennent que lorsqu'ils les demandent explicitement.