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

22

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?

Mat
la source
Il semble presque que vous utilisiez déjà SVN comme DVCS (en ce qui concerne la ramification, de toute façon). Je suis sûr que vous pouvez faire presque tout ce que Mercurial peut faire avec SVN (et vice versa); la question est alors, laquelle est plus facile à utiliser et plus pratique pour votre scénario de développement particulier? Je pense que vous devrez essayer Mercurial un peu pour voir par vous-même si cela en vaut la peine ou non
Cameron
Je suis un fan de Mercurial et il offre clairement un surensemble des fonctionnalités de SVN, mais cela étant dit, ces fonctionnalités supplémentaires ne sont vraiment utiles que pour une petite minorité de projets. Vous n'en avez probablement pas besoin, cela ne changera pas votre vie, mais vous obtiendrez plus de fonctionnalités et ne perdrez rien, alors pourquoi pas?
jiggy
Avez-vous vérifié Hg Init ? C'est un tutoriel Mercurial écrit par Joel Spolsky. Il commence par un chapitre pour les utilisateurs de Subversion, mais attend autrement que vous ne sachiez rien du DVCS.
Barry Brown

Réponses:

11

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.

Karl Bielefeldt
la source
2
+1! De plus, si vous essayez mercurial de manière juste et approfondie, je suis certain que vous ne voudrez pas y retourner.
Pete
1
"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" ... "deux personnes travaillant sur les côtés opposés d'une interface? Elles doivent partager du code avec chacune d'autres régulièrement, mais il n'est pas encore suffisamment stable pour être partagé 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 sera prête. Nous avons tout cela maintenant avec la subversion.
Matt
@Matt, alors vous avez de la chance car votre entreprise est plus l'exception que la règle. La plupart des entreprises ont des règles très strictes sur la création de succursales sur les ressources limitées du serveur central, de sorte que les gens ne pensent même pas à les créer pour des raisons temporaires.
Karl Bielefeldt
3
Je pense que cette réponse ne tient pas compte du fait que l'affiche originale contraint déjà SVN à fonctionner d'une manière qui est beaucoup plus proche d'un flux de travail DVCS que la plupart des utilisateurs de SVN ne le jugeraient viable. En substance, ils ont déjà l'état d'esprit DVCS, donc aucun changement fondamental de pensée n'est nécessaire.
Mark Booth
Bon point @Mark. Sur une si petite équipe, beaucoup de conventions normales pour les grandes équipes disparaissent. Je pense toujours que ça vaut le coup pour des raisons de vitesse.
Karl Bielefeldt
1

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 :-).

dfjacobs
la source
Voulons-nous prendre le temps de changer? Non, surtout pas lorsque nous sommes passés à svn au cours des 2 dernières années seulement. Merci pour vos commentaires.
Matt
1

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.

Mark Booth
la source
1
SVN ne déclenche pas de conflit dans le cas que vous mentionnez non plus. Il n'apparaît que lorsque vous changez tous les deux les mêmes lignes. La fusion est généralement un problème plus avec les renommages / déplacements de fichiers ou l'ajout / suppression dans svn car il ne gère pas bien les changements de répertoire de fusion. La fusion SVN vous donne plus d'options que ces 2, généralement j'utilise le "utiliser le leur puis le mien" car vous voulez généralement conserver les deux ensembles de modifications, pas les supprimer tous les deux!
gbjbaanb
@gbjbaanb - Ce n'est pas ce que j'ai trouvé, c'est pourquoi j'ai qualifié mon expérience de SVN avec at least the version I've used. Je crois comprendre que la dernière version de svn ne comprend au sujet des ancêtres communs, mais je n'ai aucune expérience et je soupçonne qu'il ya beaucoup de serveurs là - bas les anciennes versions en cours d' exécution de svn qui ont les mêmes problèmes.
Mark Booth
Soit dit en passant, j'aime le fait qu'avec hg(et presque certainement git, mais je ne l'ai pas essayé), vous pouvez prendre un fichier avec trois classes, le diviser en trois fichiers avec une classe chacun, puis fusionner plus tard les modifications entre une branche avec le fichier «combiné» et une branche avec des fichiers séparés de sorte que les modifications apportées aux classes individuelles soient appliquées aux fichiers corrects. Magie pure. * 8 ')
Mark Booth
1
gbjbaanb est correct; SVN n'aurait pas de conflit dans le scénario que vous décrivez. Il est assez facile de vous le démontrer.
Jeremy
@Jeremy @gbjaanb - La section modifiée fonctionne-t-elle mieux pour vous? Je ne vais pas discuter avec vous de la façon dont les svnfusions devraient fonctionner, j'ai ma propre expérience avec la svnligne de commande et SVNKit sous Eclipse où le simple fait de tirer des mises à jour peut entraîner des `` conflits '' qui doivent être résolus manuellement avec couper et coller (Je ne peux pas facilement dire «Je veux ces deux changements, dans cet ordre).
Mark Booth
0

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.

SK-logic
la source