2009-02-21 6 views
29

Je viens de créer un dépôt SVN Google Code pour stocker mes projets scolaires et mes devoirs, et pour faciliter le transfert entre l'école et la maison.Structure de dossiers pour de nombreux projets dans un référentiel SVN?

Ses répertoires par défaut, il crée sont:

https://simucal-projects.googlecode.com/svn/trunk/
https://simucal-projects.googlecode.com/svn/tags/
https://simucal-projects.googlecode.com/svn/branches/

Je ne l'ai jamais utilisé un dépôt pour plus d'un projet, mais après avoir lu: One svn repository or many? je J'ai décidé d'avoir un référentiel unique pour tous mes projets scolaires aléatoires.

Dois-je simplement répliquer la structure de dossiers ci-dessus, mais pour chaque projet?

https://simucal-projects.googlecode.com/svn/projectA/trunk/
https://simucal-projects.googlecode.com/svn/projectA/tags/
https://simucal-projects.googlecode.com/svn/projectA/branches/

https://simucal-projects.googlecode.com/svn/projectB/trunk/
https://simucal-projects.googlecode.com/svn/projectB/tags/
https://simucal-projects.googlecode.com/svn/projectB/branches/

Est-ce que vous multi-projets-en-un-repo font?

Répondre

43

Vous avez deux options pour cela. Celui que vous avez déjà mentionné, et qui est d'avoir un tronc pour chaque projet (option 1):

https://simucal-projects.googlecode.com/svn/projectA/trunk/ 
https://simucal-projects.googlecode.com/svn/projectA/tags/ 
https://simucal-projects.googlecode.com/svn/projectA/branches/ 

https://simucal-projects.googlecode.com/svn/projectB/trunk/ 
https://simucal-projects.googlecode.com/svn/projectB/tags/ 
https://simucal-projects.googlecode.com/svn/projectB/branches/ 

Option 2 serait d'avoir un tronc à chaque projet étant un sous-dossier tronc:

https://simucal-projects.googlecode.com/svn/trunk/projectA/ 
https://simucal-projects.googlecode.com/svn/tags/projectA/ 
https://simucal-projects.googlecode.com/svn/branches/projectA/ 

https://simucal-projects.googlecode.com/svn/trunk/projectB/ 
https://simucal-projects.googlecode.com/svn/tags/projectB/ 
https://simucal-projects.googlecode.com/svn/branches/projectB/ 

L'avantage de l'option 1 est que vous pouvez brancher et étiqueter chaque projet indépendamment. Ceci est souhaitable si vous devez déployer chaque projet séparément.

L'option 2 est souhaitable si tous les projets sont déployés ensemble. En effet, il vous suffit d'étiqueter le référentiel une seule fois lors du déploiement.

Puisque vous utilisez Subversion pour les projets scolaires, vous devez vous demander si vous aurez besoin de baliser votre travail. Vous pouvez également vous demander si vous avez besoin de créer des branches (vous voudrez probablement si vous voulez expérimenter un peu). Vous devrez également vous demander si vous êtes heureux de regrouper TOUT votre travail en un seul, de savoir si vous préférez la flexibilité de l'embranchement de chaque projet indépendamment.

La règle que je suis toujours: trunk ensemble tout ce que nous déployons ensemble.

