J'ai cherché et n'ai trouvé aucune raison commerciale pour laquelle les systèmes git / mercurial / bazzr sont meilleurs que les systèmes centralisés (subversion, perforce).

Si vous tentiez de vendre un DVCS à une personne non technique, quels arguments fourniriez-vous pour que le profit DVCS augmente .

Je vais bientôt lancer git à mon manager, cela prendra du temps pour convertir les référentiels de subversion et quelques dépenses pour acheter des licences smartgit.

Edit J'ai essayé de faire de cette question une discussion générique sur centralisée vs décentralisée, mais inévitablement elle s'est transformée en git vs subversion. Il existe certainement de meilleurs systèmes centralisés que la subversion.

Hmm, après avoir été manager, j'ai deux réactions immédiates à ce sujet:

• Si vous n'avez pas déjà de bonnes raisons pourquoi lancez-vous autre chose que d'être à la mode?
• De même, comment Subversion échoue-t-il au point que vous ayez besoin d'un remplacement?

Je ne suis pas, en fait, négatif - je pense qu'il y a probablement un argument à faire (selon les circonstances) mais si le cas est simplement que git est "meilleur" que la subversion alors vous n'en avez pas vraiment un.

Vous devez également être en mesure d'énumérer les inconvénients - vous avez déjà identifié les frais généraux liés à la migration et au réoutillage - quel est le problème supplémentaire? Par exemple, qu'advient-il de votre joli référentiel central et sauvegardé? Comment vous intégrez-vous à votre serveur de build d'intégration continue (si vous n'en avez pas, oubliez git et commencez par trier cela). Oh sécurité et suivi - SVN fonctionne avec des connexions et des autorisations appropriées.

À mon avis, les avantages sont la flexibilité, une meilleure fusion, la possibilité de faire des commits locaux sans casser la construction et ainsi de suite. Les inconvénients sont le manque de contrôle et la même flexibilité.

Il se peut que tout ce que vous voulez faire soit d'exécuter git localement sur votre machine en tant que "meilleur" client de subversion (je cherche à le faire en utilisant mercurial).

Hmm, peut-être que toute cette réponse est vraiment un commentaire? Vous devez présenter votre argumentation ici (dans la question) pour git over subversion (dans votre environnement) afin de voir si nous pouvons vous aider à identifier l'analyse de rentabilisation.

FWIW, je sais que l'on peut facilement désigner une instance spécifique du référentiel comme source de tronc / référence et que c'est ainsi que l'on se connecte à son serveur de build - la différence étant qu'avec DVCS, c'est plus une décision administrative que quelque chose d'inhérent à l'architecture.

Je dirais que la ramification et la fusion rapides et indolores permettraient aux développeurs d'être plus productifs avec leur code, car chaque nouvelle fonctionnalité pourrait être branchée, puis fusionnée plus tard. Rendre le processus de développement plus fluide. De plus, la nature distribuée permettrait à chaque développeur d'avoir une copie complète du code, donc il n'y a pas à craindre qu'une panne de serveur centralisée ne supprime tout votre code. Il y a probablement plus de raisons, ces deux-là, cependant, sont mes principales raisons d'utiliser Git.

Je suppose que vous pouvez plaider en faveur d'un contrôle de version augmentant la productivité (et donc le profit) même lorsqu'un développeur travaille seul.

Un bon DVCS reconnaît les mêmes avantages de productivité même lorsqu'il travaille en équipe - chaque développeur peut bénéficier de tous les avantages du contrôle de version - il peut effectuer des validations fréquentes, des retours en arrière, jouer avec les choses, etc. - sans se soucier des conflits avec ce que les autres développeurs font jusqu'à ce qu'ils soient prêts à pousser leurs modifications.

• Branche par bogue
• Latence réduite sur vos diffs.
• Être en mesure de naviguer très rapidement et arbitrairement dans l'historique d'une succursale lorsque vous passez en revue par des pairs.
• Vous avez toujours accès à l'intégralité de votre historique lorsque vous n'avez pas accès au serveur centralisé: vous n'êtes pas au bureau, l'alimentation vient de s'éteindre mais la batterie de votre ordinateur portable fonctionne toujours, ...

