J'essaie de comprendre le meilleur moyen de structurer nos référentiels de subversion initialement.
Il est donc préférable de créer un référentiel initial puis des sous-référentiels pour chaque projet en dessous?
et quels référentiels devraient avoir un tronc, une branche, etc. créés?
En outre, j'entends que c'est la meilleure pratique de ne pas créer de coffre, de branche et de tags dossiers sur le référentiel de niveau racine?
Je sais quand j'étais sur une autre équipe, nous avons tiré de dire du projet, mais il n'a pas tiré un tronc, des dossiers de branchement qui étaient gentils, mais je ne sais pas comment cela a été structuré sur le serveur pour que cela se produise comme ça.
5 Réponses :
Pour vous épargner des maux de tête de maintenance futurs, à moins que vous n'ayez d'énormes quantités de code, ou envisagez de supprimer complètement un projet avec une grande quantité de code, gardez tout dans un référentiel. Ensuite, faites des annuaires pour chaque projet. Ensuite, si vous souhaitez suivre la recommandation Subversions, placez les "branches", "branches" et "tags" dans le dossier de chaque projet.
Donc, lorsque je crée un sous-dossier pour un projet, je copie l'URL, allez-y dans ce dossier localement, puis comment puis-je filer cela dans le dossier réseau que j'ai créé sur le serveur sous mon dossier de projet?
Lors de la mise en place d'un nouveau référentiel, c'est ce que je fais. Je crée le référentiel global, avec une URL comme " exemple.com/svn ". Je vérifie cela dans un nouveau dossier local, c'est-à-dire "Exemple-svn" (ce que vous voulez). Maintenant, "exemple-svn" est une copie de travail de l'ensemble du référentiel. Si vous souhaitez configurer des dossiers du coffre / des branches / balises, créez un nouveau dossier à l'intérieur "Exemple-svn" pour "Project1", et à l'intérieur de ce dossier Créer "coffre", "Branches" et "Tags". Ensuite, collez tous les fichiers de projet1 dans "coffre", cliquez sur "Project1" et sélectionnez "Ajouter". Commettre et tu es bon d'aller.
Dans l'exemple ci-dessus, si vous souhaitez consulter tout le référentiel (tous les projets), vous utiliseriez " exemple.com / svn ". Si vous vouliez vérifier simplement le projet1, utilisez " exemple.com/svn/project1 "
Quelles paines rencontrez-vous lorsque vous ne le faites pas de cette façon? Vous avez dit quelques douleurs.
Les douleurs sont simplement que vous devriez gérer et sauvegarder plusieurs référentiels à l'autre sens. En plus de fournir des contrôles d'accès à ceux-ci, surveiller, etc. La création d'un nouveau projet devient créer un nouveau référentiel, donc si vous n'avez pas de processus lisse pour cela, c'est difficile - pas seulement quiconque peut commencer un nouveau projet. Avec un seul référentiel, tout cela s'en va. Si vous êtes prêt à accepter le travail ou que vous avez un cadre pour gérer de multiples référentiels facilement, vous obtenez une certaine flexibilité supplémentaire et la capacité d'échelle.
Grande réponse de Jim sur les maux de tête de maintenance. J'ajouterais que la seule chose que je faisais allusion à cela pourrait être un peu mieux avec plusieurs référentiels, est si vous envisagez de vouloir vous débarrasser complètement de projets entiers - si c'est dans son propre référentiel, vous pouvez simplement supprimer le tout. Si c'est dans un référentiel combiné, ce sera dans votre histoire pour toujours, prenant de l'espace. Mais comme dit Jim, il y a tellement de bonnes raisons d'utiliser un référentiel, je ne pense pas que cela vaut le coût.
Si vous souhaitez conserver plusieurs projets dans le référentiel, j'irais pour cette structure
/trunk /branches /tags
Merci. Et donc si je devais vérifier dans le projet1 pour la première fois, je voudrais simplement obtenir l'URL du dossier Project1 \ Trunk et utiliser cela, alors non?
Si vous souhaitez travailler sur le projet1, vous allez simplement utiliser quelque chose comme svn: //path.to.votre.repo/project1/trunk pour votre caisse
Je suis d'accord avec cela, voici comment mon équipe le fait actuellement.
J'utilise le modèle ci-dessus pendant quelques années maintenant dans certains de mon projet et je suis heureux avec ça aussi.
Quel est le raisonnement derrière la structure du tronc / des branches / des balises? Pourquoi est-il nécessaire de permettre à SVN de gérer les versions et de vérifier celui que vous voulez à l'époque? Je manque évidemment quelque chose, mais je ne peux pas le voir. Semble trop complexe surtout pour les applications simples dans un petit magasin.
Book Subversion à la rescousse.
Oui, et c'est plein d'informations pour vous confondre encore plus. J'ai traversé cela et ça ne donne pas de meilleures pratiques comme celle-ci.
J'ai trouvé que cela éclaira beaucoup de choses pour moi. La réponse de Rayell est presque immédiate des recommandations de livres.
Garder les référentiels distincts vous permet de personnaliser les horaires de sauvegarde et les emplacements de stockage par référentiel. En outre, si vous devez parfois creuser dans le référentiel et effectuer des actions de maintenance ou de nettoyage (par exemple, vous souhaitez supprimer un commit du repo entièrement ... rare mais possible) Garder des référentiels distincts vous permettra de le faire avec des interférences minimales à d'autres utilisateurs et autres repos.
Cela étant dit - pour de petits projets, ces choses ne sont généralement pas une grande préoccupation. Je donne une autre recommandation copieuse à la
Je préfère des référentiels à grain fin, très organisé, auto-contenus, structurés. Il y a un Diagramme illustrant l'approche générale (idéale) du processus de maintenance du référentiel. Par exemple, ma structure initiale de référentiel (chaque référentiel de projet devrait avoir) est le suivant:
/project
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
Face à «Svn» plutôt que «Tortoisevn», car il s'agit d'un problème de référentiel / côté sévère, pas une question côté client.