web-dev-qa-db-fra.com

Je suis un geek de Subversion, pourquoi devrais-je considérer ou non Mercurial ou Git ou tout autre DVCS?

J'essaie de comprendre les avantages du système de contrôle de version distribué (DVCS).

J'ai trouvé Subversion Re-education et cet article par Martin Fowler très utile.

Mercurial et autres DVCS promeuvent une nouvelle façon de travailler sur le code avec des changesets et des commits locaux. Il empêche la fusion de l'enfer et d'autres problèmes de collaboration

Nous ne sommes pas affectés par cela car je pratique intégration continue et travailler seul dans une branche privée n'est pas une option, sauf si nous expérimentons. Nous utilisons une branche pour chaque version majeure, dans laquelle nous corrigeons les bugs fusionnés à partir du tronc.

Mercurial vous permet d'avoir des lieutenants

Je comprends que cela peut être utile pour de très grands projets comme Linux, mais je ne vois pas la valeur dans de petites équipes hautement collaboratives (5 à 7 personnes).

Mercurial est plus rapide, prend moins d'espace disque et la copie locale complète permet des opérations de journaux et de différences plus rapides.

Cela ne m'inquiète pas non plus, car je n'ai pas remarqué de problèmes de vitesse ou d'espace avec SVN même avec de très gros projets sur lesquels je travaille.

Je recherche vos expériences et/ou opinions personnelles d'anciens geeks SVN. Surtout en ce qui concerne le concept des changesets et les performances globales vous avez mesuré.

MISE À JOUR (12 janvier) : Je suis maintenant convaincu que cela vaut la peine d'essayer.

MISE À JOUR (12 juin) : J'ai embrassé Mercurial et j'ai bien aimé. Le goût de sa cerise locale s'engage. J'ai embrassé Mercurial juste pour l'essayer. J'espère que mon serveur SVN ne me dérange pas. C'était tellement mal. C'était si bien. Ne veux pas dire que je suis amoureux ce soir .

MISE À JOUR FINALE (29 juillet) : J'ai eu le privilège de réviser Eric Sink le prochain livre intitulé Version Contrôle par l'exemple . Il a fini de me convaincre. J'irai pour Mercurial.

version-controlgitmercurialdvcssvn
304
user2567

Remarque: Voir "MODIFIER" pour la réponse à la question actuelle

Tout d'abord, lisez Subversion Re-education par Joel Spolsky. Je pense que la plupart de vos questions recevront une réponse.

Une autre recommandation, le discours de Linus Torvalds sur Git: http://www.youtube.com/watch?v=4XpnKHJAok8 . Cet autre pourrait également répondre à la plupart de vos questions, et c'est assez amusant.

BTW, quelque chose que je trouve assez drôle: même Brian Fitzpatrick & Ben Collins-Sussman, deux des créateurs originaux de Subversion ont déclaré dans un discours google "désolé pour ça" faisant référence à Subversion étant inférieure à Mercurial (et aux DVCS en général).

Maintenant, l'OMI et en général, la dynamique d'équipe se développe plus naturellement avec n'importe quel DVCS, et un avantage exceptionnel est que vous pouvez vous engager hors ligne car cela implique les choses suivantes:

  • Vous ne dépendez pas d'un serveur et d'une connexion, ce qui signifie des temps plus rapides.
  • Ne pas être esclave d'endroits où vous pouvez obtenir un accès Internet (ou un VPN) juste pour pouvoir vous engager.
  • Tout le monde a une sauvegarde de tout (fichiers, historique), pas seulement du serveur. Signifiant que n'importe qui peut devenir le serveur .
  • Vous pouvez vous engager de manière compulsive si vous en avez besoin sans salir le code des autres . Les commits sont locaux. Vous ne marchez pas sur les orteils les uns des autres en vous engageant. Vous ne cassez pas les versions ou les environnements des autres simplement en vous engageant.
  • Les personnes sans "accès de validation" peuvent s'engager (car la validation dans un DVCS n'implique pas le téléchargement de code), abaissant la barrière pour les contributions, vous pouvez décider de retirer leurs modifications ou non en tant qu'intégrateur.
  • Cela peut renforcer la communication naturelle, car un DVCS rend cela essentiel ... dans Subversion, ce que vous avez à la place, ce sont des courses de validation, qui forcent la communication, mais en gênant votre travail.
  • Les contributeurs peuvent s'associer et gérer leur propre fusion, ce qui signifie finalement moins de travail pour les intégrateurs.
  • Les contributeurs peuvent avoir leurs propres succursales sans affecter les autres (mais être en mesure de les partager si nécessaire).

