Je suis un mordu de Subversion. Pourquoi devrais-je envisager ou non Mercurial, Git ou tout autre DVCS?


300

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 de Martin Fowler très utiles.

Mercurial et d’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

Cela ne nous concerne pas, car je pratique l'intégration continue et que travailler seul dans une agence privée n'est pas une option, à moins que nous ne fassions des expériences. Nous utilisons une branche pour chaque version majeure, dans laquelle nous corrigeons les bogues fusionnés à partir du coffre.

Mercurial vous permet d'avoir des lieutenants

Je comprends que cela peut être utile pour des projets très volumineux tels que Linux, mais je ne vois pas l'intérêt des petites équipes très collaboratives (5 à 7 personnes).

Mercurial est plus rapide, prend moins d’espace disque et une copie locale complète permet des opérations plus rapides de journalisation et de diff.

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 de SVN. Surtout en ce qui concerne le concept de changesets et l' amélioration de la performance globale que vous avez mesurée.

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

MISE À JOUR (12 juin) : J'ai embrassé Mercurial et cela m'a plu. 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. Je me sentais tellement mal. C'était tellement bon. Ne veux pas dire que je suis amoureux ce soir .

FINAL UPDATE (29 juillet) : J’ai eu le privilège de relire le prochain livre d’ Eric Sink intitulé Version Control by Example . Il a fini de me convaincre. Je vais aller pour Mercurial.


8
Je suis aussi très intéressé par ça. Subversion correspond à la façon dont on m'a appris à penser au contrôle de version (venant de CVS, etc.). Néanmoins, bien que j'ai dû utiliser Mercurial et Git pour essayer quelques corrections de bugs pour les projets open source, je n'ai pas encore été converti.
Berin Loritsch le

29
+1 pour la question. De nos jours, il est devenu culte les cargaisons, car la distribution est simplement meilleure, plus rapide, plus simple, plus naturelle, sans problème et à 90% plus brillante que centralisée. Sauf que ce n'est pas nécessairement le cas. Ce sont des outils différents , et chacun peut présenter des avantages dans certains contextes et des inconvénients dans d'autres.
Joonas Pulakka

17
@Sharpie: Ayant utilisé à la fois svn, gitet hgdepuis des années, je suis assez bien conscients de leurs avantages et inconvénients. Bien que ce gitsoit certainement le plus puissant de ceux-ci, il est important de reconnaître que plus puissant ne veut pas dire automatiquement meilleur . Emacs est certainement plus puissant que n’importe quel éditeur de texte javascript fonctionnant dans un navigateur Web, mais étrangement, j’écris ce commentaire dans un éditeur de texte javascript maintenant! La simplicité , même la bêtise, a de la valeur dans de nombreux contextes. L’utilisation centralisée svnet git-svnlocale offre le meilleur des deux mondes.
Joonas Pulakka

9
@Sharpie: C'est bien pour toi que ça te plaise. Mais les avantages d'un homme sont les inconvénients d'un autre. Certaines personnes considèrent que la clarté d'un référentiel centralisé unique avec un seul tronc canonique est extrêmement précieuse. Voici une présentation sur la façon dont Google conserve le code source de tous ses projets, plus de 2 000, dans un seul tronc de code contenant des centaines de millions de lignes de code, avec plus de 5 000 développeurs accédant au même référentiel. Préférez-vous préférer 5000 serveurs et l’historique de 2000 projets sur le bureau de tous? -)
Joonas Pulakka

21
-1 pour la référence Katy Perry. ;)
Amadiere

Réponses:


331

Note: Voir "EDITER" pour la réponse à la question actuelle


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

Une autre recommandation, l’exposé de Linus Torvalds sur Git: http://www.youtube.com/watch?v=4XpnKHJAok8 . Cet autre pourrait également répondre à la plupart de vos questions, ce qui est très divertissant.

