Raisons spécifiques pour continuer à utiliser Subversion? [fermé]

22

Dans l'état actuel des choses, cette question ne convient pas à notre format de questions / réponses. Nous nous attendons à ce que les réponses soient étayées par des faits, des références ou une expertise, mais cette question suscitera probablement un débat, des arguments, des sondages ou une discussion approfondie. Si vous pensez que cette question peut être améliorée et éventuellement rouverte, visitez le centre d'aide pour obtenir des conseils.

Fermé il y a 7 ans .

Je souhaite choisir un système de contrôle de version pour mon entreprise. Jusqu'à présent, je sais que j'ai Git, Subversion et Mercurial.

Ces jours-ci, je vois que Git est le plus utilisé, donc je me demande: y aurait-il une raison spécifique pour continuer à utiliser Subversion, ou devrais-je aller directement à Git?

version-control git svn

— user1179459
source

36

Ils travaillent tous les deux. L'important est de savoir s'ils répondront à vos besoins, ce que vous ne nous avez pas dit.

— Matthew Flynn

6

Voir Pourquoi utiliser SVN? Y a-t-il des pros cachés (sur GIT / Mercurial / Bazaar)? sur Stack Overflow.

— detly

11

Sur quel argument excluez-vous Mercurial?

— mouviciel

8

-1 pour la formulation subjective (à mon humble avis) et "Ces jours-là, je vois que Git est le plus utilisé" - citation nécessaire. Git est extrêmement courant dans le monde open source, mais dans l'espace d'entreprise, il est beaucoup plus rare. Corps aime vraiment l'idée d'un référentiel unique, central et faisant autorité et est très lent à changer. Dans l'espace d'entreprise, vous êtes plus susceptible de voir un bon vieux CVS que SVN même, sans parler d'un DVCS.

— Keith

4

@RobinWinslow - SVN est différent de Git. Mieux adapté à certaines circonstances et pire adapté à d'autres. Personnellement, je préfère le DVCS en général et vous préférez évidemment Git, mais les deux sont des opinions subjectives. Ils ne sont pas sans valeur, mais ils n'appartiennent pas à un site comme celui-ci.

— Keith

46

SVN n'est pas mort du tout. Il est encore très largement utilisé et ne va pas bientôt. SVN est beaucoup plus simple à utiliser que le contrôle de version distribué, surtout si vous n'exécutez pas réellement un projet distribué qui nécessite un contrôle de version distribué.

Si vous n'avez qu'un seul référentiel central (c'est tout ce dont votre entreprise aura besoin s'ils sont encore assez petits pour s'en sortir sans contrôle de source jusqu'à présent), il est beaucoup plus simple d'utiliser SVN pour interagir avec lui. Par exemple, avec SVN, vous pouvez extraire les modifications du référentiel ou y valider vos modifications locales, en une seule opération, tandis que HG et Git nécessitent deux ou trois étapes pour effectuer le travail équivalent.

Et avec les révisions récentes, SVN a résolu un grand nombre de problèmes de performances qui faisaient que les gens préféraient HG et Git. C'est beaucoup plus rapide maintenant qu'il y a quelques années, et à ce stade, il n'y a vraiment aucune bonne raison de considérer HG ou Git pour votre projet, sauf si vous avez réellement besoin des fonctionnalités avancées du contrôle de version distribué.

— Mason Wheeler
source

16

