Nous sommes Subversion Geeks et nous voulons connaître les avantages de Mercurial [fermé]

Après avoir lu que je suis un geek de Subversion, pourquoi devrais-je considérer ou non Mercurial ou Git ou tout autre DVCS .

J'ai une question de suivi connexe. J'ai lu cette question et lu les liens et vidéos recommandés et je vois les avantages mais je ne vois pas le changement de mental global dont les gens parlent.

Notre équipe est composée de 8 à 10 développeurs qui travaillent sur une grande base de code composée de 60 projets. Nous utilisons Subversion et avons un tronc principal. Lorsqu'un développeur démarre un nouveau cas Fogbugz, il crée une branche svn, effectue le travail sur la branche et une fois terminé, il fusionne à nouveau dans le tronc. Parfois, ils peuvent rester sur la branche pendant une longue période et fusionner le tronc à la branche pour prendre les changements.

Quand j'ai regardé Linus parler de personnes créant une branche et ne plus jamais recommencer, ce n'est pas nous du tout. Nous créons probablement 50 à 100 succursales par semaine sans problème. Le plus grand défi est la fusion, mais nous y sommes également devenus très bons. J'ai tendance à fusionner par fogbugz case & checkin plutôt que par la racine entière de la branche.

Nous ne travaillons jamais à distance et nous ne faisons jamais de succursales à partir de succursales. Si vous êtes le seul à travailler dans cette section de la base de code, la fusion vers le tronc se fait en douceur. Si quelqu'un d'autre a modifié la même section de code, la fusion peut devenir compliquée et vous devrez peut-être faire une intervention chirurgicale. Les conflits sont des conflits, je ne vois pas comment un système pourrait le faire la plupart du temps, à moins qu'il ne soit assez intelligent pour comprendre le code.

Après avoir créé une branche, la vérification suivante des fichiers 60k + prend un certain temps, mais ce serait un problème avec tout système de contrôle de source que nous utiliserions.

Y a-t-il des avantages de tout DVCS que nous ne voyons pas qui nous seraient d'une grande aide?

Pour reformuler votre question, "Si nous prévoyons d'utiliser uniquement le DVCS de manière centralisée, quels sont ses avantages?" Quand vous le demandez ainsi, ce n'est pas le cas. Une branche par tâche est extrêmement courante dans VCS. Si vous y pensez, avoir une copie de travail locale du code source sur la machine d'un développeur qui change indépendamment du tronc pendant une journée est une branche, même si personne ne l'appelle ainsi. La seule différence entre cela et votre flux de travail est que vous donnez également à ces branches un nom permanent sur le serveur central. Ce n'est pas le genre de ramification dont Linus et d'autres parlent.

Comprendre le DVCS nécessite un changement fondamental de pensée. Vous devez vous demander ce que vous feriez avec autant de branches que vous le souhaitez qui sont partagées avec qui vous voulez, et seulement avec elles. Cela inclut les branches qui ne sont visibles que par vous-même.

Les possibilités sont infinies. Pour un seul exemple, que diriez-vous de deux personnes travaillant sur les côtés opposés d'une interface? Ils doivent partager du code régulièrement, mais ce n'est pas encore assez stable pour le partager avec tout le monde. Ils peuvent créer une branche à partager entre eux, puis la fusionner à nouveau dans le référentiel central lorsqu'elle est prête.

La capacité de faire des commissions locales intermédiaires en vaut la peine. C'est quelque chose que vous n'avez qu'à expérimenter par vous-même.

La vitesse gagnée en ayant votre repo local en vaut également la peine. Oui, le clone initial sera inévitablement lent dans n'importe quel VCS pour un dépôt de fichiers de 60k, mais une fois que vous avez cela, vérifier une nouvelle branche est plus rapide avec un DVCS.

Pour votre cas particulier, il n'y a aucun avantage à passer à un DVCS. Vous êtes satisfait de votre système existant, il fait tout ce dont vous avez besoin, alors pourquoi changer? SVN est toujours un projet Open Source actif et a des intégrations meilleures et plus matures avec tous les principaux IDE et outils de développement que hg ou git. Compte tenu de la taille de votre équipe et du nombre de projets, voulez-vous vraiment prendre le temps de vous convertir à un nouvel outil alors que celui qui fonctionne fonctionne très bien?