BTW, quelque chose que je trouve assez drôle: même Brian Fitzpatrick et Ben Collins-Sussman, deux des créateurs originaux de Subversion ont déclaré dans une conversation Google "désolé pour cela" en se référant au fait que la subversion soit inférieure au mercurial (et aux DVCS en général).

Maintenant, IMO et, en général, la dynamique d'équipe se développent plus naturellement avec n'importe quel DVCS, et l'un des avantages remarquables est que vous pouvez vous engager hors ligne, car cela implique les éléments suivants:

  • Vous ne dépendez pas d'un serveur et d'une connexion, ce qui signifie des temps plus rapides.
  • Ne pas être esclave de lieux 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. Cela signifie que n'importe qui peut devenir le serveur .
  • Vous pouvez vous engager de manière compulsive si vous en avez besoin sans déranger le code des autres . Les commits sont locaux. Vous ne vous mettez pas les pieds sur les pieds quand vous vous engagez. Vous ne détruisez pas les constructions ou les environnements des autres en vous engageant.
  • Les personnes sans "accès de validation" peuvent valider (car s'engager dans un DVCS n'implique pas le téléchargement de code), en 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 puisqu'un DVCS rend cela essentiel ... dans la subversion, ce que vous avez à la place sont des courses engagées, 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 branches sans affecter les autres (tout en pouvant les partager si nécessaire).

A 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 extraites. 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é?, Gardez simplement vos tests dans le cadre de votre culture / politique.
  • Mercurial est plus rapide dans certains cas, git plus rapide dans d’autres. Pas vraiment aux DVCS en général, mais à leurs implémentations particulières, autant que je sache.
  • Tout le monde aura toujours le projet complet, pas seulement vous. La chose distribuée a à voir avec ce que vous pouvez valider / mettre à jour localement, partager / prendre de 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 tout le versioning.

J'apportais de la documentation au projet Joomla pour aider à prêcher une migration vers les DVCS, et ici, j'ai réalisé quelques diagrammes pour illustrer la centralisation par rapport à la distribution.

Centralisé

texte alternatif

Distribué en pratique générale

texte alternatif

Distribué au maximum

texte alternatif

Vous voyez dans le diagramme qu'il y a toujours un "référentiel centralisé", et il s'agit de l'un des arguments préférés des fans du contrôle de version centralisée: "vous êtes toujours en cours de centralisation", et non, vous ne l'êtes pas, car le référentiel "centralisé" n'est qu'un référentiel tous sont d’accord (p. ex. un dépôt officiel de github), mais cela peut changer à tout moment.

Il s’agit maintenant du flux de travail typique des projets Open Source (par exemple, un projet avec une collaboration massive) utilisant des DVCS:

texte alternatif

Bitbucket.org est un peu l’équivalent de github pour mercurial. Sachez qu’ils ont un référentiel privé illimité avec un espace illimité. Si votre équipe est inférieure à cinq personnes, 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.


EDIT : Pour répondre à votre deuxième édition, je peux simplement rappeler qu’avec un DVCS, votre flux de travail est différent, je vous déconseille de chercher des raisons de ne pas l’essayer à cause des meilleures pratiques , c’est comme lorsque les gens disent nécessaires car ils peuvent contourner des modèles de conception complexes avec ce qu’ils font toujours avec le paradigme XYZ; vous pouvez bénéficier de toute façon.

Essayez, vous verrez que travailler dans "une branche privée" est en fait une meilleure option. 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 et de travailler de manière plus naturelle.

En ce qui concerne "la fusion de l'enfer", vous dites "à moins que nous n'essayions", je dis "même si vous expérimentez + maintaing + en même temps que la version révisée v2.0 ". Comme je le disais plus tôt, la fusion de l'enfer n'existe pas, car:

  • Chaque fois que vous validez une branche non nommée et que vos modifications rencontrent les modifications d'autres personnes, une fusion naturelle se produit.
  • Étant donné que les DVCS collectent davantage de métadonnées pour chaque validation, moins de conflits se produisent lors de la fusion ... vous pouvez même appeler cela une "fusion intelligente".
  • Lorsque vous vous heurtez à des conflits de fusion, voici ce que vous pouvez utiliser:

