Utilisez-vous le contrôle de version distribué ?

Question

J'aimerais connaître l'avis des personnes qui utilisent le contrôle de version distribué (alias contrôle de révision distribué, contrôle de version décentralisé) et savoir comment elles le trouvent. Qu'utilisez-vous, Mercurial, Darcs, Git, Bazaar ? L'utilisez-vous encore ? Si vous avez utilisé le rcs client/serveur dans le passé, le trouvez-vous meilleur, pire ou simplement différent ? Que pourriez-vous me dire qui me ferait sauter dans le train en marche ? Ou de m'en écarter, car j'aimerais connaître l'avis de personnes ayant eu des expériences négatives.

J'envisage actuellement de remplacer notre système de contrôle de source actuel (Subversion), ce qui est à l'origine de cette question.

Je serais particulièrement intéressé par ceux qui l'ont utilisé avec des collègues dans d'autres pays, où les machines ne sont pas forcément allumées en même temps et où la connexion est très lente.

Si vous n'êtes pas sûr de ce qu'est le contrôle de version distribué, voici quelques articles :

Introduction au contrôle de version distribué

Entrée sur Wikipédia

Answer 1

J'ai utilisé Mercurial à la fois au travail et dans mes projets personnels, et j'en suis vraiment satisfait. Les avantages que je vois sont :

1. Contrôle de la version locale. Parfois, je travaille sur quelque chose, et je veux garder un historique des versions, mais je ne suis pas prêt à le pousser vers les dépôts centraux. Avec un VCS distribué, je peux simplement commiter dans mon dépôt local jusqu'à ce qu'il soit prêt, sans branchement. De cette façon, si d'autres personnes apportent des modifications dont j'ai besoin, je peux toujours les obtenir et les intégrer dans mon code. Lorsque je suis prêt, je le pousse vers les serveurs.
2. Moins de conflits de fusion. Cela arrive encore, mais c'est moins fréquent et le risque est moindre, car tout le code est archivé dans mon dépôt local, donc même si je rate la fusion, je peux toujours revenir en arrière et recommencer.
3. Séparer les dépôts comme des branches. Si j'ai plusieurs vecteurs de développement qui fonctionnent en même temps, je peux simplement créer plusieurs clones de mon dépôt et développer chaque fonctionnalité indépendamment. De cette façon, si quelque chose est mis au rebut, je n'ai pas besoin de retirer des morceaux. Lorsqu'ils sont prêts à être utilisés, je les fusionne simplement.
4. Vitesse. Mercurial est beaucoup plus rapide à utiliser, principalement parce que la plupart de vos opérations courantes sont locales.

Bien sûr, comme tout nouveau système, la transition a été douloureuse. Vous devez penser au contrôle de version différemment de ce que vous faisiez lorsque vous utilisiez SVN, mais dans l'ensemble, je pense que cela en vaut vraiment la peine.

Answer 2

À l'endroit où je travaille, nous avons décidé de passer de SVN à Bazaar (après avoir évalué git et mercurial). Bazaar était facile à démarrer, avec des commandes simples (pas comme les 140 commandes de git).

L'avantage que nous voyons est la possibilité de créer des branches locales et de travailler dessus sans perturber la version principale. Le fait de pouvoir travailler sans accès au réseau permet également d'effectuer les diffs plus rapidement.

Une commande de bzr que j'aime bien est l'extension shelve. Si vous commencez à travailler sur deux morceaux de code logiquement différents dans un seul fichier et que vous souhaitez n'en livrer qu'un seul, vous pouvez utiliser l'extension shelve pour littéralement mettre de côté les autres changements plus tard. Dans Git, vous pouvez faire la même chose en jouant dans l'index (staging area) mais bzr a une meilleure interface utilisateur pour cela.

La plupart des personnes étaient réticentes à l'idée de passer à la nouvelle version car elles devaient taper deux commandes pour commiter et pousser (bzr ci + bzr push). Il leur était également difficile de comprendre le concept de branches et de fusions (personne n'utilise de branches ou de fusions dans svn).

Une fois que vous aurez compris cela, la productivité du développeur s'en trouvera accrue. Jusqu'à ce que tout le monde comprenne cela, il y aura un comportement incohérent entre tous.

Answer 3

Sur mon lieu de travail, nous sommes passés de CVS à Git il y a environ deux mois (la majorité de mon expérience est avec Subversion). Bien qu'il y ait eu une courbe d'apprentissage pour se familiariser avec le système distribué, j'ai trouvé que Git était supérieur dans deux domaines clés : la flexibilité de l'environnement de travail et la fusion.