À propos de vos points:

  • La fusion de l'enfer n'existe pas dans DVCSland; n'a pas besoin d'être manipulé. Voir le point suivant .
  • Dans les DVCS, tout le monde représente une "branche", ce qui signifie qu'il y a des fusions chaque fois que des modifications sont tirées. Les branches nommées sont une autre chose.
  • Vous pouvez continuer à utiliser l'intégration continue si vous le souhaitez. Pas nécessaire à mon humble avis, pourquoi ajouter de la complexité?, Il suffit de garder vos tests dans le cadre de votre culture/politique.
  • Mercurial est plus rapide dans certaines choses, git est plus rapide dans d'autres choses. Pas vraiment aux DVCS en général, mais à leurs implémentations particulières AFAIK.
  • Tout le monde aura toujours le projet complet, pas seulement vous. La chose distribuée a à voir avec le fait que vous pouvez valider/mettre à jour localement, le partage/prélèvement depuis l'extérieur de votre ordinateur s'appelle pousser/tirer.
  • Encore une fois, lisez Subversion Re-education. Les DVCS sont plus faciles et plus naturels, mais ils sont différents, n'essayez pas de penser que cvs/svn === base de tous les versions.

Je contribuais à la documentation du projet Joomla pour aider à prêcher une migration vers DVCS, et ici J'ai fait quelques diagrammes pour illustrer centralisé vs distribué.

Centralisé

alt text

Distribué en médecine générale

alt text

Distribué au maximum

alt text

Vous voyez dans le diagramme il y a toujours un "référentiel centralisé", et c'est l'un des arguments préférés des fans de version centralisée: "vous êtes toujours centralisé", et non, vous ne l'êtes pas, car le référentiel "centralisé" est juste un référentiel que vous tous sont d'accord (par exemple un dépôt github officiel), mais cela peut changer à tout moment.

Maintenant, c'est le flux de travail typique pour les projets open-source (par exemple un projet avec une collaboration massive) utilisant des DVCS:

alt text

Bitbucket.org est en quelque sorte un équivalent de github pour Mercurial, sachez qu'ils ont des référentiels privés illimités avec un espace illimité, si votre équipe est inférieure à cinq, vous pouvez l'utiliser gratuitement.

La meilleure façon de vous convaincre d'utiliser un DVCS est d'essayer un DVCS, chaque développeur DVCS expérimenté qui a utilisé svn/cvs vous dira que cela en vaut la peine et qu'il ne sait pas comment il a survécu tout son temps sans lui.

