J'utilise SVN depuis un certain temps et je suis assez heureux de la façon dont cela fonctionne (mais je ne peux pas dire que je suis un expert, et je n'ai pas vraiment beaucoup fait avec des branches et la fusion). Cependant, une opportunité est apparue de mettre dans de nouvelles pratiques sur une nouvelle équipe et j'ai donc pensé jeter un coup d'œil aux DVCSS pour voir si cela vaut la peine de faire le saut.
La société que je travaille pour est une jolie société standard où nous travaillons tous au même endroit (ou parfois à la maison) et nous voulons garder un magasin central de tout code.
Ma question est la suivante: si tout ce que vous faites avec un DVCS crée une concentrateur centrale que tout le monde pousse ses modifications, existe-t-il vraiment des avantages pour se déplacer vers un DVC et ses frais généraux supplémentaires dans ce type d'environnement?
11 Réponses :
Avec les personnes de DVCS peut conserver leurs propres branches locales sans apporter des modifications dans le référentiel central et poussez leurs modifications au référentiel principal lorsqu'ils pensent qu'il est préparé. Notre projet est stocké dans un référentiel SVN mais personnellement, j'utilise Git-SVN pour gérer mes modifications locales et le trouver tout à fait utile, car nous ne sommes pas autorisés à soumettre tous les changements immédiatement (ils doivent être approuvés par l'intégrateur d'abord). < / p>
«Les personnes de DVCS peuvent conserver leurs propres branches locales sans modifier le référentiel central», cela peut être considéré comme un avantage ainsi qu'un inconvénient.
Je peux totaliser le bénéfice d'avoir une histoire de verion locale, mais je peux également voir une question de plusieurs caractéristiques étant «en développement» étant parsemées avec une manière émédante de savoir quoi et où. Mais alors peut-être que cela est plus bas pour la gestion de projet.
Vous auriez cet irresépctif de DVC mais sûrement? Ou enregistrez-vous une moitié de travail de travail à SVN?
@JK: En fait, je fais. Je crée fréquemment (et détruire) des branches de fonctionnalité à cette fin. L'avantage de le faire avec SVN est que tout est sauvegardé avec la sauvegarde du serveur SVN. L'inconvénient est que tout est sauvegardé avec la sauvegarde du serveur SVN. :)
Personnellement, je trouve que c'est un énorme avantage. Même avec un repo central, un DVCS modifie le flux de "code d'édition, la mise à jour de Central, commettre" à "modifier le code, commettre, appuyer sur central". Entre autres choses, cela signifie que la résolution des conflits est beaucoup moins stressante. Cela peut également encourager le développement en petits morceaux, car vous n'avez pas à pousser après chaque commit. Si votre équipe est acceptable, cela signifie que vos engagements individuels peuvent quitter l'application dans un État étrange, tant que cela fonctionne lorsque vous enfoncez enfin au Repo central. Si elles ne sont pas correctes avec cela, aussi longtemps que vous utilisez git (ou hg , IIRC), vous pouvez toujours faire du développement dans le même style, mais puis condenser tout votre plus petit s'engage dans un grand commit qui est terminé avant de la pousser le repo central.
Je pense que le principal avantage d'un DVCS vient lorsque vous souhaitez appuyer vos modifications directement à d'autres personnes (ou machines, par exemple, prenant la maison de référentiel avec vous), sans passer à travers une hub centrale. Si vous avez la nécessité de le faire, un DVC est définitivement la voie à suivre. Si, comme vous le dites,
Tout ce que vous faites avec un DVCS crée un hub central que tout le monde pousse leurs modifications à
Alors vous ne profitiez pas vraiment de l'objectif principal d'un DVC et je dirais que SVN suffit.
P.s. On pourrait également faire l'argument selon lequel un DVC encourage les utilisateurs à s'engager plus souvent, car ils peuvent le faire dans leur référentiel personnel et ne publient que leurs modifications lorsqu'elles sont prêtes - mais cela peut être facilement accompli dans SVN à l'aide de branches, avec le seul " Inverside "Être que" personnelle "commettre l'incrément du numéro de version de l'ensemble du référentiel.
Vous obtiendrez la guerre inévitable de Git vs Mercurial à partir d'ici bientôt ... :-) J'utilise personnellement mercurial, mais ce que j'ai à dire devrait être approprié pour tous dvcs .
À mon avis, oui, ils sont adaptés à une utilisation en entreprise. Je les utilise à ma propre entreprise, mais avec un petit nombre de développeurs de l'utiliser, mais si vous êtes inquiet au sujet d'évolutivité, regardez les grands projets open source en utilisant git et mercurial, par exemple Mozilla, Python.
L'approche de moyeu central fonctionne bien - il est un modèle de travail familier aux utilisateurs de subversion et vous avez toujours une version « définitive ». Verrouillez l'accès à ce et appliquer les crochets pour appliquer des politiques et engager après, les développeurs ont une grande liberté au travail comme la façon dont ils avec leurs copies locales.
Un autre grand plus est que j'ai trouvé la fusion beaucoup moins douloureux avec Mercurial que la subversion.
Le plus délicat de Qu'est-ce avec un DVCS gère les fichiers binaires - vous ne pouvez pas exiger un verrou sur un fichier binaire comme vous pouvez avec la subversion (entre autres). Gérer cette communication avec idéalement.
Enfin, le clonage d'un repo est idéal pour garder synchronisés si checkouts vous travaillez à partir de plusieurs ordinateurs.
Hope this helps.
K
Tout dépend de la façon dont vous voulez travailler sur des projets. Les environnements distribués sont formidables si tout le monde veut s'appuyer sur sa propre branche. Je préfère un référentiel central pour mon travail (dans une petite équipe) car il fait que les développeurs pensent à libérer une version de notre produit.
Dans mon expérience, je vois beaucoup d'utilisateurs de DVCS qui pensent à leurs propres changements comme ceux qu'ils n'ont pas à examiner et ces utilisateurs examinent les changements de tous les autres développeurs avant de les fusionner dans leur propre arbre. J'aime voir mes changements comme la modification du produit principal, alors j'examine ces changements avant de les engager. En conséquence, nous essayons de garder le produit assez stable pendant tout le cycle de développement. Refactoring fonctionne bien, comme nous mettons tous la mise à jour souvent.
Plusieurs utilisateurs de DVCS que je connais préfèrent travailler sur leur fonctionnalité sur un arbre indépendant et laisser l'intégration avec le produit central à la phase finale de leur développement. Cela fonctionne bien si la fonctionnalité est indépendante, mais je ne voudrais pas être celle qui doit intégrer toutes les fonctionnalités développées de cette façon avec une échéance de la vue.
Si vous intégrez souvent, les DVCS ne diffèrent pas beaucoup des VCS centraux, et la plupart des DVCS prennent en charge un référentiel central, tandis que de plus en plus de VCs centraux ont soutenu plusieurs caractéristiques où les DVCs sont auparavant, tels que la commission et les étagères hors ligne.
(FYI: Les engagements hors ligne sont planifiés pour Subversion 1.8)
La fusion d'une "fonctionnalité" complète est de quelque chose qui me concerne aussi. Je sais ce que c'est comme plus que plus vous laissez le code non commité dans SVN. Je suppose que c'est juste à la définition de "fonctionnalité" dans ce cas, en veillant à ce que ce ne soit pas trop important.
Vous appuyez sur vos changements quand ils sont terminés, mais vous devriez toujours vous tirer dans toutes les changements d'essasse régulièrement (au moins quotidiennement IMHO), donc il n'y a pas une énorme différence entre votre branche et d'autres
@JK @matt: Mais si tout le monde ne pousse pas leurs changements parce qu'ils travaillent comme vous êtes alors vous finissez toujours avec une grosse fusion à faire lorsque quelqu'un fait enfin enfoncé.
Les frais généraux ne sont pas si gros, en fait, dans notre environnement, la poussée HG ajoutée est inférieure à une tenue de tête que de se rendre au représentant central SVN. Mais le plus grand avantage est toutes les cloches et sifflets qui viennent avec Mercurial, qui sont parfaits pour un développeur individuel, quelle que soit la taille de l'équipe ou le flux de travail. Tout d'abord, le fait que chaque WC est un repo est excellent, car vous pouvez expérimenter beaucoup plus librement sans polluer le député principal. Ensuite, il y a des fonctionnalités qui s'appuient sur le WC == repo Égalité: bisect pour trouver rapidement la révision dans laquelle un bogue s'est installé, grep à, eh bien, grep l'historique, ainsi que la fonctionnalité manquante simplement de la subversion, comme des diffètes de couleur dans le terminal.
Le grand bénéfice de l'utilisation d'un DVCS pour moi est que je puisse vous engager dans mon référentiel local sans avoir à partager ces changements avec tout le monde. Ainsi, lorsque vous travaillez sur un gros changement, je fais de petits commits incrémentiels, ce qui signifie que je peux revenir au travail de 30 dernières minutes, ou faire une diffuse contre une version qui fonctionnait hier, mais seulement appuyer uniquement vers le référentiel central une fois que tout mon travail est terminé. .
Je pense que cet avantage est seul vaut la peine de passer à un DVCS pour.
Cependant, l'utilisation d'un DVCS nécessite un peu plus de pensée et de compréhension et d'utilisation d'un système de contrôle de version "standard" tel que SVN ou CVS, vous devez donc envisager la surcharge de formation si vous passez à un DVCS ou à votre référentiel central se retrouvera. plein de beaucoup de branches différentes, les gens n'ont pas réalisé qu'ils créaient.
De votre premier paragraphe - est-ce essentiellement différent de créer votre propre branche de développement dans SVN? Je n'ai pas encore pris connaissance de DCVS, alors je suis curieux de comprendre la différence.
Je suppose que ce n'est pas si différent, même si je pense que vous trouverez lors de l'utilisation d'un DVCS fusionnant des changements moins douloureux, car le référentiel stocke une histoire de jeux de changement. Mon expérience (limitée) de la fusion avec SVN est que c'était un processus horrible, principalement manuel, bien que j'aurais pu me tromper mal. Lorsque vous utilisez Mercurial, j'ai constaté que la fusion de mes changements dans le référentiel central était presque indolore, avec mon intervention uniquement lorsqu'il y avait un conflit authentique. Je suppose que Git est la même chose.
"Le grand avantage de l'utilisation d'un DVCS pour moi est que je puisse s'engager dans mon référentiel local sans avoir à partager ces changements avec tout le monde." Vous pouvez le faire via la ramification dans à peu près à chaque VCS, et certains soutiennent également des étagères.
Même avec un flux de travail de moyeu, un DVCS vous permet de faire de petits commetts localement, de les fusionner uniquement lorsque vous le souhaitez et de les pousser quand ils sont prêts.
Avec un non-DVCS, vous êtes obligé de:
Et si vous explorez une impasse, sans DVCS: avec la première méthode, vous ne pouvez pas rembobiner, vous n'avez pas de vous engager de revenir à; Avec la seconde, vos commits et leurs revêtements devaient être fusionnés inutilement par tous les autres.
Voulez-vous toujours avoir la question de la poussée d'une énorme commit lorsque vous terminez une fonctionnalité locale et que vous souhaitez le pousser au moyeu?
Vous devriez profiter de vos DVCS et faire de petits commits au lieu d'un grand. Vous devez fusionner vos petits commits avec les nouveaux engagements sur le moyeu, mais vous avez la capacité de le faire uniquement lorsque vos commits sont complets et prêts à être testés.
Les énormes commettent-ils que vous poussez à distance un inconvénient?
En savoir plus étroitement, les énormes commettrations sont une conséquence naturelle de l'utilisation d'un VCS centralisé VCS.
Bazaar VCS peut fonctionner comme VCS distribué et en tant que VC centralisés afin que vous ayez la liberté de sélectionner le flux de travail avoir besoin. Dans le même temps, les branches privées locales (où les gens peuvent expérimenter tout en travaillant sur de nouvelles fonctionnalités et, à la fois commettre leurs progrès régulièrement) sont Les DVC constituent également un flux de travail de développement naturel lorsque la révision de code obligatoire requise avant que de nouveaux changements ne soient débarqués au coffre. Ce flux de travail (concernant SVN) décrit brillamment dans le Article UQDS . Et malgré le fait que l'article décrit le flux de travail basé sur SVN, vous le trouverez plus naturel lorsque vous utilisez des DVC au lieu de SVN, car dans les DVCS Branching et la fusion est une opération de première classe de base.
Personnellement, je pense que le plus gros avantage des DVC est que vous vous engagez (localement) avant de la fusionner, donc si à mi-chemin de la fusion, il s'avère être plus complexe que vous ne le pensez à l'origine, il est trivial de revenir à un état propre sans perdre votre travail. comparer aux CVC où vous devez généralement fusionner avec succès avant de pouvoir vous engager.
Avantages supplémentaires incluent:
Dans mon expérience, il existe plusieurs façons d'utiliser un DVCS dans un environnement d'entreprise:
Support multi-sites: vous avez des équipes séparées et vous utilisez vos DVCS pour configurer différents "serveurs" à chaque emplacement, de manière à ne pas être limitées par les problèmes de réseau sous-jacents (et croyez-moi, il y aura ). Cela avait l'habitude d'être fait avec des "grandes choses" comme ClearCase Multi-site ou Wandisco (pour SVN / CVS), mais il est maintenant assez faisable avec des systèmes DVCS.
Support "Utilisateurs itinérants": vous êtes un Corp. Développeur, mais vous voulez travailler à la maison pendant une certaine heure (ou jamais): au lieu de compter sur le VPN, vous pouvez avoir un DVC à votre ordinateur portable, puis vous êtes libre de commettre, d'examiner, de diffuser, de diffuser et de fusionner sans être lent bas par le serveur central. Vous vous synchronisez lorsque vous êtes en ligne ou à votre retour au bureau.
vrai "développement distribué": qui est le cas extrême: chaque développeur ayant ses propres DVCS (comme vous le feriez sur le monde OSS). Cela dépendra vraiment des compétences et de la motivation de l'équipe: si l'équipe veut vraiment y passer, elles en bénéficieront, sinon ce sera le cauchemar de Sysadm de ne pas gérer pas un seul repo mais des centaines ... avec leurs problèmes correspondants.