Je n'ai pas besoin d'être sur notre VPN, ni même d'avoir une connectivité réseau, pour avoir accès à toutes les fonctionnalités de gestion des versions. Cela signifie que je peux expérimenter des idées ou effectuer des remaniements importants où que je me trouve lorsque l'envie m'en prend, sans avoir à me rappeler de vérifier l'énorme commit que j'ai créé ou à m'inquiéter de ne pas pouvoir revenir en arrière lorsque je fais des erreurs.

Comme les fusions sont effectuées côté client, elles sont beaucoup plus rapides et moins sujettes aux erreurs que le lancement d'une fusion côté serveur.

Answer 4

Mon entreprise utilise actuellement Subversion, CVS, Mercurial et git.

Lorsque nous avons commencé il y a cinq ans, nous avons choisi CVS, et nous l'utilisons toujours dans ma division pour notre branche principale de développement et de maintenance des versions. Cependant, beaucoup de nos développeurs utilisent Mercurial individuellement comme un moyen d'avoir des points de contrôle privés sans la douleur des branches CVS (et particulièrement leur fusion) et nous commençons à utiliser Mercurial pour certaines branches qui ont jusqu'à environ 5 personnes. Il y a de fortes chances que nous abandonnions finalement CVS dans un an. Notre utilisation de Mercurial s'est développée de manière organique ; certaines personnes n'y touchent toujours pas, car elles sont satisfaites de CVS. Tous ceux qui ont essayé Mercurial ont fini par en être satisfaits, sans trop de difficultés d'apprentissage.

Ce qui fonctionne très bien pour nous avec Mercurial, c'est que nos serveurs d'intégration continue (faits maison) peuvent surveiller les dépôts Mercurial des développeurs ainsi que la ligne principale. Ainsi, les gens commettent dans leur dépôt, demandent à notre serveur d'intégration continue de le vérifier, puis publient le jeu de modifications. Nous prenons en charge de nombreuses plates-formes et il n'est donc pas possible d'effectuer un niveau décent de vérifications manuelles. Un autre avantage est que les fusions sont souvent faciles, et quand elles sont difficiles, vous disposez des informations nécessaires pour faire un bon travail sur la fusion. Une fois que quelqu'un a réussi à faire fonctionner la version fusionnée, il peut pousser ses jeux de modifications de fusion et personne d'autre ne doit répéter l'effort.

Le plus gros obstacle est que vous devez recâbler le cerveau de vos développeurs et gestionnaires pour qu'ils s'éloignent du modèle de la branche linéaire unique. Le meilleur remède pour cela est une dose de Linus Torvalds vous disant que vous êtes stupide et moche si vous utilisez un SCM centralisé. De bons outils de visualisation de l'historique seraient utiles, mais je ne suis pas encore satisfait de ce qui est disponible.

Mercurial et CVS fonctionnent bien pour nous, avec des développeurs qui utilisent un mélange de Windows, Linux et Solaris, et je n'ai remarqué aucun problème avec les fuseaux horaires. (En réalité, ce n'est pas trop difficile ; il suffit d'utiliser les secondes d'époque en interne, et je pense que tous les principaux systèmes SCM le font correctement).

Il a été possible, avec un certain effort, d'importer notre historique CVS dans Mercurial. Cela aurait été plus facile si des personnes n'avaient pas délibérément introduit des cas de figure dans notre historique CVS principal afin de tester les outils de migration d'historique. Cela a inclus la fusion de certaines branches Mercurial dans l'historique CVS, de sorte que le projet ressemble à ce qu'il utilisait dès le premier jour.

Notre groupe de conception de silicium a choisi Subversion. Ils sont pour la plupart à huit fuseaux horaires de mon bureau, et même sur une ligne dédiée assez bonne entre nos bureaux, les vérifications de Subversion sont douloureuses, mais réalisables. Un grand avantage des systèmes centralisés est que vous pouvez potentiellement y archiver de gros binaires (par exemple les versions des fournisseurs) sans rendre tous les dépôts distribués énormes.

Nous utilisons git pour travailler avec le noyau Linux. Git nous conviendra mieux lorsqu'une version native pour Windows sera mature, mais je pense que la conception de Mercurial est si simple et élégante que nous nous y tiendrons.

Answer 5

Je n'utilise pas moi-même le contrôle de source distribué, mais peut-être que ces questions et réponses connexes vous donneront un aperçu :

• Options de contrôle des sources distribuées
• Pourquoi git est-il meilleur que Subversion