texte alternatif

De plus, la taille du projet n'a pas d'importance. Lorsque je passais de la subversion, je voyais déjà les avantages tout en travaillant seul, tout se sentait bien. Les changesets (pas exactement une révision, mais un ensemble spécifique de modifications pour des fichiers spécifiques pour lesquels vous incluez un commit, isolé de l'état de la base de code) vous permettent de visualiser exactement ce que vous voulez dire en faisant ce que vous faisiez avec un groupe de fichiers spécifique. pas toute la base de code.

Concernant le fonctionnement des changesets et l’amélioration 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 graphe de réseau github .

Avant

texte alternatif

Après

texte alternatif

Ce que vous constatez, c’est que les développeurs sont capables de se concentrer sur leur propre travail tout en s’engageant. ) 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 sache utiliser mercurial / git et de lui dire de vous l'expliquer. En passant environ une demi-heure avec des amis à la ligne de commande tout en utilisant mercurial avec nos ordinateurs de bureau et nos comptes bitbucket, leur montrant comment fusionner, et même créant des conflits pour eux, afin de voir comment les résoudre dans des délais aussi ridicules que possible. eux le vrai pouvoir d'un DVCS.

Enfin, je vous recommanderais d’utiliser mercurial + bitbucket au lieu de git + github si vous travaillez avec des utilisateurs Windows. Mercurial est aussi 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:


18
Excellente réponse, mais juste une question pour ceux d’entre nous qui sommes dans le même bateau que OP: pouvez-vous expliquer comment la fusion de l’enfer n’existe pas? Un intégrateur ou un contributeur n'a-t-il pas besoin de passer par les mêmes actions lorsque leur fourchette est devenue obsolète?
Nicole

17
Bonne réponse. Juste une note de côté: bien que Spolsky puisse avoir quelques points intéressants, sachez qu'il essaie également de vendre un produit en utilisant ces points comme matériel de vente, ce qui les rend un peu biaisés.
Martin Wickman

5
J'ai lu cette page de rééducation et je ne l'ai pas trouvée pertinente pour plusieurs raisons. Je vais modifier ma question avec mon point de vue personnel sur le sujet.

15
Cela vaut également la peine de souligner que Git peut agir en tant que client Subversion, ce qui signifie que vous n'avez pas besoin de convertir tout le monde à Git en même temps. quelques membres de l'équipe peuvent simplement utiliser Git s'ils le souhaitent et leur flux de travail individuel s'améliore (notamment parce que la fusion est beaucoup plus facile).
Greyfade

6
@Pierre, les DVCS s'occupent de la fusion des modifications logicielles des programmeurs individuels, mais pas de la compilation du logiciel ni de la réussite des tests unitaires existants. Vous avez toujours besoin d'un autre logiciel pour le faire chaque fois que le code source change et le meilleur choix que nous avons aujourd'hui est d'utiliser un moteur de CI (et de le faire correctement)

59

Vous dites notamment que si vous restez essentiellement dans une seule branche, vous n’avez pas besoin de contrôle de version distribué.

C’est vrai, mais n’est-ce pas une restriction inutilement forte de votre façon de travailler, et une restriction qui ne s’adapte pas bien à plusieurs endroits dans plusieurs fuseaux horaires? Où le serveur de sous-version central doit-il être situé et tout le monde doit-il rentrer chez lui si ce serveur est en panne pour une raison quelconque?

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

(techniquement, pas légalement). Si vous y réfléchissez bien, vous comprendrez peut-être pourquoi il s'agit d'un si grand bond en avant?

Pour moi, notre passage à git, a immédiatement abouti à

  • Nos sauvegardes étant plus faciles à faire (juste "git remote update" et vous avez terminé)
  • Plus facile à commettre de petites étapes lorsque vous travaillez sans accès au référentiel central. Vous venez de travailler et de synchroniser lorsque vous revenez sur le réseau hébergeant le référentiel central.
  • Hudson construit plus rapidement. Beaucoup, beaucoup plus rapide à utiliser que git pull que la mise à 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 plus facile que bittorrent. Cela est vrai de la même manière que le fichier de sauvegarde géré par votre éditeur favori est plus rapide à utiliser qu'un système de contrôle de version.


