mercurial cas d'utilisation solution

Question

le projet dans lequel je suis impliqué a beaucoup de petits modules qui sont gérés par différents développeurs.Nous utilisons actuellement svn mais voulant passer à mercurial, comme nous devons aller sur le site client et faire un Un peu de développement et donc il devient difficile de gérer les versions ..

Mais le coffre complet est énorme d'environ 4-5 Go et la création d'un seul repo pour tous les modules signifie que si jamais j'ai besoin de regrouper le repo j'ai besoin pour déplacer ce 4-5 Gigs de fichier .. et je ne peux pas prendre une sauvegarde des modules plus petits (car ils n'ont pas de dossier. Hg) qui sont dans un dossier de base où le dossier. Hg existe, car il ne me donnerait pas façon de commuter à partir du module sauvegardé (dossier) .. alors quelle est la meilleure façon de faire face à une telle situation où un projet a de nombreux modules et dire ... un Tous les développeurs prennent leurs propres modules (en gardant la taille des données à transférer au minimum) avec eux, codent où ils veulent et ensuite ramener et fusionner leur branche.

Une chose qui me vient à l'esprit est que chaque module devient un repo, mais qu'il serait difficile de gérer spécialement quand un produit intégré sera publié. Quelle version serait cette version? comme tous les modules auraient leur propre histoire de version ??

et un cas plus évident serait si je convertis l'histoire svn complète en mercurial .. alors cette conversion si fait sur le tronc, il ferait un seul repo mais avec une taille énorme .. et chaque propriétaire de module prenant cet énorme paquet avec lui chaque fois serait insignifiant ..

Alors des suggestions?

Merci.

Answer 1

Tonfa le dit dans un commentaire, mais je vais le mettre là comme réponse: Utilisez le Submodule Support de Mercurial. Il est expirimental, mais il est arrivé à travers les mois de la version 1.3 sans un bug ou un changement majeur, donc je soupçonne qu'il est dans la zone où les changements à venir seront rétrocompatibles. De plus, si vous avez de très gros fichiers (> 10 Mo) gonflant le repo, vous pouvez utiliser le Big Files Extension pour les sortir du contrôle direct, mais suivre leur version. En général, cependant, je trouve que si je rends mes scripts de construction suffisamment complets pour qu'ils téléchargent de gros assets non édités à la main au lieu de les placer dans le contrôle de source, les repos n'ont pas tendance à passer à 4 ou 5 GB - c'est beaucoup de KLoC. Peut-être que cette migration est un bon moment pour utiliser un outil de téléchargement de dépendance comme Ivy ou tout ce qui est adapté à votre environnement de développement.

Answer 2

Sur les sites Web, nous mettons tous les fichiers sauf MP3 et FLV sous mercurial et nous obtenons rarement plus de 300 Mo. D'ailleurs, le disque est bon marché. Si vous avez des problèmes de bande passante entre vous et le site client (ou des problèmes de sécurité), vous pouvez simplement cloner l'arbre entier sur une clé USB, aller sur le site client et pirater, puis revenir à la maison et modifier la fusion. Mercurial a fondamentalement changé la façon dont je vois le contrôle de version.

Des trucs comme ça étaient une grosse affaire et maintenant ... hein.