(Soit dit en passant - vous pouvez avoir beaucoup de troncs dans le même dépôt - ce qui est presque équivalent à avoir un tronc dans plusieurs dépôts, à l'exception que chaque référentiel conserve son propre compteur de révision et vous ne pouvez pas fusionner entre les dépôts.)

+0

@Simucal Je pense que cela devrait être la réponse acceptée - merci Trumpi! –

+0

@TonyDay, terminé. Merci de me le rappeler. – mmcdole

9

C'est ce que j'utilise pour mon contrôle de source domestique.

Où je n'ai qu'un référentiel principal.

dépôt/Project1/Tronc
Repository/Project1/Mots
repository/Project1/Branches

repository/Project2/Tronc
repository/Project2/Tag
repository/Project2/Branches

J'aime cette structure, il est très facile de référencer des projets et de maintenir l'intégrité.

+0

Je suis fortement en faveur de cette mise en page. J'entends ce que dit Pawel, et si les dépôts étaient aussi faciles à créer et à administrer dans svn comme ils sont avec git, je serais d'accord. Mais si vous pouvez traiter chaque projet * comme si * c'était son propre référentiel, les choses fonctionnent bien. –

+0

Oui, exactement, dans le scénario décrit également, il semble impossible d'avoir une mise en page de référentiel multiple de toute façon.Vous pouvez faire un simple get pour le référentiel principal pour sélectionner tout votre code ou obtenir chaque projet individuellement. –

+0

Aussi avec VS2008 & AnkhSVN 2.0 c'est très facile à utiliser et facile à utiliser Solutions multi-projets –

1

Il n'y a pas de réponse claire à cette question car elle dépend de ce qui convient le mieux à vos projets. J'utiliserais la mise en page/projectA/trunk si un développement important se produisait par projet et que tout devait être séparé puisqu'il n'y avait pas beaucoup de connexion entre eux (composants/projets indépendants). Cependant, vous pouvez également utiliser un référentiel SVN par projet. Rappelez-vous que vous ne serez pas en mesure de vérifier tous les projets en utilisant svn co http: //..../svn/ car cela récupérerait aussi tous les tags et toutes les branches de tous les projets, et pas seulement le tronc.

  • /trunk/projectA serait certainement mieux si vos projets/composants sont étroitement liés et que vous devez les étiqueter et les relier à partir de la même révision (comme une bibliothèque appartenant très étroitement au projet principal). Vous pouvez également utiliser svn co http: //.../svn/trunk/ pour obtenir tous les projets sur leur dernière révision de tronc si vous le souhaitez.D'un point de vue de la maintenabilité, je préfèrerais presque toujours la deuxième voie; mais si vos projets prennent de l'ampleur et pourraient se prolonger, il serait préférable d'utiliser des référentiels distincts par projet. En plus de cela: S'il vous plaît vérifiez si vous avez vraiment besoin de services de code Google pour vos devoirs parce que son but est de soutenir OSS. Vous pouvez toujours utiliser SVN localement ou même via SSH, vous pouvez donc placer vos dépôts sur une clé USB ou sur un ordinateur accessible à distance; vous n'avez pas vraiment besoin d'hébergement pour ça. Il pourrait également y avoir des problèmes de confidentialité.

  • +2

    Eh bien, mon code ~ sera ~ open-source et juste parce que c'est pour l'école ne signifie pas qu'il n'a aucune valeur potentielle . Particulièrement mon travail dans les algorithmes génétiques, les gens pourraient trouver utile de lire à travers. Google-code est conçu pour exactement cela. – mmcdole

    +1

    Je ne suis pas un type de gars Thumbdrive et SVN échoue localement le but de pourquoi je tente de mettre en place ce en premier lieu. Portabilité. – mmcdole

    +0

    Peut-être que vous aimeriez essayer unfuddle (http://www.unfuddle.com). Ils vous donneront un référentiel svn gratuit et votre code peut être privé. – Trumpi

    1

    Si vous insistez pour n'avoir qu'un seul dépôt (je suis dans le camp NE PAS me camper moi-même) et que je fais des branchements, je pense que ce que vous proposez est bon. Mais encore une fois, je considère qu'un référentiel SVN est égal à un projet.

    +2

    Mes projets sont assez légers. Le but du dépôt est pour moi de pouvoir travailler sur tous mes petits projets pour l'école sans avoir à transporter du code partout avec moi. Disposer d'un référentiel pour chacun de ces microprojets serait lourd. – mmcdole

    6

    Un exemple concret: les projets Apache repository.

    1

    L'un des principaux objectifs de la mise en page des dossiers (dans la gestion des versions) est la gestion des contrôles d'accès.

    S'il est nécessaire de séparer développer l'équipe (qui travaille sur le tronc) et maintenir l'équipe (qui traite avec les directions générales) cette structure est bonne:

    /trunk 
         /Project1 
         /Project2 
    /branches 
         /Project1 
         /Project2 
    /tags 
        /Project1 
        /Project2 
    

    Et si nous voulons permettre l'accès de chaque projet un groupe d'utilisateurs spécifique, cette structure est bonne:

    /Project1 
         /trunk 
         /branches 
         /tags 
    /Project2 
         /trunk 
         /branches 
         /tags 
    
    Questions connexes