Utilisez-vous le contrôle de version distribué ?
https://stackoverflow.com/questions/26845
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
J'aimerais entendre les personnes qui utilisent le contrôle de version distribué (c'est-à-dire le contrôle de révision distribué, le contrôle de version décentralisé) et comment elles le trouvent.Qu'utilisez-vous, Mercurial, Darcs, Git, Bazaar ?L'utilisez-vous toujours ?Si vous avez utilisé des RC client/serveur dans le passé, le trouvez-vous meilleur, pire ou simplement différent ?Que pourriez-vous me dire pour que je prenne le train en marche ?Ou sautez d'ailleurs, je serais également intéressé d'entendre des personnes ayant des expériences négatives.
Je cherche actuellement à 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 tous ceux qui l'ont utilisé avec des collègues dans d'autres pays, où vos machines ne sont peut-être pas allumées en même temps et où votre 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 :
La solution
J'utilise Mercurial à la fois au travail et dans mes propres projets personnels, et j'en suis vraiment content.Les avantages que je vois sont :
- Contrôle de version local. Parfois, je travaille sur quelque chose et je souhaite conserver un historique des versions, mais je ne suis pas prêt à le transférer vers les référentiels centraux.Avec le VCS distribué, je peux simplement m'engager dans mon dépôt local jusqu'à ce qu'il soit prêt, sans créer de branchement.De cette façon, si d’autres personnes apportent les modifications dont j’ai besoin, je peux toujours les obtenir et les intégrer dans mon code.Quand je suis prêt, je le transmets aux serveurs.
- Moins de conflits de fusion. Cela se produit toujours, mais ils semblent moins fréquents et présentent moins de risques, car tout le code est archivé dans mon dépôt local, donc même si je bâcle la fusion, je peux toujours sauvegarder et recommencer.
- Séparez les dépôts en branches. Si plusieurs vecteurs de développement s'exécutent 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 tombe ou glisse, je n’ai pas besoin de retirer des morceaux.Quand ils sont prêts à partir, je les fusionne simplement.
- 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é un peu pénible.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.
Autres conseils
Là 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.Pouvant également travailler sans accès au réseau, les différences sont plus rapides.
Une commande dans bzr que j'aime 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 valider qu'un seul, vous pouvez utiliser l'extension shelve pour littéralement mettre de côté les autres modifications ultérieurement.Dans Git, vous pouvez faire la même chose en jouant dans l'index (zone de transit), mais bzr a une meilleure interface utilisateur pour cela.
La plupart des gens étaient réticents à se déplacer car ils devaient taper deux commandes pour valider et pousser (bzr ci + bzr push).Il leur était également difficile de comprendre le concept de branches et de fusion (personne n'utilise de branches ni ne les fusionne dans svn).
Une fois que vous aurez compris cela, cela augmentera la productivité du développeur.Jusqu’à ce que tout le monde comprenne cela, il y aura un comportement incohérent de la part de chacun.
Sur mon lieu de travail, nous sommes passés de CVS à Git il y a environ deux mois (la majorité de mon expérience concerne Subversion).Même s'il y a 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 :flexibilité de l'environnement de travail et fusion.
Je n'ai pas besoin d'être sur notre VPN, ni même d'avoir une connectivité réseau, pour avoir accès aux capacités complètes de gestion des versions.Cela signifie que je peux expérimenter des idées ou effectuer de grandes refactorisations partout où je me trouve lorsque l'envie me vient, sans avoir à me rappeler d'enregistrer cet énorme commit que j'ai construit ou à m'inquiéter de ne pas pouvoir revenir en arrière lorsque je fais un gâchis.
Étant donné que 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.
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 moyen d'avoir des points de contrôle privés sans avoir à se soucier des branches CVS (et en particulier de les fusionner) et nous commençons à utiliser Mercurial pour certaines branches comptant jusqu'à environ 5 personnes.Il y a de fortes chances que nous abandonnions enfin CVS dans un an.Notre utilisation de Mercurial s'est développée de manière organique ;certaines personnes n'y touchent même jamais, parce qu'elles sont satisfaites de CVS.Tous ceux qui ont essayé Mercurial en sont finalement satisfaits, sans grande courbe d'apprentissage.
Ce qui fonctionne vraiment bien pour nous avec Mercurial, c'est que nos serveurs d'intégration continue (faits maison) peuvent surveiller les référentiels Mercurial des développeurs ainsi que la ligne principale.Ainsi, les gens s'engagent dans leur référentiel, demandent à notre serveur d'intégration continue de le vérifier, puis publient l'ensemble des modifications.Nous prenons en charge de nombreuses plates-formes, 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 lorsqu'elles sont difficiles, vous disposez des informations dont vous avez besoin pour faire du bon travail lors de la fusion.Une fois que quelqu'un fait fonctionner la version fusionnée, il peut pousser ses ensembles de modifications de fusion et personne d'autre n'a à répéter l'effort.
Le plus gros obstacle est que vous devez recâbler le cerveau de vos développeurs et managers afin qu’ils s’éloignent du modèle de branche linéaire unique.Le meilleur remède pour cela est une dose de Linus Torvalds vous informant que vous êtes stupide et laid 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 tous deux bien pour nous avec les développeurs utilisant un mélange de Windows, Linux et Solaris, et je n'ai remarqué aucun problème avec les fuseaux horaires.(Vraiment, ce n'est pas trop difficile ;vous utilisez simplement les secondes d'époque en interne, et je m'attendrais à ce que tous les principaux systèmes SCM réussissent).
Il a été possible, avec beaucoup d'efforts, d'importer notre historique CVS principal dans Mercurial.Cela aurait été plus facile si les gens n'avaient pas délibérément introduit des cas particuliers dans notre historique CVS principal afin de tester les outils de migration de l'historique.Cela impliquait la fusion de certaines branches Mercurial dans l'historique CVS, de sorte que le projet semble avoir été utilisé dès le premier jour.
Notre groupe de conception silicium a choisi Subversion.Ils se trouvent principalement à huit fuseaux horaires de mon bureau, et même sur une assez bonne ligne dédiée entre nos bureaux, les extractions Subversion sont pénibles, mais réalisables.Un gros avantage des systèmes centralisés est que vous pouvez potentiellement y archiver de gros fichiers binaires (par ex.versions du fournisseur) sans rendre tous les référentiels distribués énormes.
Nous utilisons git pour travailler avec le noyau Linux.Git nous conviendrait mieux une fois qu'une version native de Windows serait mature, mais je pense que le design de Mercurial est si simple et élégant que nous le conserverons.
Je n'utilise pas moi-même le contrôle de source distribué, mais peut-être que ces questions et réponses connexes vous donnent quelques idées :
J'utilise personnellement le système de contrôle de source Mercurial.Je l'utilise depuis un peu plus d'un an maintenant.C'était en fait ma première expérience avec un VSC.
J'ai essayé Git, mais je n'ai jamais vraiment poussé parce que je trouvais que c'était trop pour ce dont j'avais besoin.Mercurial est vraiment facile à prendre en main si vous êtes un utilisateur de Subversion car il partage de nombreuses commandes avec lui.De plus, je trouve la gestion de mes référentiels vraiment simple.
J'ai 2 façons de partager mon code avec des gens :
- Je partage un serveur avec un collègue et nous gardons un dépôt principal pour notre projet.
- Pour certains projets OSS sur lesquels je travaille, nous créons des correctifs de notre travail avec Mercurial (hg export) et le mainteneur du projet les applique simplement sur le référentiel (hg import)
Vraiment facile à utiliser, mais très puissant.Mais généralement, le choix d'un VSC dépend vraiment des besoins de notre projet...
Avant d'éteindre les postes de travail Sun pour le développement de systèmes embarqués, nous utilisions les logiciels Sun. TeamWare solution.TeamWare est une solution entièrement distribuée utilisant SCCS comme système de révision de fichiers de référentiel local, puis l'encapsulant avec un ensemble d'outils pour gérer les opérations de fusion (effectuées via le renommage de branche) vers les référentiels centralisés qui peuvent être nombreux.En fait, comme il est distribué, il n'y a pas vraiment de référentiel maître en soi (sauf par convention si vous le souhaitez) et tous les utilisateurs ont leurs propres copies de l'intégralité de l'arborescence des sources et des révisions.Lors des opérations de « remise en place », l'outil de fusion utilisant des différences à trois voies trie algorithmiquement ce qui est quoi et vous permet de combiner les modifications de différents développeurs qui se sont accumulées au fil du temps.
Après être passé à Windows pour notre plateforme de développement, nous avons fini par passer à AccuRév.Même si AccuRev, car dépendant d'un serveur centralisé, n'est pas véritablement une solution distribuée, elle s'en rapproche logiquement beaucoup d'un modèle de workflow.Là où TeamWare aurait eu des copies complètement séparées de tout sur chaque client, y compris toutes les révisions de tous les fichiers, sous AccuRev, celles-ci sont conservées dans la base de données centrale et les machines clientes locales n'ont que la version actuelle du fichier plat pour l'édition locale.Cependant, ces copies locales peuvent être versionnées via la connexion client au serveur et suivies de manière complètement séparée de toute autre modification (c'est-à-dire :branches) implicitement créées par d'autres développeurs
Personnellement, je pense que le modèle distribué mis en œuvre par TeamWare ou le type de modèle hybride mis en œuvre par AccuRev est supérieur aux solutions complètement centralisées.La raison principale en est qu'il n'est pas nécessaire d'extraire un fichier ou de verrouiller un fichier par un autre utilisateur.De plus, les utilisateurs n'ont pas besoin de créer ou de définir les branches ;les outils le font implicitement pour vous.Lorsqu'il existe des équipes plus grandes ou différentes équipes qui contribuent à ou maintiennent un ensemble de fichiers sources, cela résout les collisions liées au verrouillage "générées par l'outil" et permet aux modifications de code d'être davantage coordonnées au niveau du développeur qui doit finalement coordonner les modifications de toute façon.Dans un sens, le modèle distribué permet un « verrouillage » beaucoup plus fin que le verrouillage à granularité institué par les modèles centralisés.
J'ai utilisé des darcs sur un grand projet (GHC) et pour de nombreux petits projets.J'ai une relation amour/haine avec Darcs.
Avantages :référentiel incroyablement facile à configurer.Très facile de déplacer les modifications entre les référentiels.Très facile à cloner et à essayer des « branches » dans des référentiels séparés.Très facile de prendre des « commits » en petits groupes cohérents, cela a du sens.Très facile à renommer les fichiers et les identifiants.
Inconvénients :aucune notion d'histoire : on ne peut pas retrouver « l'état des choses au 5 août ».Je n'ai jamais vraiment compris comment utiliser darcs pour revenir à une version antérieure.
Rupture d'affaire :darcs n'est pas mis à l'échelle.J'ai (et bien d'autres) eu de gros problèmes avec GHC en utilisant des darcs.Je l'ai accroché avec une utilisation à 100% du processeur pendant 9 jours en essayant de tirer 3 mois de changements.J'ai eu une mauvaise expérience l'été dernier où j'ai perdu deux semaines en essayant de faire fonctionner DARCS et j'ai finalement recouru à rejouer tous mes changements à la main dans un référentiel immaculé.
Conclusion:darcs est idéal si vous voulez un moyen simple et léger de vous empêcher de vous tirer une balle dans le pied pour vos projets de loisirs.Mais même avec certains des problèmes de performances résolus dans darcs 2, ce n'est toujours pas destiné aux éléments de puissance industrielle.Je ne croirai pas vraiment aux darcs tant que la tant vantée « théorie des correctifs » ne sera pas quelque chose de plus que quelques équations et quelques belles images ;Je veux voir une vraie théorie publiée dans un lieu arbitré.Il est grand temps.
J'aime vraiment Git, surtout avec GitHub.C'est tellement agréable de pouvoir s'engager et revenir en arrière localement.Et la sélection des fusions, bien que non triviale, n'est pas terriblement difficile et bien plus avancée que tout ce que Svn ou CVS peuvent faire.
Mon groupe au travail utilise Git, et cela fait toute la différence dans le monde.Nous utilisions SCCS et une pile de scripts csh pour gérer des projets assez volumineux et compliqués partageant du code entre eux (tentative de toute façon).
Avec Git, la prise en charge des sous-modules facilite beaucoup de choses et seul un minimum de scripts est nécessaire.Nos efforts d’ingénierie de versions ont été considérablement réduits car les branches sont faciles à maintenir et à suivre.Être capable de créer des branches et de fusionner à moindre coût rend vraiment facile la maintenance d'une seule collection de sources sur plusieurs projets (contrats), alors qu'avant, toute perturbation du flux typique des choses était très, très coûteuse.Nous avons également constaté que la capacité de script de Git est un énorme de plus, parce que nous pouvons personnaliser son comportement via des hooks ou via des scripts qui le font . git-sh-setup, et cela ne ressemble plus à un tas de bidouilles comme avant.
Nous avons aussi parfois des situations dans lesquelles nous devons maintenir notre contrôle de version sur des sites distribués et non en réseau (dans ce cas, des laboratoires sécurisés déconnectés), et Git dispose de mécanismes pour gérer cela de manière assez fluide (les bundles, le mécanisme de clonage de base, les formats formatés). correctifs, etc.).
Cela vient en partie du fait que nous sortons du début des années 80 et adoptons des mécanismes de contrôle de version modernes, mais Git "a bien fait les choses" dans la plupart des domaines.
Je ne suis pas sûr de l'étendue de la réponse que vous recherchez, mais notre expérience avec Git a été très, très positive.
Utiliser Subversion avec SourceForge et d'autres serveurs sur un certain nombre de connexions différentes avec des équipes de taille moyenne et cela fonctionne très bien.
Je suis un fervent partisan du contrôle de source centralisé pour de nombreuses raisons, mais j'ai brièvement essayé BitKeeper sur un projet.Peut-être qu'après des années d'utilisation d'un modèle centralisé dans un format ou un autre (Perforce, Subversion, CVS), j'ai simplement trouvé le contrôle de source distribué difficile à utiliser.
Je pense que nos outils ne devraient jamais gêner le travail réel ;ils devraient faciliter le travail.Alors, après quelques expériences époustouflantes, j’ai renoncé.Je conseillerais de faire des tests très approfondis avec votre équipe avant de faire bouger le bateau, car le modèle est très différent de celui auquel la plupart des développeurs sont probablement habitués dans le monde SCM.
j'ai utilisé bazar depuis un petit moment maintenant et j'adore ça.Les branchements triviaux et la fusion donnent une grande confiance dans l'utilisation des branches comme elles devraient l'être.(Je sais que les outils vcs centraux devraient permettre cela, mais les outils courants, y compris Subversion, ne le permettent pas facilement).
bzr prend en charge un certain nombre de flux de travail du solo au travail en tant que référentiel centralisé jusqu'à la distribution complète.Chaque branche (pour un développeur ou une fonctionnalité) pouvant être fusionnée indépendamment, les révisions de code peuvent être effectuées branche par branche.
bzr a aussi un super plugin (bzr-svn) vous permettant de travailler avec un dépôt Subversion.Vous pouvez faire une copie du dépôt svn (ce qui prend initialement un certain temps car il récupère l'intégralité de l'historique de votre dépôt local).Vous pouvez ensuite créer des branches pour différentes fonctionnalités.Si vous souhaitez apporter une solution rapide au tronc à mi-chemin de votre fonctionnalité, vous pouvez créer une branche supplémentaire, y travailler, puis fusionner de nouveau avec le tronc, laissant votre fonctionnalité à moitié terminée intacte et à l'extérieur du tronc.Merveilleux.Jusqu’à présent, travailler contre la subversion a été ma principale utilisation.
Notez que je ne l'ai utilisé que sous Linux, et principalement à partir de la ligne de commande, bien qu'il soit censé fonctionner correctement sur d'autres plates-formes, il possède des interfaces graphiques telles que TortueBZR et beaucoup de travail est en cours sur l'intégration avec IDE etc.
Je joue avec Mercurial pour mes projets personnels.Jusqu’à présent, ce que j’aime, c’est que je peux avoir plusieurs référentiels.Si j'emporte mon ordinateur portable en cabine, j'ai toujours le contrôle de version, contrairement à l'époque où j'exécutais CVS à la maison.Le branchement est aussi simple que hg clone et travailler sur le clone.
Utiliser Subversion
Subversion n'est pas distribué, ce qui me fait penser que j'ai besoin d'un lien wikipedia au cas où les gens ne seraient pas sûrs de ce dont je parle :)
J'utilise darcs 2.1.0 et c'est idéal pour mes projets.Facile à utiliser.J’adore les changements de cueillette des cerises.
J'utilise Git au travail, avec un de mes collègues.Cependant, le référentiel principal est SVN.Nous devons souvent changer de poste de travail et Git permet d'extraire très facilement les modifications d'un référentiel local sur une autre machine.Lorsque nous travaillons en équipe sur la même fonctionnalité, fusionner nos travaux se fait sans effort.
Le pont git-svn est un peu bancal, car lors de l'enregistrement dans SVN, il réécrit tous les commits pour ajouter son commentaire git-svn-id.Cela détruit la belle histoire des fusions entre le dépôt de mon collègue et le mien.Je prédis que nous n'utiliserions pas du tout de référentiel central si chaque membre de l'équipe utilisait Git.
Vous n'avez pas dit sur quel système d'exploitation vous développez, mais Git présente l'inconvénient de devoir utiliser la ligne de commande pour obtenir toutes les fonctionnalités.Gitk est une interface graphique intéressante pour visualiser l'historique des fusions, mais la fusion elle-même doit être effectuée manuellement.Git-Gui et les plugins Visual Studio ne sont pas encore très perfectionnés.
Nous utilisons un contrôle de version distribué (SCM en plastique) pour les scénarios multi-sites et déconnectés.
1- Multi-sites :si vous avez des groupes distants, vous ne pouvez parfois pas compter sur la connexion Internet, ou elle n'est pas assez rapide et ralentit les développeurs.Ensuite, avoir un serveur indépendant qui peut se synchroniser (Plastic réplique les branches d'avant en arrière) est très utile et accélère les choses.C'est probablement l'un des scénarios les plus courants pour les entreprises puisque la plupart d'entre elles sont encore préoccupées par les pratiques « totalement distribuées » où chaque développeur dispose de son propre référentiel répliqué.
2- Déconnecté (ou véritablement distribué si vous préférez) :chaque développeur possède son propre référentiel qui est répliqué dans les deux sens avec ses pairs ou avec l'emplacement central.Il est très pratique de se rendre chez un client ou simplement de rentrer chez soi avec son ordinateur portable, et de continuer à pouvoir changer de succursale, de code de paiement et d'enregistrement, de consulter l'historique, d'exécuter des annotations, etc., sans avoir à accéder au "central" distant. serveur.Ensuite, chaque fois que vous retournez au bureau, vous répliquez simplement vos modifications (normalement des branches) en quelques clics.