Ces choses vous permettent de travailler plus efficacement, à la fois en solo et en équipe. Travail plus efficace = temps de développement plus rapide = temps de mise sur le marché plus rapide = profit.

Pardonnez-moi de créer un lien vers mon propre blog, mais j'ai écrit des articles sur ce même sujet:

• Pourquoi le conseil doit toujours compiler
• Pourquoi DVCS offre un meilleur contrôle central
• Pourquoi le branchement est meilleur avec DVCS
• Pourquoi les modèles de branchement distribué peuvent ne pas fonctionner correctement sur votre CVCS .

N'hésitez pas à voter contre si vous ne les trouvez pas pertinents.

En un mot, DVCS facilite les modèles de branchement qui peuvent empêcher de grands groupes de développeurs de marcher les uns sur les autres, ce qui augmente à la fois la productivité et la qualité de construction quotidienne. La partie de collaboration désordonnée du contrôle de version peut être effectuée dans des référentiels locaux, laissant votre référentiel central plus propre et de meilleure qualité. De plus, les décisions sur le moment de la succursale peuvent avoir un grand effet sur l'efficacité, par exemple si un département est prêt à commencer à travailler sur 2.0 alors que 1.0 est toujours nettoyé par d'autres. Le DVCS permet que ces décisions soient prises au niveau local plutôt que par comité.

Mes arguments pour DVCS sont les suivants:

• La ramification n'est pas rompue, ce qui réduit les frictions dans le développement des fonctionnalités et le maintien des correctifs des produits existants. La friction coûte de l'argent à temps.

• Le passage à un système moderne attire mieux les développeurs de pointe, ce qui conduira à une culture de meilleurs produits, ce qui permettra à l'entreprise de vendre plus de produits.

• Les validations hors réseau sont plus rapides , ce qui permet aux développeurs de s'engager souvent, ce qui conduit à une détection et une analyse fines des bogues.

Il s'agit essentiellement de réduire la friction. Il y a un terme pour cela: Muda . Plus il y a de friction, plus c'est douloureux de faire les choses. Plus il y a de douleur, moins on en fait, moins il y a de profits.

Je m'excuse si je suis en règle, mais permettez-moi de présenter l'analyse de rentabilisation en termes non incertains:

SVN rend la vie des développeurs misérable . Et cela rend une entreprise de logiciels misérable.

... d'une manière que beaucoup ne réaliseront pas avant de commencer à utiliser un DVCS. Il s'agit de l'analyse de rentabilisation la plus importante qui puisse être faite . Pourquoi? Eh bien, comparé au coût de la recherche et de la conservation de bons développeurs, le coût du passage à un DVCS est presque inexistant .

Considérer ce qui suit:

• Toutes les opérations, sauf les plus triviales, dans SVN (et la plupart des autres CVCS) nécessitent un accès réseau. Dans la plupart des DVCS, l'accès au réseau se produit uniquement lorsque vous effectuez une opération pushou pull. Cela signifie que les commandes non triviales sont lentes . Que faites-vous quand une commande prend une éternité? Je vais personnellement parcourir programmers.se ou hacker news en attendant. En termes simples, les DVCS permettent aux programmeurs de se concentrer sur ce qu'ils aiment: écrire les logiciels de l'entreprise .
• SVN a un soutien pour la ramification de la même manière que les prisons ont un soutien pour laisser tomber votre savon sous la douche: vous pouvez le faire, mais quand vous le faites, vous vous faites baiser. Ainsi, SVN oblige vos développeurs à se battre constamment les uns contre les autres pour apporter des modifications .
• Lorsque SVN est en panne, c'est en baisse. Il devient terriblement difficile pour les développeurs de faire leur travail s’ils peuvent le faire. Ainsi, SVN oblige vos développeurs à dépendre de votre infrastructure à 100% sans bogue .
• De nos jours, git gagne rapidement en partage tandis que SVN la perd rapidement. S'il n'y a aucun avantage à utiliser DVCSes sur SVN, pourquoi la communauté de programmation évolue-t-elle aussi vite qu'elle le peut?