Je ne suis pas entièrement d'accord avec votre estimation, mais j'aimerais ajouter un point important en faveur de SVN: Beaucoup de gens dans l'industrie sont à l'aise avec SVN mais ne connaissent pas assez de Git pour travailler confortablement avec lui. Si toute votre équipe est habituée à SVN, le passage à Git peut coûter cher. (L'inverse peut aussi être vrai, bien sûr).

— Joachim Sauer

8

Je voterais cette douzaine de fois si je le pouvais. Beaucoup de gens vont avec la mode, mais ne pensent pas vraiment pourquoi ils auraient besoin d'un contrôle de source distribué.

— Euphoric

21

@ Euphoric: Je sais précisément pourquoi je veux toujours un contrôle de source distribué sur chaque projet. Il a pour effet secondaire important de rendre les branchements et les fusions simples, évidents et fiables. Subversion est toujours enlisé dans les cas d'angle avec branchement parce que le modèle de base qu'il a choisi le rend simplement plus compliqué.

— Jan Hudec

18

Le contrôle de version distribué n'est pas une «mode». Il s'agit d'une évolution du contrôle des sources, tout comme le contrôle des versions simultanées était une évolution par rapport au paradigme de verrouillage de fichiers.

— JesperE

6

@MichaelBorgwardt, je l'ai fait plusieurs fois. C'est beaucoup plus facile qu'avec la subversion, le fait que tout soit local aide beaucoup, il n'est pas nécessaire d'expliquer l'interaction "client" et "serveur". Le flux de travail dans git ou hg est beaucoup plus naturel et intuitif (si vous vous éloignez des éléments délicats comme l'édition de l'historique).

— SK-logic

19

L'outillage client n'a pas encore été mentionné. Vous pouvez certainement tout faire avec un script de ligne de commande, mais l'intégration de l'interface graphique peut être un véritable gain de productivité.

Nous travaillons principalement avec Visual Studio; l'intégration dans l'IDE est nettement meilleure avec SVN qu'avec Git en ce moment. Cela pourrait changer à l'avenir, mais je peserais certainement cela dans votre décision tout autant que les fonctions de contrôle de version.

Comme tout le reste, un système de contrôle de version n'est pas un objectif en soi, juste un outil pour vous emmener où vous allez. Choisissez celui qui vous y mènera le plus rapidement en fonction de votre situation.

— njr101
source

C'est un bon point. Je pense que l'une des raisons pour lesquelles les gens préfèrent Git sur SVN est que Git a un meilleur outil CLI. Mais cela peut être compensé avec une bonne interface graphique SVN tierce, comme TortoiseSVN sous Windows.

— Euphoric

2

C'est l'une des raisons pour lesquelles nous avons opté pour Mercurial (et TortoiseHg) sur Git. Les avantages du contrôle de version distribué et des outils décents et de l'intégration IDE.

— HappyCat

15

Je suis fan de Git. Récemment, j'ai dû admettre que l'un des inconvénients de Git est qu'il identifie les versions avec des hachages contrairement aux numéros de version de svn. Le numéro de version peut être plus facilement transmis par téléphone ou quelque chose comme ça.

Et c'est le seul pro que j'imagine. Si vous voulez vraiment compter sur cette fonctionnalité, vous pouvez l’avoir dans un VCS Bazaar distribué et / ou centralisé . Dans Git, il existe des balises qui peuvent servir à cette fin.

Quoi qu'il en soit, je ne pouvais tout simplement pas imaginer développer sans changement de branche rapide et stockage. Ces deux fonctionnalités à elles seules ont battu SVN, où, pour autant que je me souvienne, la même tâche nécessitait de créer et d'extraire un arbre entier dans des répertoires séparés pour atteindre le même objectif.

Ces soi-disant «fonctionnalités avancées du contrôle de version distribué» viennent avec le temps, et vous n'avez pas à les apprendre au tout début. N'ayez pas peur d'eux. Ils sont là pour vous aider, pas pour vous gêner. Et il n'y a aucun problème à mettre en place un référentiel central pour un DVCS.

— Rajish
source

1

C'est en fait théorique, git n'a besoin que d'une partie suffisamment grande du hachage pour pouvoir lever l'ambiguïté, généralement quelque chose ~ 6 caractères suffit, pas tout le hachage.

— TC1

2

En pratique, vous ne passez jamais le hash git autour. Vous pouvez utiliser n'importe quel préfixe unique du hachage, qui est généralement composé de 6 à 7 caractères.

— JesperE

1

@JesperE: Oui, mais les numéros de version de SVN augmentent séquentiellement au fil du temps, tandis que les hachages de Git, même si vous les abrégez, pourraient tout aussi bien être aléatoires.

— Keith Thompson

2

Avec SVN, vous pouvez facilement extraire des parties d'un référentiel jusqu'au niveau du dossier, tandis qu'avec git, vous obtenez l'ensemble du référentiel, y compris tout l'historique.

Selon la situation, cela peut présenter certains avantages pour SVN

(cela présente également de gros inconvénients tels que les ordures ".svn" cachées tout au long de votre arborescence de dossiers).

— Richard Nichols
source

3

note: pas de déchets .svn depuis la v1.7 - son maintenant tous stockés dans un seul emplacement.

— gbjbaanb

Ce n'est pas correct - git vous permet d'extraire uniquement les fichiers, sans l'historique, et il est également possible d'extraire uniquement des parties des fichiers repo - single si vous le souhaitez. C'est un peu plus complexe que svn, mais la capacité est là.

— Benubird

2

"Si vous avez une tâche qui peut être effectuée en six heures, il est préférable d'écrire un outil qui le fait en 20 minutes, même lorsque la création de l'outil prend six heures?"

Le contrôle de version distribuée est une bête différente à affronter. Cela nécessite un apprentissage substantiel pour chaque développeur. Si vous avez le tampon pour accueillir le processus d'apprentissage pour chaque développeur, vous devez passer à un bon système de contrôle de version distribué. Une fois la phase d'apprentissage terminée, le contrôle de version distribué est bien meilleur que le contrôle de version centralisé.

Le contrôle de version distribué semble être une éventualité. Il est là pour rester très longtemps, il vaut mieux s'y adapter tôt que tard. Je me souviens de la même discussion lorsque SVN était nouveau et que les gens étaient habitués à CVS, de nombreux arguments ont été avancés pour ne pas utiliser SVN, mais finalement SVN est devenu le système de contrôle de version le plus populaire.

Si l'entreprise est bien établie avec beaucoup de code source dans le système de contrôle de version existant, le passage à un nouveau système est une tâche importante, mais si l'entreprise est petite ou en démarrage, le passage à un nouveau contrôle de version est très facile. Mais si vous vous en tenez à un contrôle de version plus ancien (dans une nouvelle configuration), vous rencontrerez un goulot d'étranglement quelque part à l'avenir où vous devrez éventuellement planifier une migration de contrôle de version de toute façon.

J'ai vu beaucoup de commentaires pro SVN, mais tous ont tendance à être de la nature "SVN n'est pas mauvais" plutôt que "SVN est meilleur". Je vous recommande donc fortement de choisir un contrôle de version distribué (tel que Git) pour votre projet.

EDIT Avantages de GIT sur SVN

~~Aucun serveur dédié requis~~ En fait, les deux peuvent être utilisés sans serveur.
Peut poursuivre le développement même sans connexion réseau.
La gestion des succursales est beaucoup plus facile.
Meilleur support des outils CI tels que Bamboo

Quelqu'un a mentionné l'outillage (pour Visual Studio) comme une raison de s'en tenir à SVN. http://gitscc.codeplex.com/ fournit la prise en charge GIT pour Visual Studio.

— Apeirogon Prime
source

6

SVN ne Manipulez les fichiers binaires mieux que Git ou Hg.

— Fake Name

2

"Vous rencontrerez un goulot d'étranglement quelque part à l'avenir où vous devrez éventuellement planifier une migration de contrôle de version ..." Désolé, je ne peux pas convenir que c'est une bonne raison de faire le pas aujourd'hui. J'ai travaillé sur de nombreux projets où cette approche conduit à rendre les choses plus compliquées qu'elles ne devraient l'être et le projet est annulé bien avant qu'il ne puisse jamais profiter de ces avantages futurs. Parfois assez bon, c'est assez bon. Restez sur YAGNI et prenez ce qui fait le travail aujourd'hui. Il y aura assez de temps pour s'inquiéter des migrations plus tard. Au moins, vous aurez toujours un projet.

— njr101

2

Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.Je suis totalement en désaccord avec cela. Il peut avoir des avantages perçus dans certaines circonstances, mais quelque chose d'aussi simple que le numéro de version dans svn étant lisible par l'homme est un avantage massif dans de nombreuses organisations.

— TZHX le

1

@apeirogon - Tout se résume à ce que vous allez mettre dans le référentiel. Le HEAD seul de l'un des principaux référentiels avec lesquels je travaille est de 11,1 Go! Si je l'avais dans un dépôt Git / bzr / hg, cela prendrait probablement plus de 100 Go.

— Fake Name

1

Bien sûr, cela est dû au fait que ce dépôt particulier est plein de fichiers PCB et de modèles 3D, qui sont tous au format binaire et peu économe en espace. La recommandation ici (Electronics.SE, par exemple pour les personnes stockant des fichiers PCB ddesign, etc.) est très différente si c'est pour quelqu'un qui stocke le code source.

— Fake Name

1

y aurait-il une raison spécifique d'utiliser Subversion ces jours-là

En dehors de la prise en charge des outils dans les IDE (que je n'utilise pas) - pas vraiment, non. Bien sûr, SVN est peut-être plus familier, mais c'est à peu près la seule raison, et j'ai trouvé Hg et Git très faciles (et très rapides) à apprendre.

Oui, il y a tous ces guides complexes qui décrivent comment Git est trivial une fois que vous comprenez que les branches ne sont que des endofoncteurs homéomorphes cartographiant les sous-variétés d'un espace de Hilbert. ¹

Je ne comprends pas ça. Mais tu sais quoi? Ça n'a pas d'importance. Vous n'avez pas besoin de connaître tout cela pour utiliser Git.

Pour la plupart, Git et Hg sont faciles à utiliser et ils ont des avantages définitifs sur SVN. L'éléphant dans la pièce est bien sûr ramifié: les branches fonctionnent juste en Git et Hg. En revanche, dans SVN, ils sont au mieux douloureux et au pire cassés (fusion de plusieurs têtes).

Bien sûr, vous pouvez toujours utiliser SVN. Vous pouvez également toujours utiliser Windows XP. Cependant, la majorité des utilisateurs qui ont essayé les deux conviennent que l'une des alternatives est largement supérieure.

¹ Oui, je comprends que c'est une blague. Je pense.

— Konrad Rudolph
source

Un tutoriel Git avec des endofoncteurs homéomorphes cartographiant les sous-variétés d'un espace de Hilbert? J'ai besoin de lire ça! Mais cela ne s'applique-t-il pas plutôt à Darcs, qui est écrit en Haskell (auquel je pense que l' endofoncteur fait référence) et inspiré par la mécanique quantique (d'où l'espace Hilbert )? Je ne vois vraiment pas ce que Git et HG ont à voir avec ces choses.

— leftaroundabout

@leftaroundabout C'est une blague. La description n'est même pas exacte (pour autant que je sache). C'est un riff sur les nombreux tutoriels qui commencent par "les branches git sont faciles une fois que vous vous rendez compte que ..." et puis il y a une métaphore complexe spécifique au domaine après.

— Konrad Rudolph

1

Avez-vous déjà considéré que tous ces tutoriels trop compliqués existent pour une raison? Et à quoi ça sert de toute façon? Je n'ai jamais compris l'obsession de la foule DVCS avec la ramification, puis la réintégration d'une branche pour chaque petite chose. Cela m'a toujours semblé être une solution à la recherche d'un problème. Réintégrer une branche dans SVN est difficile car c'est une chose vraiment stupide et conceptuellement erronée à faire en premier lieu , et je ne trouve vraiment aucun argument qui se résume à "notre produit rend la mauvaise chose tellement plus facile" très convaincant.

— Mason Wheeler

1

Quant à travailler sur plusieurs changements en parallèle, j'avoue que c'est un peu pénible, mais la bonne solution est le rayonnage, qui est prévu pour la prochaine version de SVN. Et la plupart du temps, si vous travaillez sur plusieurs changements en même temps (et surtout si vous le faites de manière cohérente!), C'est la preuve d'un problème plus large qui devrait être résolu au niveau de l'organisation, pas activé avec de nouveaux outils. (Voir ci-dessus, «notre produit facilite beaucoup la mauvaise chose» et l'article classique de Joel sur le changement de tâche humaine.)

— Mason Wheeler

3

@KonradRudolph La fusion des branches dans le tronc fonctionne très bien dans les dernières versions de SVN. Cela s'améliore régulièrement depuis plusieurs années, là où c'est très bien maintenant.

— Adam Bruss