[~ # ~] modifier [~ # ~] : Pour répondre à votre deuxième modification, je peux simplement répéter qu'avec un DVCS, vous avez un flux de travail différent, je Je vous conseille de ne pas chercher de raisons de ne pas l'essayer à cause de meilleures pratiques, on a l'impression que quand les gens soutiennent que OOP n'est pas nécessaire car ils peuvent contournez les modèles de conception complexes avec ce qu'ils font toujours avec le paradigme XYZ; vous pouvez quand même en bénéficier.

Essayez-le, vous verrez comment travailler dans "une branche privée" est en fait une meilleure option. L'une des raisons pour lesquelles je peux expliquer pourquoi la dernière est vraie est que vous perdez la peur de vous engager , ce qui vous permet de vous engager à tout moment si vous le souhaitez et travaillez d'une manière plus naturelle.

En ce qui concerne "la fusion de l'enfer", vous dites "à moins que nous expérimentions", je dis "même si vous expérimentez + maintenez + travaillez en même temps dans la version 2.0 remaniée ". Comme je le disais plus tôt, la fusion de l'enfer n'existe pas, car:

  • Chaque fois que vous vous engagez, vous générez une branche sans nom et chaque fois que vos modifications rencontrent les modifications d'autres personnes, une fusion naturelle se produit.
  • Étant donné que les DVCS rassemblent plus de métadonnées pour chaque validation, moins de conflits se produisent lors de la fusion ... vous pouvez même l'appeler une "fusion intelligente".
  • Lorsque vous rencontrez des conflits de fusion, voici ce que vous pouvez utiliser:

alt text

De plus, la taille du projet n'a pas d'importance, lorsque je suis passé de Subversion, je voyais déjà les avantages en travaillant seul, tout allait bien. Les changesets (pas exactement une révision, mais un ensemble spécifique de changements pour des fichiers spécifiques que vous incluez un commit, isolé de l'état de la base de code) vous permettent visualisez exactement ce que vous vouliez dire en faisant ce que vous faisiez pour un groupe spécifique de fichiers, pas la base de code entière.

En ce qui concerne le fonctionnement des changesets et l'augmentation des performances. Je vais essayer de l'illustrer avec un exemple que j'aime donner: le commutateur de projet mootools de svn illustré dans leur graphique réseau github .

Avant

alt text

Après

alt text

Ce que vous voyez, c'est que les développeurs peuvent se concentrer sur leur propre travail tout en validant, sans craindre de casser le code des autres, ils s'inquiètent de casser le code des autres après avoir poussé/tiré (DVCS: d'abord valider, puis pousser/tirer, puis mettre à jour ) mais comme la fusion est plus intelligente ici, ils ne le font souvent jamais ... même en cas de conflit de fusion (ce qui est rare), vous ne passez que 5 minutes ou moins à le résoudre.

Je vous recommande de chercher quelqu'un qui sait utiliser Mercurial/git et de lui dire de vous l'expliquer sur le terrain. En passant environ une demi-heure avec des amis sur la ligne de commande tout en utilisant Mercurial avec nos ordinateurs de bureau et nos comptes bitbucket, leur montrant comment fusionner, créant même des conflits pour eux afin de voir comment résoudre ce problème en un temps ridicule, j'ai pu montrer leur la vraie puissance d'un DVCS.

Enfin, je vous recommande d'utiliser Mercurial + bitbucket au lieu de git + github si vous travaillez avec des gens Windows. Mercurial est également un peu plus simple, mais git est plus puissant pour une gestion de référentiel plus complexe (par exemple git rebase ).

Quelques lectures supplémentaires recommandées:

333
dukeofgaming

Ce que vous dites, entre autres, c'est que si vous restez essentiellement sur une seule branche, vous n'avez pas besoin d'un contrôle de version distribué.

C'est vrai, mais n'est-ce pas une restriction inutilement forte à votre façon de travailler, et qui ne s'adapte pas bien à plusieurs emplacements dans plusieurs fuseaux horaires? Où le serveur central Subversion devrait-il être situé et tout le monde devrait-il rentrer à la maison si ce serveur est en panne pour une raison quelconque?

Les DVC sont à Subversion, ce que Bittorrent est à ftp

(techniquement, pas légalement). Peut-être que si vous y réfléchissez, vous comprendrez peut-être pourquoi c'est un si grand bond en avant?

Pour moi, notre passage à git, a immédiatement entraîné

  • Nos sauvegardes étant plus faciles à faire (juste "git remote update" et vous avez terminé)
  • Plus facile de valider de petites étapes lorsque vous travaillez sans accès au référentiel central. Vous venez de travailler et de vous synchroniser lorsque vous revenez sur le réseau hébergeant le référentiel central.
  • Des constructions Hudson plus rapides. Beaucoup plus rapide à utiliser git pull qu'à mettre à jour.

Alors, considérez pourquoi bittorrent est meilleur que ftp, et reconsidérez votre position :)

Remarque: Il a été mentionné qu'il existe des cas d'utilisation où ftp est plus rapide et que bittorrent. Cela est vrai de la même manière que le fichier de sauvegarde géré par votre éditeur préféré est plus rapide à utiliser qu'un système de contrôle de version.

59
user1249

La principale caractéristique des systèmes de contrôle de version distribués est la partie distribuée. Vous ne récupérez pas une "copie de travail" du référentiel, vous clonez une copie entière du référentiel. C'est énorme, car il offre de puissants avantages:

  • Vous pouvez profiter des avantages du contrôle de version, même lorsque vous n'avez pas accès à Internet, comme ... Celui-ci est malheureusement surutilisé et sur-typé parce que DVCS est génial --- ce n'est tout simplement pas un argument de vente solide car beaucoup d'entre nous se retrouvent à coder sans accès à Internet aussi souvent qu'il commence à pleuvoir des grenouilles.

  • La vraie raison d'avoir un référentiel local est un tueur, c'est que vous avez un contrôle total sur votre historique de validation avant qu'il ne soit poussé vers le référentiel maître.

Jamais corrigé un bug et s'est retrouvé avec quelque chose comme:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

Etc. L'histoire comme celle-ci est en désordre --- il n'y avait vraiment qu'un seul correctif, mais maintenant l'implémentation est répartie entre de nombreuses validations qui contiennent des artefacts indésirables tels que l'ajout et la suppression d'instructions de débogage. Avec un système comme SVN, l'alternative est de ne pas valider (!!!) jusqu'à ce que tout fonctionne afin de garder l'historique propre. Même alors, des erreurs passent et la loi de Murphy attend de vous brutaliser lorsque des quantités importantes de travail ne sont pas protégées par le contrôle de version.

Avoir un clone local du référentiel, que vous possédez , corrige cela car vous pouvez réécrire l'historique en roulant continuellement les "fix it" et "oops "s'engage dans le commit" bug fix ". À la fin de la journée, un commit propre est envoyé au référentiel maître qui ressemble à:

r321 Fixed annoying bug.

C'est ainsi que cela devrait être.

La possibilité de réécrire l'historique est encore plus puissante lorsqu'elle est combinée avec le modèle de branchement. Un développeur peut effectuer un travail entièrement isolé au sein d'une branche, puis lorsqu'il est temps de mettre cette branche dans le coffre, vous disposez de toutes sortes d'options intéressantes:

  • Faites une fusion simple vanille . Apporte tout dans les verrues et tout.

  • Faites un rebase . Vous permet de trier l'historique des branches, de réorganiser l'ordre des validations, de lancer les validations, de joindre les validations ensemble, de réécrire les messages de validation --- même de modifier les validations ou d'en ajouter de nouvelles! n système de contrôle de version distribué prend en charge en profondeur la révision de code.

Une fois que j'ai appris comment les référentiels locaux m'ont permis de modifier mon histoire pour le bien-être de mes collègues programmeurs et de mon avenir, j'ai raccroché SVN pour de bon. Mon client Subversion est maintenant git svn.

Permettre aux développeurs et aux gestionnaires d'exercer un contrôle éditorial sur l'historique des validations se traduit par une meilleure historique des projets et une histoire claire avec laquelle travailler aide vraiment ma productivité en tant que programmeur. Si tout ce discours sur la "réécriture de l'historique" vous fait peur, ne vous inquiétez pas car c'est à cela que servent les référentiels centraux, publics ou maîtres. L'histoire peut (et devrait!) Être réécrite au point où quelqu'un l'apporte dans une branche dans un référentiel dont d'autres personnes tirent. À ce stade, l'histoire doit être traitée comme gravée sur une tablette de pierre.

46
Sharpie

la réponse de dukofgamings est probablement aussi bonne que possible, mais je veux aborder cette question dans une direction différente.

Supposons que ce que vous dites est absolument vrai et qu'en appliquant de bonnes pratiques, vous pouvez éviter les problèmes que DVCS a été conçu pour résoudre. Est-ce à dire qu'un DVCS ne vous offrirait aucun avantage? Personnes puant à suivre les meilleures pratiques. Les gens vont pour gâcher. Alors, pourquoi voudriez-vous éviter le logiciel conçu pour résoudre un ensemble de problèmes, en choisissant plutôt de compter sur les gens pour faire quelque chose que vous pouvez prévoir à l'avance qu'ils ne feront pas?

18
philosodad

Oui, cela fait mal quand vous devez fusionner de gros commits dans Subversion. Mais c'est aussi une excellente expérience d'apprentissage, vous permettant de tout faire pour éviter de fusionner les conflits. En d'autres termes, vous apprenez à vérifiez souvent . L'intégration précoce est une très bonne chose pour tout projet colocalisé. Tant que tout le monde le fait, l'utilisation de Subversion ne devrait pas être un gros problème.

Git, par exemple, était conç pour le travail distribué et encourage les gens à travailler sur leurs propres projets et à créer leurs propres fourches pour une fusion (éventuelle) plus tard. Il n'était pas spécialement conçu pour une intégration continue dans une "petite équipe hautement collaborative", ce que demande le PO. C'est plutôt le contraire, pensez-y. Vous n'aurez aucune utilité pour ses fonctionnalités distribuées de fantaisie si tout ce que vous faites est assis dans la même pièce en travaillant ensemble sur le même code.

Donc, pour une équipe co-localisée utilisant CI, je ne pense vraiment pas que cela ait beaucoup d'importance si vous utilisez un système distribué ou non. Cela se résume à une question de goût et d'expérience.

9
Martin Wickman

Parce que vous devez constamment contester vos propres connaissances. Vous aimez Subversion, et je peux comprendre parce que je l'ai utilisé pendant de nombreuses années et que j'en étais très content, mais cela ne veut pas dire que c'est toujours l'outil qui vous conviendrait le mieux.

Je crois que lorsque j'ai commencé à l'utiliser, c'était le meilleur choix à l'époque. Mais d'autres outils apparaissent au fil du temps, et maintenant je préfère git, même pour mes propres projets de temps libre.

Et Subversion a quelques défauts. Par exemple. si vous renommez un répertoire sur le disque, il n'est pas renommé dans le référentiel. Le déplacement de fichier n'est pas pris en charge, ce qui rend un déplacement de fichier une opération de copie/suppression, ce qui rend difficile la fusion des modifications lorsque les fichiers ont été déplacés/renommés. Et le suivi des fusions n'est pas vraiment intégré au système, mais plutôt implémenté sous la forme d'une solution de contournement.

Git résout ces problèmes (notamment en détectant automatiquement si un fichier a été déplacé, vous n'avez même pas besoin de lui dire que c'est un fait).

D'un autre côté, git ne vous permet pas de créer des branches sur des niveaux de répertoires individuels comme Subversion le fait.

Donc, ma réponse est que vous devriez rechercher des alternatives, voir si elles correspondent mieux à vos besoins que ce que vous connaissez, puis décider.

8
Pete

En ce qui concerne les performances, Git ou tout autre DVCS a un gros avantage sur SVN lorsque vous devez passer d'une branche à une autre ou passer d'une révision à une autre. Comme tout est stocké localement, les choses sont beaucoup plus rapides que pour SVN.

Cela seul pourrait me faire basculer!

7
Xavier Nodet

Au lieu de cela, accrocher à l'idée que "en appliquant les meilleures pratiques, vous n'avez pas besoin d'un DVCS", pourquoi ne pas considérer que le flux de travail SVN est un flux de travail, avec un ensemble de meilleures pratiques, et que le flux de travail GIT/Hg est un flux de travail différent, avec un ensemble différent de meilleures pratiques.

git bisect (et toutes ses implications sur votre référentiel principal)

Dans Git, un principe très important est que vous pouvez trouver des bogues en utilisant git bisect. Pour ce faire, vous prenez la dernière version que vous avez exécutée qui était connue pour fonctionner, et la première version que vous avez exécutée qui était connue pour échouer, et vous effectuez (avec l'aide de Git) une recherche binaire pour déterminer quel commit a causé le bogue. Pour ce faire, l'intégralité de votre historique de révision doit être relativement exempte d'autres bogues pouvant interférer avec votre recherche de bogues (croyez-le ou non, cela fonctionne plutôt bien en pratique, et les développeurs du noyau Linux le font tout le temps).

Atteindre git bisect capacité, vous développez une nouvelle fonctionnalité seule branche de fonctionnalité , la rebase et nettoyez l'historique (vous n'avez donc aucun -des révisions de travail dans votre historique - juste un tas de changements qui vous permettent de résoudre le problème à mi-chemin), puis lorsque la fonctionnalité est terminée, vous la fusionnez dans la branche principale avec l'historique de travail.

De plus, pour que cela fonctionne, vous devez avoir une discipline sur la version de la branche principale à partir de laquelle vous démarrez votre branche de fonctionnalité. Vous ne pouvez pas simplement partir de l'état actuel de la branche master car cela peut avoir des bogues non liés - donc le conseil dans la communauté du noyau est de commencer à travailler à partir de la dernière version stable du noyau (pour les grandes fonctionnalités ), ou pour commencer le travail à partir de la dernière version candidate balisée.

Vous pouvez également sauvegarder votre progression intermédiaire en poussant la branche de fonctionnalité vers un serveur dans l'intervalle, et vous pouvez pousser la branche de fonctionnalité vers un serveur pour la partager avec quelqu'un d'autre et obtenir des commentaires, avant que la fonctionnalité ne soit terminée, avant de devoir transformez le code en une fonctionnalité permanente de la base de code que tout le monde * dans votre projet doit gérer.

La page de manuel gitworkflows est une bonne introduction aux workflows pour lesquels Git est conçu. Aussi Pourquoi Git est meilleur que X discute des workflows git.

Grands projets distribués

Pourquoi avons-nous besoin de lieutenants dans une équipe hautement collaboratrice avec de bonnes pratiques et de bonnes habitudes de conception?

Parce que dans des projets comme Linux, il y a tellement de personnes impliquées qui sont si géographiquement réparties qu'il est difficile de collaborer aussi fortement qu'une petite équipe qui partage une salle de conférence. (Je soupçonne que pour développer un grand produit comme Microsoft Windows, même si les gens sont tous situés dans le même bâtiment, l'équipe est tout simplement trop grande pour maintenir le niveau de collaboration qui permet à un VCS centralisé de fonctionner sans lieutanants.)

3
Ken Bloom

Pourquoi ne pas les utiliser en tandem? Sur mon projet actuel, nous sommes obligés d'utiliser CVS. Cependant, nous conservons également des référentiels git locaux afin de faire du développement de fonctionnalités. C'est le meilleur des deux mondes, car vous pouvez essayer différentes solutions et conserver des versions de ce sur quoi vous travaillez, sur votre propre machine. Cela vous permet de revenir aux versions précédentes de votre fonctionnalité ou d'essayer plusieurs approches sans rencontrer de problèmes lorsque vous gâchez votre code. Avoir un référentiel central vous donne alors les avantages d'avoir un référentiel centralisé.

2
Vadim

Je n'ai aucune expérience personnelle avec DVCS, mais d'après ce que je comprends des réponses ici et de certains documents liés, la différence la plus fondamentale entre DVCS et CVCS est le modèle de travail utilisé.

DVCS

Le modèle de travail de DVCS est que vous faites développement isolé. Vous développez votre nouvelle fonctionnalité/correction de bogue indépendamment de toutes les autres modifications jusqu'au moment où vous décidez de la diffuser au reste de l'équipe. Jusque-là, vous pouvez faire ce que vous voulez, car personne d'autre ne s'en souciera.

CVCS

Le modèle de travail de CVCS (en particulier Subversion) est que vous faites développement collaboratif. Vous développez votre nouvelle fonctionnalité/correction de bug en collaboration directe avec tous les autres membres de l'équipe et toutes les modifications sont immédiatement accessibles à tous.

Autres différences

D'autres différences entre svn et git/hg, telles que les révisions par rapport aux changesets sont fortuites. Il est très possible de créer un DVCS basé sur des révisions (comme Subversion les a) ou un CVCS basé sur des changesets (comme Git/Mercurial en ont).

Je ne recommanderai aucun outil en particulier, car cela dépend principalement du modèle de travail avec lequel vous (et votre équipe) êtes le plus à l'aise.
Personnellement, je n'ai aucun problème à travailler avec un CVCS.

  • Je n'ai aucune crainte à enregistrer des choses, car je n'ai aucun problème à les mettre dans un état incomplet, mais compilable.
  • Quand j'ai connu l'enfer de fusion, c'était dans des situations où cela se serait produit à la fois dans svn et git/hg. Par exemple, la V2 de certains logiciels était maintenue par une autre équipe, utilisant un VCS différent, pendant que nous développions la V3. Parfois, des corrections de bogues devaient être importées du V2 VCS ​​vers le V3 VCS, ce qui signifiait essentiellement faire un très grand enregistrement sur le V3 VCS (avec tous les correctifs de bogues dans un seul ensemble de modifications). Je sais que ce n'était pas idéal, mais c'était une décision de gestion d'utiliser différents systèmes VCS.
1
Bart van Ingen Schenau