Qu'est-ce que tout cela représente? Je n'ai pas encore rencontré un développeur qui a donné un DVCS un essai honnête qui préférerait SVN par la suite. Si je pouvais faire encore une déclaration ennuyeuse et audacieuse, SVN est un "mal nécessaire" que les développeurs se forcent à utiliser. Git est un outil qui rend les développeurs plus productifs et plus heureux .

(Je dois souligner que les déclarations en gras sont celles sur lesquelles vous devez vous concentrer. Les autres fournissent simplement un contexte.)

La seule chose à laquelle je peux penser est que git fonctionne sans connexion réseau. Tout le reste est même souvent difficile à vendre aux utilisateurs techniques qui utilisent subersion ou perforce depuis un certain temps.

La différence montre quand il y a des problèmes

Nous sommes passés à git il y a 6 mois après avoir porté notre dépôt vieux de dix ans.

Jusqu'à présent, j'ai trouvé ce qui suit, après un peu d'expérimentation:

• ramification et fusion est presque indolore. Cela rend beaucoup plus facile de travailler sur des fonctionnalités distinctes et de corriger des bogues sans marcher les uns sur les autres. Cela facilite également l'application d'un correctif de bug donné ailleurs.

• plus robuste par conception - vous ne comptez pas à 100% sur la disponibilité d'un serveur central, et si ce n'est pas le cas, vous pouvez utiliser la promotion de n'importe quel clone temporairement comme remplacement à chaud. Cela supprime un point de défaillance crucial - si le serveur SVN tombe en panne pour une raison quelconque, personne ne peut faire de travail SVN. Si le référentiel central git tombe en panne pour une raison quelconque, vous pouvez toujours travailler et pousser / tirer localement pour vous assurer que les validations sont répliquées. Vous pouvez même avoir plusieurs référentiels hors site à cet effet.

• l'interaction du référentiel est simplifiée. Pour CVS, vous aviez essentiellement besoin d'un accès permanent à tout moment et à tout moment. Pour git, l'ensemble du référentiel est disponible localement, permettant à beaucoup de choses d'aller plus vite.

Ainsi, l'avantage n'est pas autant dans la routine quotidienne, mais est très clair au moment où vous avez quelque chose qui ne fonctionne pas correctement!

Par conséquent, je suggère que pour votre analyse de rentabilisation, regardez ce que vous ferez en cas de catastrophe ...

La facilité de ramification et de fusion est la raison la plus concrète, mais pour convaincre quelqu'un, vous devrez lui donner un exemple concret de la façon dont cela améliore les choses.

Disons que vous avez quelques programmeurs qui travaillent sur l'amélioration des performances d'une application, et qu'ils sont au stade expérimental et ne savent pas si le code qu'ils écrivent fera jamais partie de la branche master / trunk. Cependant, ils doivent fréquemment partager du code entre eux et essayer des idées qui peuvent être des impasses. Comment gérez-vous des branchements et des fusions si fréquents en subversion? La réponse courte est que vous ne le faites pas. Avec un dvcs, c'est vraiment facile, et les programmeurs peuvent rapidement essayer de nouvelles idées dans les branches et partager avec les autres avant de décider si cette idée persistera.

L'analyse de rentabilisation pour l'abandon de SubVersion est que le support de branchement est un obstacle à la stabilisation et à la maintenance des produits. Si vous devez publier un produit puis poursuivre le développement, vous avez besoin d'une branche. Avec subversion, les développeurs n'utiliseront pas correctement les branchements, et donc vous ne pourrez pas continuer le développement sur le tunk, et vous assurer que les corrections de bugs arrivent réellement à la fois sur le tronc et la branche.