J'ai presque décidé de l'essayer avec un vrai projet.

Bonne idée. N'oubliez pas d'y aller avec la mentalité de "J'aime vraiment ça!" au lieu de "je ne veux pas faire ça!". Il y a beaucoup à apprendre. Si vous choisissez git, github dispose de nombreuses aides en ligne. Si vous choisissez hg, Joel a écrit du bon matériel en ligne. Si vous choisissez bzr, Canonical a probablement beaucoup de bons documents en ligne. Autres?

3
Hmm qui suppose que vous pensez que bittorrent est meilleur que FTP ...
Murph

2
@Murph, moi aussi, et Blizzard aussi (avec qui, je pense, nous entendons, sait comment gérer une synchronisation en ligne massive?). wowwiki.com/Blizzard_Downloader

2
@Murph, vous démarrez un serveur torrent sur le serveur et un client torrent sur le client. Pas dur. Il devrait immédiatement vous indiquer que seuls les fichiers modifiés doivent être mis à jour. De plus, avez-vous envisagé ce que rsync au lieu de ftp pourrait vous acheter pour des mises à jour incrémentielles?

46

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 complète du référentiel. C'est énorme, car il fournit des avantages puissants:

  • Vous pouvez profiter des avantages du contrôle de version, même lorsque vous n’avez pas accès à Internet tel que ... Celui-ci est malheureusement surutilisé et surexprimé comme une raison pour laquelle DVCS est génial - ce n’est tout simplement pas un argument de vente fort nous nous trouvons en train de coder sans accès à Internet à peu près aussi souvent qu'il commence à pleuvoir des grenouilles.

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

Jamais corrigé un bug et fini 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. Une telle histoire est désordonnée - il n'y avait en réalité qu'un correctif, mais maintenant, l'implémentation est répartie entre de nombreux commits contenant 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 s’engager (!!!) tant que tout n’est pas en marche pour que l’historique reste vierge. Même dans ce cas, des erreurs se glissent et la loi de Murphy attend de vous brutaliser lorsque des travaux importants ne sont pas protégés 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 continuant à rouler les corrections "it it" et "oops" dans le commit "correctif de bogue". À 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 comme ça que ça devrait être.

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

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

  • Faites un rebase . Vous permet de trier l'historique de la branche, de réorganiser l'ordre des validations, de supprimer les validations, de rejoindre les validations ensemble, de réécrire les messages de validation, voire même de les modifier ou d'en ajouter de nouveaux! Un système de contrôle de version distribué prend en charge de manière approfondie la révision du code.

Une fois que j'ai compris comment les référentiels locaux me permettaient de modifier mon histoire pour préserver la santé mentale 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 permet de créer un meilleur historique des projets et d’avoir un historique sans faille qui contribue réellement à ma productivité en tant que programmeur. Si toutes ces discussions sur la "réécriture de l'historique" vous effraient, ne vous inquiétez pas, c'est à quoi servent les référentiels centraux, publics ou principaux. L'histoire peut (et devrait!) Être réécrite jusqu'à ce que quelqu'un la ramène dans une branche d'un référentiel que d'autres personnes extraient. À ce stade, l'histoire doit être traitée comme si elle était gravée sur une tablette de pierre.


6
Réécrire l’histoire: n’est-ce qu’un truc pour Git? Ou est-ce facile aussi dans Mercurial? (Si c'est le cas, j'ai vraiment besoin de commencer à le faire.)
Paul D. Waite

