Devrais-je stocker tous les projets dans un ou plusieurs référentiels?

Question

J'utilise actuellement TortoiseSVN pour gérer quelques projets en cours pour le moment. Lorsque j'ai tout transféré dans le contrôle de code source, je n'étais pas vraiment sûr de la manière dont tout devrait être structuré. J'ai donc mis chaque projet dans son propre référentiel.

Je me demandais si ce serait une bonne idée pour moi de les déplacer tous dans un grand référentiel et de les séparer dans des dossiers de projet? Que font les autres?

À l’heure actuelle, aucun d’entre eux ne partage un code commun, mais il se peut qu’ils le soient ultérieurement. Est-ce que cela faciliterait la gestion s'ils étaient tous ensemble?

Merci.

Answer 1

Cela dépend dans une certaine mesure de ce que vous entendez par "projet".

J'ai un référentiel local général contenant des éléments aléatoires que j'écris (y compris mon site Web, car il est petit). Un référentiel SVN local à utilisateur unique ne souffrira pas de problèmes de performances perceptibles tant que vous n’aurez pas passé beaucoup de temps à taper. A ce moment-là, SVN sera plus rapide de toute façon. Je n’ai donc pas encore regretté d’avoir tout jeté dans un référentiel, même si certains éléments de ce dernier n’ont absolument aucun rapport, à part le fait que j’ai tout écrit.

Si un " projet " signifie "une affectation de la classe", ou "les scripts que j'utilise pour conduire mon TiVo", ou "mes progrès dans l'apprentissage d'une nouvelle langue", puis la création d'une mise en pension par projet me semble un peu inutile. Là encore, cela ne coûte rien non plus. Donc, je suppose que je dirais ne changez pas ce que vous faites. À moins que vous ne souhaitiez vraiment l'expérience de la réorganisation des référentiels, auquel cas changez ce que vous faites: -)

Cependant, si par "projet" vous voulez dire un projet logiciel réel, avec un accès public au référentiel, alors je pense que séparer les pensions par projet est ce qui a du sens: en partie parce qu'il divise les choses proprement et que chaque projet évolue indépendamment, mais aussi parce que c'est ce que les gens s'attendent à voir .

Le partage de code entre des référentiels distincts est moins un problème que vous ne le pensez, car svn a le joli style "svn: externals". fonctionnalité. Cela vous permet de pointer un répertoire de votre référentiel vers un répertoire situé dans un autre référentiel et de le vérifier automatiquement avec vos éléments. Voir, comme toujours, le livre SVN pour plus de détails.

Answer 2

Je les stockerais dans le même référentiel. C'est un peu plus propre. De plus, pourquoi une intégration continue est-elle si importante? Vous pouvez toujours extraire un dossier spécifique du référentiel.

C’est aussi plus facile à administrer - comptes dans un référentiel, journaux d’accès d’un référentiel, etc.

Answer 3

Mon principe de base est de consolider les éléments livrés ensemble. En d'autres termes, si vous pouvez livrer le projet X et le projet Y séparément, placez-les dans des pensions séparées.

Oui, parfois, cela signifie que vous avez un stock énorme pour un projet qui contient un grand nombre de composants, mais les utilisateurs peuvent opérer sur des sous-arbres d'un rapport et cela les oblige à penser au "projet entier". quand ils commettent des modifications au référentiel.

Answer 4

Je garderais absolument chaque projet dans son propre référentiel, séparé de tous les autres. Cela donnera à chaque projet sa propre histoire de commits. Les retours en arrière sur un projet n'affecteront pas les autres projets.

Answer 5

Personnellement, je préfère chaque projet dans son propre référentiel

Answer 6

Si vous travaillez avec beaucoup d'autres personnes, vous pouvez vous demander si tout le monde a besoin du même niveau d'accès à chaque projet. Je pense qu'il est plus facile de donner des droits d'accès par personne si vous mettez chaque projet dans un référentiel séparé. ~~~

Answer 7

Si vous utilisez un référentiel distinct pour chaque projet, vous pouvez utiliser le Balise externe pour faire référence à d’autres référentiels - jusqu’à ce que le code soit partagé.

Answer 8

Tant que chaque projet a / trunk / tags et / branches, ça va. La bonne intégration continue est le critère ici.

Answer 9

Oui, mettez tout dans le contrôle de source.

Si vous utilisez SVN, conservez les projets dans leur propre référentiel - svn est lent et ralentit.

Answer 10

Si vos projets sont indépendants, vous pouvez les conserver dans des référentiels distincts. S'ils partagent des composants, rassemblez-les.

Answer 11

Pour Subversion, je suggérerais de tout mettre dans le même référentiel; la surcharge administrative liée à la mise en place d'un nouveau référentiel est trop importante pour en faire une évidence, vous avez donc plus de chances de ne pas mettre à jour quelque chose et de le regretter plus tard. Subversion fournit de nombreux contrôles d'accès à granularité fine si vous devez restreindre l'accès à une partie de votre référentiel.

Alors que je commence à migrer mes projets vers Mercurial, toutefois, je suis passé à la création d'un référentiel par projet, car il faut simplement un "hg init". pour en créer un nouveau, je peux utiliser le forêt hg extension pour effectuer facilement des opérations sur des référentiels imbriqués. Subversion a svn: externals, qui sont un peu similaires, mais nécessitent plus de charge administrative.