SVN Repository Structure - Pourquoi est-ce mieux?

On m'a dit que la plupart des magasins de développement ont la structure suivante ou au moins proche de celle-ci:SVN Repository Structure - Pourquoi est-ce mieux?

principal dépôt
- dossiers de projet dessous
- Chaque dossier de projet a un tronc, des branches, dossier et les tags

donc:

ReponsitoryMain 
    Project1 
     branches 
     trunk 
     tags 
    Project2 
     ...

Alors pourquoi est-ce mieux ou mieux? Que se passe-t-il ou quels chagrins avez-vous rencontrés si vous l'avez fait d'une autre manière?

Source

2009-07-31 PositiveGuy

C'est une bonne pratique qui s'est avérée efficace pour la plupart des gens. Dans notre société, nous utilisons une version légèrement modifiée et sommes heureux avec elle et vous devriez le faire. Si cela correspond à vos besoins, très bien! Sinon, validez n'importe quelle structure de répertoire que vous aimez. – Boldewyn

Vous dites "mieux", mais mieux que quoi? –

Merci à tous! Très appréciée. – PositiveGuy

Cette façon d'organiser le dépôt:

ReponsitoryMain 
    Project1 
     branches 
     trunk 
     tags 
    Project2 
    ...

est mieux quand vos projets ne sont pas que connectés/dépendants les uns des autres. Dans l'autre sens, il est plus facile de mettre à jour l'intégralité de votre suite de projets. Donc, si vous libérez/packagez souvent Project1 et Project2 ensemble, il est préférable de les partager avec la même branche. Si, d'autre part, votre projet est très découplé et que des équipes totalement différentes travaillent dessus, vous n'avez pas besoin de les vérifier tous ensemble la plupart du temps, et vous pouvez donc utiliser la méthode ci-dessus .

Source

2009-07-31 18:34:19

Voilà ce que nous avons. Cela fonctionne et c'est assez bon pour le moment (parce que nous ne savons jamais ce que l'avenir nous réserve) Nous n'avons aucune raison impérieuse de consacrer du temps (et de l'argent) pour trouver une structure plus optimale.

Source

2009-07-31 18:16:06 Max

Je ne discute pas de la structure en me demandant simplement pourquoi c'est recommandé et quels pièges vous pouvez obtenir si vous ne le faites pas de cette façon. – PositiveGuy

La plupart des gens le font parce qu'il est recommandé par le Subversion book.

Voici une bonne explication du directeur du projet Subversion de CollabNet:

http://blogs.collab.net/subversion/2007/04/subversion_repo/

Source

2009-07-31 18:16:38

joli lien, merci beaucoup. Ceci est également très utile. – PositiveGuy

Nous gardons un dépôt distinct pour chaque projet.

Bien que cela ne vous permette pas de copier et de conserver les fichiers d'historique des versions d'un projet à un autre, il vous permet d'archiver un référentiel entier lorsqu'un projet est terminé.

Source

2009-07-31 18:18:33 pgb

pourquoi voudriez-vous l'archiver? Est-ce une commande Subversion? – PositiveGuy

juste pour économiser de l'espace, et le garder dans un endroit sûr au lieu de le sauvegarder tous les jours. – pgb

Les branches et balises de tronc agissent toutes de la même manière. La façon dont vous les utilisez dépend de vous.

J'utilise cette structure depuis des années et je n'ai pas encore trouvé de temps pour que la structure ne s'adapte pas à ce que je devais faire.

Source

2009-07-31 18:28:49 Gren

La structure du référentiel dépend de vos besoins. Si vos projets sont complètement séparés (pas de dépendances entre eux) alors cette structure de référentiel "simple" est bien. Si vous avez des dépendances dans votre projet (par exemple, des « outils »-bibliothèques mondiales, le code partagé), vous devez utiliser une autre structure comme:

trunk 
    prj_a 
    prj_b 
tags 
    <YOUR_TAGNAME> 
     prj_a 
     prj_b 
branches 
    <YOUR_BRANCHNAME> 
    prj_a 
    prj_b

ou toute autre chose qui est plus logique de votre processus. Dans la structure simple avec trunk/tags/branches locaux, il n'est pas possible (au moins de manière propre) d'étiqueter plusieurs projets, si vous avez des dépendances entre eux. L'approche «multi-référentiel» souvent proposée ne comblera pas cet écart car vous êtes alors condamné à plusieurs révisions ou tags dans plusieurs référentiels.

Le principal problème est que SVN a pas de support pour les ressources partagées et de les marquer/ramifier.

Si vous pensez à la structure de votre référentiel, vous devez vous demander dans quel processus vous souhaitez partager vos bibliothèques de codes.

Source

2009-07-31 18:32:22