3
Vous devez être conscient de la discipline du noyau Linux, à savoir: ne jamais rebaser (ou réécrire l'historique) une branche que vous avez publiée publiquement. Si vous avez des branches qui sont publiques pour une utilisation à court terme (pour fusionner en branches jettées fréquemment comme linux-next, ou pour que quelqu'un vérifie et jette ensuite leurs copies locales), vous pouvez alors rebaser ces branches - mais votre les autres utilisateurs doivent savoir que la convention pour cette branche est qu'elle peut être rebasée et ne devrait pas être fusionnée dans les branches à long terme des autres peuples.
Ken Bloom

4
vous pourriez très bien avoir un accès Internet sans avoir un accès complet au réseau interne. Cela m’arrive souvent lorsque je voyage.

5
Ne pas avoir besoin d'un accès à Internet est un gros problème, car c'est de là que vient la vitesse de DVCS. Dès que vous devez envoyer des paquets sur un réseau, vous ralentissez le processus d'un ordre de grandeur, quelle que soit la qualité de votre connexion.
Adam Lassek

6
@ Paul, je crois comprendre que dans Mercurial, cela peut être fait, mais ce n'est pas la fonctionnalité ou la philosophie de base.
Benjol

18

La réponse de dukofgamings est probablement aussi bonne que possible, mais je veux aborder la question sous un angle différent.

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


2
En fait, je proposerais cet argument contre DCVS. Mon entreprise est récemment passée de CVS à Mercurial. Les gens effacent les changements des autres peuples lors des fusions de manière plus fréquente lorsqu'ils sont sur CVS.
Juozas Kontvainis

@JuozasKontvainis: Je ne connais pas très bien mercurial, mais avec git, vous pouvez interdire les envois comportant des fusions dont HEAD n'est pas parent, ce qui empêche les utilisateurs de demander des modifications sans les modifications les plus récentes de master. Je suis sûr qu'il y a quelque chose de similaire dans Mercurial.
naught101

@ naught101: en fait, mon entreprise a activé ce paramètre. Qu'est-ce qui se passe est que le programmeur valide ses modifications localement, puis essaie de pousser. Il reçoit une réponse du serveur qu'il doit fusionner avant de pouvoir envoyer des messages. Il obtient les mises à jour du serveur et tente de réaliser une validation de fusion. À ce stade, je ne sais pas exactement comment ces personnes ont effectué une validation de fusion, mais à plusieurs reprises, cette validation a essentiellement effacé les modifications apportées par le serveur.
Juozas Kontvainis

1
Cela ressemble à des personnes qui ont retiré les modifications, puis les ont supprimées du serveur lors de la fusion (ce qui est possible). Bien entendu, le jeu de modifications du serveur est toujours présent. Vous pouvez donc réinitialiser le référentiel à l'état dans lequel il se trouvait avant ses modifications.
philosodad

1
en fait, cela ressemble à ceci: randyfay.com/content/avoiding-git-disasters-gory-story Un article non critique sur ce qui peut mal tourner avec un dépôt git si vous ne savez pas ce que vous faites.
gbjbaanb

9

Oui, cela fait mal lorsque vous devez fusionner de grands commits dans la subversion. Mais c’est aussi une excellente expérience d’apprentissage, qui vous oblige à faire tout ce qui est possible pour éviter la fusion des conflits. En d'autres termes, vous apprenez à vous enregistrer souvent . Une intégration précoce est une très bonne chose pour tout projet co-localisé. Tant que tout le monde le fait, la subversion ne devrait pas poser trop de problèmes.

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

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


2
Git a été conçu pour le travail distribué à travers le monde et encourage les gens à travailler sur leurs propres projets et à créer leurs propres forks. Il n’était pas spécifiquement conçu pour une intégration continue au sein de "petites équipes hautement collaboratives", comme le demande le PO.
Martin Wickman

4
Devinez quoi, vous obtenez des conflits plus petits / plus faciles à résoudre. Mais si deux personnes changent les mêmes parties du code, vous rencontrez un problème de planification dans votre équipe, problème qui ne peut être résolu par aucun VCS. Distribué ou non.
Martin Wickman