Si vous avez des développeurs qui ne peuvent tout simplement pas fonctionner sans DVCS, dirigez-les vers les passerelles svn pour hg ou git. Expliquez-leur très clairement que leurs connexions au référentiel svn doivent être conformes aux procédures et processus utilisés par le reste de l'équipe. Un autre avantage de cette approche est que les vrais fanatiques DVCS qui utilisent déjà les passerelles sans vous le dire peuvent maintenant sortir du placard :-).

Il me semble que vous utilisez déjà un flux de travail qui est très similaire au type de flux de travail que de nombreuses personnes adoptent après avoir commencé à utiliser un DVCS.

De votre point de vue, un DVCS aura les avantages significatifs suivants par rapport à SVN:

• Une fois que vous avez cloné votre référentiel, de nombreuses opérations peuvent être effectuées localement.
  • La consultation du journal du référentiel n'a pas besoin de toucher le serveur svn, elle peut donc être incroyablement rapide.
  • De même, le changement de branche ne nécessite pas d'accès au serveur, pas plus que les clones locaux.
• Parce que les branches ne sont que des chemins divergents à travers l'historique, votre référentiel n'est pas encombré de chaque branche que quiconque a créée (nous n'avons vraiment que des branches de version dans SVN, mais le branchesrépertoire contient toujours de nombreux sous-répertoires qui ne sont plus pertinents).
  • Dans git, une fois qu'une branche a été fusionnée et que la référence a été supprimée, vous ne saurez peut-être même pas qu'elle était là.
  • Dans Mercurial, vous avez le choix entre nommer une branche (auquel cas elle est encodée dans chaque ensemble de modifications à perpétuité) ou simplement créer une branche sans nom (topologique), qui fusionnera tranquillement dans l'historique lorsqu'elle sera mergeréintégrée dans default( trunk)
• Dans SVN, les branches des branches sont beaucoup trop obscures pour être utiles. En gitet hgils sont juste à égalité pour le cours.
• DVCS comprend que le développement logiciel est un DAG , c'est-à-dire que lorsque vous fusionnez, vous vous retrouvez avec un ensemble de modifications avec plusieurs parents. SVN (au moins la version que j'ai utilisée) ne comprend pas vraiment cela.

Sur ce dernier point, vous dites

Les conflits sont des conflits, je ne vois pas comment un système pourrait le faire correctement la plupart du temps à moins qu'il ne soit assez intelligent pour comprendre le code.

En passant de l'utilisation hgexclusive à l'utilisation svnseule, et selon gitsvnmon expérience, les fusions sont beaucoup plus simples et sans problème avec hget avec gitsvnelles svn. Les fusions avec svn(au moins la version que nous utilisons) produisent beaucoup plus de conflits qui doivent être résolus manuellement.

L'une des raisons pour lesquelles les fusions sont plus difficiles dans SVN est qu'il ne vous donne que deux options pour chaque ligne qui diffère,

• le texte de la branche dans laquelle vous fusionnez
• le texte de la branche dans laquelle vous fusionnez

tandis que la fusion à partir d'un DVCS vous donnera généralement une troisième option, qui est

• le texte de l'ancêtre commun des deux branches que vous fusionnez

Ne sous-estimez pas à quel point cela est bénéfique, il vous offre un bien meilleur contexte pour les changements qu'un simple différentiel bidirectionnel.

Dans l'ensemble, je vous suggère d'essayer. Avec des outils comme gitsvnet hgsubversion, vous pouvez même les essayer avec votre dépôt SVN actuel .

^{Remarque, la création du clone en premier lieu est une PItA royale, mais une fois que vous avez fait cela, vous obtenez la plupart de la puissance d'un DVCS avec votre CVCS existant.}

Il y a un changement important que j'ai remarqué après une telle transition: je change de branche beaucoup plus souvent et je m'engage plus souvent que je ne pourrais jamais me le permettre avec Subversion. Par exemple, il existe un certain nombre de minuscules branches de fonctionnalités, organisées en séquence, et je peux passer des mois à ajouter des bits à chacune d'entre elles, en les rebasant facilement toutes de manière séquentielle dans un tronc en constante évolution. Réorganiser l'ordre dans lequel les branches de fonctionnalité sont fusionnées est trivial.

Mais, en fait, je ne me suis pas vraiment éloigné de Subversion. J'utilise juste git comme client svn local.