lorsque vous dites pas de support pour les ressources partagées. Dans mon premier exemple, que se passe-t-il si un Projet 3 utilise à la fois le Projet 1 et le Projet 2, ce qui signifie que le Projet 3 n'a qu'une seule solution? – PositiveGuy

c'est là que commence la céphalée: vous pouvez utiliser des externes, mais vous devez faire attention au balisage ou à la dérivation, ou vous pouvez utiliser des checkoutscripts spéciaux, mais où les stocker dans votre référentiel? Je n'ai jamais trouvé une solution parfaite pour les ressources partagées dans SVN. Cependant, vous trouverez rapidement un moyen de les traiter. –

Ok, je vais être un peu plus moralisateur et descendre fermement du côté d'avoir une malle, les étiquettes & branches pour chaque projet.

L'alternative principale est d'avoir un seul tronc, les étiquettes & branches avec tous les projets en dessous. Cependant, cela conduit à un certain nombre de problèmes, dont un est important et je vais détailler ici:

Principalement, il ouvre la voie à la bibliothèque intouchable, où tout le monde a peur de toucher une bibliothèque particulière, car tout changement peut casser quelque chose de subtil dans un projet aléatoire. La raison en est que, puisqu'il n'y a pas de séparation entre les projets, n'importe qui peut effectivement modifier le code de votre projet sans que vous puissiez le détecter ou le contrôler.

Que se passe-t-il un jour où vous extrayez votre projet et qu'il se construit, le jour suivant vous l'extrayez et qu'il échoue, mais vous n'avez pas aucun changement à votre projet. Ce qui est arrivé, c'est que quelqu'un a changé une bibliothèque dont vous dépendiez. Dans une structure volumineuse avec de nombreuses dépendances, il est irréaliste pour un développeur de tester les modifications de sa bibliothèque par rapport à tous les projets, en particulier s'ils doivent apporter des modifications de rupture. Ce dont vous avez besoin dans votre projet est une référence à une version spécifique de la bibliothèque. De cette façon, la bibliothèque n'est mise à jour que lorsque vous modifiez la référence à la dernière version.

Ce type de référence a 3 effets: 1 votre projet est isolé des modifications de développement intermédiaires aléatoires de la bibliothèque. 2 vous obtenez une révision dans votre projet qui vous indique que "j'utilise maintenant cette version de la bibliothèque". 3. Vous pouvez contrôler quand vous apportez les modifications à votre projet pour tenir compte des changements de rupture dans la bibliothèque.

Il y a d'autres problèmes que je peux rencontrer si ce n'est pas suffisant.

Source

2009-08-06 16:50:45

Dans les systèmes comme CVS, vous n'avez pas conservé de "répertoires" séparés. Vous venez étiqueté et ramifié. Cependant, SVN est plus basé sur l'idée de snapshots, et donc des "copies" de choses sont faites très efficacement. Plutôt que d'étiqueter ou de marquer autrement des versions spéciales (ou alternatives) d'un projet, il est plus facile (et plus efficace) d'en faire une copie nommée.

Source

2009-08-06 17:08:56

À mon magasin, nous avons quelque chose comme ceci:

RepositoryMain 
    Trunk 
    proj 1 
    proj 2 
    .. 
    Dev 
    Team1 
     proj 1 
     proj 2 
    Team2 
     proj 1 
     proj 2 
    ...

Je ne sais pas comment cela empile jusqu'à la plupart des endroits, mais il semble fonctionner assez bien

Toutes les équipes de développement peuvent travailler séparément sur leurs propres projets, fusionnant du tronc à leur projet quand ils commencent le développement/l'amélioration, puis se réintègrent au tronc une fois qu'ils sont terminés.

Source

2009-08-06 17:16:45 Stevus

C'est une idée intéressante. C'est presque comme un système de contrôle de source distribuée. –

Merci pour la discussion ici, je suis allé dans cette et project-structure-for-product-with-different-versions

link2

link3

link4

Je pouvais voir terminologies sont source de confusion. Projets, Applications, correctement établir une corrélation entre

voudrais répéter les choses ci-dessus avec exp peu claire Disons que nous faisons solution pour un client ABC Solution est BILLET/HelpDesk application pour les clients de ABC Interroge

Disons que nomApplication est OneDeskApplication. Cette application consiste de WebUI, bibliothèques partagées, créer des outils

pouvons-nous concevoir le SVN comme celui-ci

XSoftware.com/ABC - Dépôt / tronc/ OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp branches/ Branch_Product_Support_1_0_0_0/ OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp Tags/ OneDeskDocs OneDeskMasterBuild

Source

2012-07-05 02:31:27 user1502707

Vous semblez avoir un bon contenu ici, mais c'est un peu un fouillis. – thecoshman

SVN Repository Structure - Pourquoi est-ce mieux?

Répondre

Questions connexes