4
Le PO fait partie d'une équipe co-localisée utilisant l'EC. Cela signifie qu'ils effectuent souvent de nombreux petits enregistrements (plusieurs fois par jour). Compte tenu de cela, je ne vois aucune raison pour laquelle utiliser un DVD devrait conférer un avantage particulier, ni aucune raison pour laquelle des fusions énormes devraient se produire et, partant, aucune fusion d'enfer. Je ne recommanderais pas svn svn pour une équipe distribuée, mais ce n'est pas le cas ici.
Martin Wickman

2
@MartinWickman - Mercurial a été conçu pour engager, créer des branches et fusionner rapidement et à moindre coût. Cela semble parfait pour l'intégration continue. Personnellement, je pense qu'avoir la possibilité pour Alice de créer des branches pour ses modifications et de suggérer à Bob de les extraire et de fusionner ses modifications sur cette branche pour rechercher d'éventuels problèmes, le tout sans toucher au serveur central ni transférer les modifications n'importe où, semble être un excellent moyen. pour que les petites équipes hautement collaboratives travaillent.
philosodad

2
Mon 0,02 $. J'ai déjà utilisé Subversion, Mercurial et Git pour divers projets. Subversion semble vraiment être le meilleur choix pour un groupe très étroitement intégré faisant de l'intégration continue. Mercurial convient mieux aux groupes qui ne peuvent créer qu'une journée par jour avec beaucoup plus de modifications de code à chaque fois (ce qui créerait des problèmes de fusion dans SVN). Git semble être la voie à suivre pour les personnes dont les équipes peuvent passer des jours / des semaines sans rassembler le code pour créer un build.
Brian Knoblauch

8

Parce que vous devriez continuellement contester vos propres connaissances. Vous aimez la subversion, et je peux comprendre car je l’utilise depuis de nombreuses années et j’en suis très heureux, 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 au fil du temps, d’autres outils sont apparus et je préfère maintenant git, même pour mes projets personnels.

Et la subversion a quelques défauts. Par exemple, si vous renommez un répertoire sur un disque, celui-ci n'est pas renommé dans le référentiel. Le déplacement de fichier n'est pas pris en charge, ce qui oblige un fichier à déplacer une opération de copie / suppression, rendant 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 implémenté sous forme de solution de contournement.

