Je code principalement de petits programmes pour moi-même, mais récemment, j'ai commencé à coder pour mes pairs dans mon équipe. À cette fin, j'ai commencé à utiliser un référentiel Mercurial pour maintenir mon code sous une forme de contrôle de version (plus précisément, Tortoise-Hg sous Windows). J'ai beaucoup de petits scripts, chacun dans leur propre répertoire, tous sous un seul dépôt. Cependant, en lisant Joel's Hg Tutorial, j'ai essayé de cloner un répertoire pour un de mes plus gros scripts pour créer une version "stable" et j'ai trouvé que je ne pouvais pas le faire car le répertoire n'était pas lui-même un dépôt. Donc, je suppose (et corrigez-moi si je me trompe) que pour utiliser correctement le clonage, je devrais créer un référentiel pour chaque script/répertoire. Mais .. serait-ce une "bonne idée" ou un cauchemar d'entretien à venir? Par la suite, est-ce que je conserve tous mes scripts (sans rapport) dans un seul référentiel, ou devrais-je créer un référentiel pour chacun d'entre eux? Ou une troisième option inconnue?Combien de dépôts devrais-je utiliser pour maintenir mes scripts sous contrôle de version?
Répondre
Utilisez des mises en attente séparées pour tout ce que vous pourriez vouloir utiliser de façon indépendante à un moment donné. Il est très facile de combiner repos dans le futur et beaucoup plus difficile de les séparer. La fonctionnalité subrepos (comme svn externals) vous permet même de faire un repo parapluie qui inclut tous les petits repos si c'est encore quelque chose que vous aimeriez pouvoir cloner en une seule commande.
La création d'un référentiel distinct pour chaque répertoire réel serait probablement une bonne idée, car il le sépare du reste de votre code. Tout comme la modularité dans le codage est bénéfique, la modularité dans les référentiels l'est tout autant. Si vous vouliez publier l'un de vos scripts sur quelque chose comme GitHub, il est plus facile si les repos sont déjà séparés.
Cependant, si vous avez un tas de petits scripts qui ont un long fichier, vous pouvez probablement les conserver sous un seul dépôt. Cependant, si vous avez déjà voulu en publier les révisions, vous devrez les relâcher tous en même temps.
En principe, des référentiels distincts sonnent bien. Mais je ne suis pas sûr que cette approche évolue. J'ai écrit plus de mille scripts dans mon répertoire ~/bin seul. Ceux-ci sont tous stockés dans un référentiel unique. Ces scripts sont petit: la longueur moyenne est de 150 lignes, mais cela est trompeur — seulement environ 15% des scripts sont plus de 100 lignes.
Je ne vois pas le cas d'utilisation pour les mettre dans des repos séparés. Si je veux partager avec d'autres développeurs, je n'envoie généralement que du code source. Ils ne changent pas beaucoup: la moitié des scripts n'ont pas été modifiés depuis juin 2005 et seulement 5% ont été modifiés au cours des six derniers mois. Donc, la plupart du code est raisonnablement stable, il n'y a pas beaucoup de corrections de bugs, et l'histoire n'est pas intéressante.
Je voudrais aller avec un seul repo jusqu'à ce que vous voyez un besoin démontré.
Utilisez un référentiel pour chaque projet et pour chaque bloc logique de mini-projets.
hg fonction de sous-boucle n'est pas encore prête pour le prime-time, à mon avis; quelques commandes hg de base ne comprennent pas les sous-états et vous pouvez donc vous poignarder assez facilement, surtout avec du code partagé. Vous pouvez trouver plus d'informations sur les sous-dépôts dans les dernières notes de mise à jour pour hg.
Existe-t-il une commande Mercurial analogue à 'git filter-branch'? C'est comme ça que vous déplacez les choses dans les sous-états avec git. C'est effrayant mais assez facile une fois qu'on l'a appris. – intuited
J'ai vu svn externals dénommé un anti-pattern; les sous-dépôts partagent-ils les mêmes problèmes que svn externals? – romandas
@romandas Ce n'est pas comme ça que j'aime faire les choses. Je laisse les dépendances s'exprimer par mes outils de construction (ivy!) Et non par mon contrôle de source. Je pense que cela apporte un meilleur découplage et un meilleur suivi des versions requises à chaque étape du développement. http://stackoverflow.com/questions/2392404/dvcs-how-structure-with-large-integrated-code-base-with-multiple-projects-sharin/2393475#2393475 –