Git résout ces problèmes (y compris 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'autre part, git ne vous permet pas de vous connecter à des niveaux de répertoires individuels, contrairement à Subversion.

Donc, ma réponse est que vous devriez rechercher des solutions de rechange, voir si cela répond mieux à vos besoins que ce que vous connaissez, puis décider.


Très vrai, les alternatives d'expérimentation devraient être automatiques.

git utilise une certaine heuristique pour déterminer si un fichier a été déplacé, qu'il soit bon mais pas parfait.
Gbjbaanb

Je suis d’accord avec cela, même si vous détestez le nouvel outil que ces maudits enfants utilisent, je pense qu’il est important de vous forcer au moins à essayer de nouvelles choses, surtout si elles font des vagues énormes.
Tjaart

7

En ce qui concerne les performances, Git ou tout autre DVCS présente un avantage considérable par rapport à SVN lorsque vous devez passer d’une branche à l’autre ou passer d’une révision à l’autre. Comme tout est stocké localement, les choses sont beaucoup plus rapides que pour SVN.

Cela seul pourrait me faire basculer!


D'accord, Git Checkout est extrêmement rapide.

+1 pour avoir signalé cela, passer d'une branche à une autre est assez rapide
dukeofgaming

3

Si vous vous en tenez à l'idée qu '"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 bugs en utilisant git bisect. Pour ce faire, vous prenez la dernière version que vous avez exécutée qui fonctionnait normalement et la première version que vous avez exécutée dont l'échec était connu, et vous effectuez (avec l'aide de Git) une recherche binaire pour déterminer quelle validation a été causée par le bogue. Pour ce faire, votre historique de révision doit être relativement exempt d’autres bogues susceptibles d’interférer avec votre recherche de bogues (croyez-le ou non, cela fonctionne plutôt bien dans la pratique, et les développeurs du noyau Linux le font tout le temps).

Pour atteindre cette git bisectcapacité, vous développez une nouvelle fonctionnalité sur sa propre branche de fonctionnalités , vous la rebasonnez et nettoyez l’historique (de sorte que vous ne disposiez pas de révisions inopérantes dans votre historique, mais uniquement de nombreuses modifications que vous apportez à part entière. résoudre le problème), puis lorsque la fonctionnalité est terminée, vous le fusionnez dans la branche principale avec l’historique de travail.

En outre, pour que cela fonctionne, vous devez définir avec précision la version de la branche principale à partir de laquelle vous démarrez votre branche. Vous ne pouvez pas simplement partir de l’état actuel de la masterbranche car il peut y avoir des bogues non liés. Le conseil de la communauté du noyau est donc de commencer à travailler à partir de la dernière version stable du noyau (pour les grandes fonctionnalités) ou de commencer à travailler. de la dernière version candidate étiquetée.

Vous pouvez également sauvegarder votre progression intermédiaire en envoyant la branche de fonctionnalités à un serveur entre-temps. Vous pouvez également la transmettre à un serveur pour la partager avec une autre personne et obtenir des commentaires avant la fin de la fonctionnalité, avant de devoir transformez le code en une fonctionnalité permanente de la base de code que tout le monde * de votre projet doit traiter.

La page de manuel gitworkflows constitue une bonne introduction aux flux de travail pour lesquels Git est conçu. De plus, pourquoi Git est meilleur que X traite des workflows git.

Grands projets distribués

Pourquoi avons-nous besoin de lieutenants dans une équipe hautement collaborative dotée 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 réparties géographiquement, qu'il est difficile d'être aussi collaborateur qu'une petite équipe partageant une salle de conférence. (Je suppose que pour le développement d'un produit volumineux tel que Microsoft Windows, même si tous les utilisateurs se trouvent dans le même bâtiment, l'équipe est tout simplement trop nombreuse pour maintenir le niveau de collaboration qui permet à un VCS centralisé de fonctionner sans lieutanants.)


Je ne comprends pas votre premier point. Avez-vous des références? En ce qui concerne le dernier, je diviserais le projet en composants distincts. Je n'ai jamais travaillé sur un projet d'une telle envergure, le nombre maximum de développeurs que j'ai sur le même projet est de deux douzaines.

@Pierre. Il est certainement raisonnable de diviser le projet en composants distincts. Étant donné que Linux est un noyau monolithique, cela signifie (essentiellement) que tous les pilotes de périphérique doivent être développés dans le même référentiel, même s’il s’agit essentiellement d’un projet distinct. Dans le même temps, ils souhaitent que leurs architectes plus expérimentés puissent faire preuve de souplesse pour apporter des modifications de grande envergure qui touchent tous ces facteurs. Il sera donc difficile de les répartir dans différents référentiels. Donc, les git (et les lieutenants) leur conviennent bien pour gérer ces différentes préoccupations.
Ken Bloom

Vous voudrez peut-être aussi lire ce que Martin Fowler a à dire sur les workflows SVN versus Git et Mercurial. martinfowler.com/bliki/VersionControlTools.html
Ken Bloom

2
Je fais des bisections sur SVN régulièrement pour trouver des bugs. La seule différence avec Git est que tout n'est pas automatique. Mais cela ne suffirait pas à nous permettre de basculer.
Xavier Nodet

1
La pertinence de git bisect pour les petites équipes est presque nulle. Je le comprends pour le noyau où des centaines de changements de différentes personnes sont fusionnés en une fois et cassent des choses, mais quand vous avez une équipe de 5 personnes, vous pouvez généralement éliminer presque tous les correctifs de coupables potentiels sauf deux ou trois avec un rapide coup d'œil au bûche.
Blucz

2

Pourquoi ne pas les utiliser en tandem? Sur mon projet actuel, nous sommes obligés d'utiliser CVS. Cependant, nous conservons également les référentiels git locaux afin de développer les fonctionnalités. C’est le meilleur des deux mondes, car vous pouvez essayer diverses solutions tout en conservant les versions de vos travaux sur votre propre ordinateur. Cela vous permet de revenir aux versions précédentes de votre fonctionnalité ou d'essayer plusieurs approches sans vous poser 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é.


Mais vous pouvez simplement configurer un référentiel central avec un DVCS (et vous pouvez contrôler les autorisations aussi étroitement qu'avec un CVCS. Alors, quels sont les avantages?
naught101

C'est vrai, mais les référentiels git centraux peuvent être difficiles à configurer si vous êtes dans un environnement Windows. Je suppose que c'est à peu près le seul auquel je puisse penser. Nous étions obligés d'utiliser CVS au niveau de l'entreprise, nous n'avions donc pas vraiment le choix.
Vadim

1

Je n'ai pas d'expérience personnelle avec DVCS, mais d'après ce que je tire 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 effectuez un développement isolé . Vous développez votre nouvelle fonctionnalité / correction de bug indépendamment de toutes les autres modifications jusqu'au moment où vous décidez de la diffuser au reste de l'équipe. Jusqu'à ce moment-là, vous pouvez effectuer les enregistrements de votre choix, car personne d'autre ne s'en préoccupera.

CVCS

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

Autres différences

Les autres différences entre svnet git/ hg, telles que les révisions par rapport aux ensembles de modifications, sont accessoires. 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 les 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 de vérifier les données, car je n'ai aucun problème à en faire un état incomplet, mais compilable.
  • Lorsque j’ai connu Merge-Hell, c’était dans des situations où cela s’était produit à la fois svnet git/ hg. Par exemple, la version 2 de certains logiciels était maintenue par une équipe différente, utilisant un autre VCS, pendant que nous développions la version 3. De temps en temps, des corrections de bogues devaient être importées du VCS V2 vers le VCS V3, ce qui signifiait essentiellement une très grande vérification sur le VCS V3 (avec tous les correctifs dans un seul ensemble de modifications). Je sais que ce n’était pas idéal, mais la direction a décidé d’utiliser différents systèmes VCS.

Je ne pense pas que le développement isolé soit en réalité le modèle de travail de DVCS. Une caractéristique importante d'un système DVCS est que les autres membres de l'équipe peuvent extraire vos modifications locales ou cloner votre référentiel local. Vous vous engagez quand vous le souhaitez, vos modifications sont toujours disponibles et vos bogues ne peuvent pas causer de ravages en masse.
philosodad

@philosodad: Si d'autres personnes extraient du code de mon référentiel sans en connaître l'état, cela peut quand même causer des dégâts. La seule différence réside dans la responsabilité de qui. Et mon code n'est pas toujours disponible. Cela dépend toujours de si mes systèmes sont configurés pour un accès extérieur.
Bart van Ingen Schenau

Si des personnes extraient du code de votre référentiel et le fusionnent avec le leur, elles peuvent restaurer, indépendamment et sans problèmes de masse . Deuxièmement, bien sûr, si vous décidez de refuser l’accès à votre base de code et de paralyser une caractéristique majeure du système, vous pouvez forcer l’ isolement sur vous-même. C'est très différent d'un système modélisé pour un développement isolé. DVCS n'est pas. Votre compréhension du modèle de travail de DVCS est tout simplement fausse.
philosodad

1
@philosodad: Je pense que je commence à le comprendre de mieux en mieux: tout le monde peut avoir vos dégâts, comme dans un CVCS, mais ce n'est plus de votre faute, car vous ne les avez pas poussés dessus. :-)
Bart van Ingen Schenau

Bien ... en quelque sorte. Mais en général, Alice clonerait ou créerait une branche d’abord, puis fusionnerait vos modifications, ce qui faciliterait la tâche de prétendre qu’elle n’avait jamais vu votre code buggy!
philosodad
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.