Qu'est-ce que SVN fait mieux que Git? [fermé]

Il ne fait aucun doute que la majorité des débats sur les outils de programmation se résume soit par choix personnel (par l'utilisateur), soit par emphase sur la conception , c'est-à- dire l'optimisation de la conception en fonction de cas d'utilisation particuliers (par le constructeur d'outils). Les éditeurs de texte sont probablement l'exemple le plus important: un codeur travaillant sous Windows au travail et codant à la maison avec Haskell sur un Mac, valorisant l'intégration multiplateforme et du compilateur et choisissant Emacs plutôt que TextMate , etc.

Il est moins courant qu'une technologie nouvellement introduite soit véritablement, manifestement supérieure aux options existantes.

Est-ce en fait le cas des systèmes de contrôle de version (VCS), en particulier des VCS centralisés ( CVS et SVN ) par rapport aux VCS distribués ( Git et Mercurial )?

J'ai utilisé SVN pendant environ cinq ans, et SVN est actuellement utilisé là où je travaille. Il y a un peu moins de trois ans, je suis passé à Git (et GitHub) pour tous mes projets personnels.

Je peux penser à un certain nombre d'avantages de Git par rapport à Subversion (et qui, pour la plupart, sont abstraits des avantages d'un VCS distribué par rapport à un VCS centralisé), mais je ne peux pas penser à un exemple contraire: une tâche (qui est pertinente et qui survient chez un programmeur habituel. flux de travail) que Subversion fait mieux que Git.

La seule conclusion que j'en ai tirée est que je n'ai pas de données - pas que Git est meilleur, etc.

Je suppose que de tels contre-exemples existent, d’où cette question.

Subversion est un référentiel central

Alors que beaucoup de gens voudront avoir des référentiels distribués pour les avantages évidents de la rapidité et de la multiplicité des copies, il existe des situations dans lesquelles un référentiel central est plus souhaitable. Par exemple, si vous avez un élément de code essentiel auquel vous ne voulez accéder à personne, vous ne voudrez probablement pas le placer sous Git. De nombreuses entreprises souhaitent garder leur code centralisé et (je suppose) tous les projets gouvernementaux (sérieux) sont sous des dépôts centraux.

La subversion est la sagesse conventionnelle

Cela revient à dire que de nombreuses personnes (en particulier les gestionnaires et les responsables) ont la méthode habituelle pour numéroter les versions et considèrent le développement comme une "ligne unique" au fil du temps, codé en dur dans leur cerveau. Sans vouloir vous offenser, la libéralité de Git n'est pas facile à avaler. Le premier chapitre de tout livre Git vous recommande d'effacer tous les idéaux conventionnels de votre esprit et de recommencer à zéro.

Subversion le fait dans un sens et rien d'autre

SVN est un système de contrôle de version. Il a une façon de faire son travail et tout le monde le fait de la même manière. Période. Cela facilite la transition vers / depuis SVN depuis / vers un autre VCS centralisé. Git n’est PAS même un pur VCS - c’est un système de fichiers, il existe de nombreuses topologies pour la configuration des référentiels dans différentes situations - et il n’existe aucune norme. Cela rend plus difficile de choisir un.

Les autres avantages sont:

• SVN supporte les répertoires vides
• SVN a un meilleur support Windows
• SVN peut extraire / cloner un sous-arbre
• SVN prend en charge le contrôle d'accès exclusif, svn lockce qui est utile pour les fichiers difficiles à fusionner.
• SVN prend en charge les fichiers binaires et les fichiers volumineux plus facilement (et ne nécessite pas de copier les anciennes versions partout).
• L'ajout d'un commit implique beaucoup moins d'étapes car il n'y a pas de push / push et vos changements locaux sont toujours implicitement rebasés svn update.

L'un des avantages de Subversion par rapport à Git peut être que Subversion permet uniquement d'extraire des sous-arbres. Avec Git, le référentiel entier est une unité, vous ne pouvez obtenir que tout ou rien. Avec le code modulaire, cela peut être très agréable comparé aux sous-modules Git. (Bien que les sous-modules Git aient aussi leur place, évidemment.)

Et un petit avantage minime: Subversion peut suivre les répertoires vides. Git suit le contenu du fichier, donc un répertoire sans fichier n'apparaîtra pas.

Je peux penser à trois. Premièrement, il est un peu plus facile de parler, en particulier pour les non-développeurs. Conceptuellement, il est beaucoup plus simple que les options DCVS . Deuxièmement, il y a la maturité, en particulier TortoiseSVN sous Windows. TortoiseHg rattrape vite cependant. Troisièmement, la nature de la bête - une simple image d'un système de fichiers où vous pouvez vérifier des éléments à partir de n'importe quel niveau de l'arborescence - peut s'avérer très pratique dans certains scénarios - comme la gestion de versions d'une variété de fichiers de configuration très différents sur des dizaines des serveurs sans dizaines de référentiels.

Cela ne veut pas dire que tous les développements ne sont pas transférés à Mercurial.

• Les référentiels SVN sont plus faciles à gérer du point de vue du gestionnaire et de l'administrateur ( ACL + méthodes d'authentification + hotcopy + miroirs + dumps)
• Les crochets SVN * sont plus faciles à implémenter et à supporter
• svn:external a plus de puissance et de flexibilité que les sous-modules
• Les arbres de référentiels basés sur des systèmes de fichiers sont plus faciles à utiliser que les référentiels monolithiques avec séparation logique uniquement
• SVN a plus d' outils client différents
• SVN a des interfaces Web utilisables par des tiers, bien meilleures que celles de Git
• SVN ne casse pas ton cerveau

J'ai écrit ceci dans un commentaire sur la réponse de quelqu'un d'autre, mais je suppose que cela mérite d'être une réponse en soi.

La configuration soigneusement choisie par mon entreprise pour SVN nécessite un verrouillage au niveau fichier pour modifier le contenu, et n'utilise jamais la fusion. En conséquence, plusieurs développeurs se disputent les verrous, ce qui peut constituer un goulot d'étranglement majeur et il n'y a jamais aucune chance qu'un conflit de fusion se produise.

SVN a définitivement un meilleur contrôle hiérarchique que Git. Dans ma migration de Skunkworks vers Git (demande de pardon plutôt que de permission), j'ai souvent terrifié mon manager en lui faisant croire qu'il n'existait aucun serveur central maître contrôlé par logiciel, auquel nous sommes tous esclaves.

Mes raisons:

• la maturité - à la fois le serveur et les outils (par exemple, TortoiseSVN)
• simplicité - sans étapes, un commit est un commit. Les DVCS tels que Git et Mercurial impliquent un commit, puis un push.
• traitement binaire - SVN gère les exécutables et les images binaires mieux que Git / Hg. Particulièrement utile avec les projets .NET car j'aime vérifier les outils liés à la construction dans le contrôle de source.
• numérotation - SVN a un schéma de numérotation de validation lisible, utilisant uniquement des chiffres - il est plus facile de suivre les numéros de révision. Git et Hg font cela très différemment.

J'apprécie le fait que vous recherchiez de bonnes informations, mais ce type de question invite simplement à dire: "Je pense que Git a tant de succès, et svn teh suxorz!" réponses.

J'ai personnellement essayé de trouver Git un peu trop pour ma petite équipe. Cela semblait idéal pour une grande équipe distribuée ou un groupe d'équipes dispersées géographiquement. Je comprends très bien les avantages de Git, mais le contrôle de la source, à mon avis, ne me garde pas éveillé la nuit.

Je suis un chasseur de cerfs et lorsque mes amis et moi-même sortons, ils sont armés jusqu'aux dents, hérissés de munitions et de matériel de haute technologie. Je me présente avec un seul fusil, sept balles et un couteau à couteau. Si j'ai besoin de plus de sept tours, je fais quelque chose de mal et je le fais aussi bien que quiconque.

Ce que j'essaie de dire, c'est que si vous êtes une petite équipe travaillant sur un projet de taille moyenne à petite et que vous connaissez déjà SVN, utilisez-le. C'est certainement mieux que CVS ou (frémir) SourceSafe , et cela ne me prend pas plus de cinq minutes pour mettre en place un référentiel. Git peut parfois être exagéré.

Tout cela est relatif et, comme dit maple_shaft, si l’on travaille pour vous, ne changez pas!

Mais si vous voulez vraiment quelque chose , je dirais que c'est peut-être mieux pour les concepteurs, les programmeurs Web et autres - cela gère un peu mieux les images et les fichiers binaires.

Facilité d'utilisation. Ce n'est pas vraiment le mérite de Subversion, mais bien celui de TortoiseSVN . TortoiseGit existe, mais il reste encore beaucoup de chemin à parcourir pour égaler TortoiseSVN.

Si vous demandiez ce que Git fait mieux que SVN, je répondrais GitHub . C'est drôle de voir à quel point les outils tiers font une telle différence.

Lorsque vous n'avez pas besoin de créer de branches et de fusionner , SVN (avec TortoiseSVN sous Windows) est très facile à comprendre et à utiliser. Git est trop complexe pour les cas simples, car il essaie de faciliter la création de branches / fusions.

(De nombreux petits projets ne doivent jamais créer de branches si ils sont bien gérés. Git est destiné aux cas complexes. La plupart de la documentation Git suppose donc que vous devez effectuer des opérations complexes telles que la création de branches et la fusion.)

Eh bien, mon grand-père pourrait utiliser SVN sur son ordinateur Windows XP, mais il aurait du mal à utiliser Git. Peut-être est-ce plus un accomplissement de TortoiseSVN sur TortoiseGit , mais je pense qu'il est plutôt lié au fait que Git est intrinsèquement plus puissant et donc plus complexe, et il serait inutile de stupide vers le bas au même niveau.

Maintenant, cela n'a pas vraiment d'importance pour mon grand-père, car il n'a pas encore programmé. Cependant, j’étais une fois dans une équipe où nos graphistes utilisaient également notre contrôle de source.

Et ce sont des gens qui s'attendent simplement à ce que leurs outils fonctionnent (moi aussi, mais j'ai une chance réaliste de les faire fonctionner en cas d'échec) et à être intuitifs. Mis à part le fait qu'il aurait été très difficile de les amener à s'entendre avec un DVCS , il y avait peu à gagner. Et comme il n'y avait que deux programmeurs dans l'équipe, il était logique que nous nous en tenions également à SVN.

Au travail, je ne pouvais pas passer des développeurs SVN à un DVCS pour deux raisons:

• Extractions partielles (comme seulement trois dossiers de profondeurs différentes dans l'arborescence du projet)
• Verrouillage de fichier (rapports au format binaire)

• Sens de la sécurité lors de l'exécution d'un 'svn commit'. Étant donné que les commits sont envoyés au serveur, je ne peux faire aucun bazar qui effacera mes modifications après leur validation. Dans git, les commits sont locaux, donc, jusqu'à ce que j'appuie, un 'rm -rf' errant et tout est fini.
• Les commits sont authentifiés. Par défaut, je peux dire que je commets en tant que personne.
• Moins de commandes à apprendre pour un usage quotidien. 'svn checkout', 'svn up' et 'svn commit' vous mèneront loin.
• Les caisses partagées fonctionnent beaucoup mieux. Lorsque vous vous engagez, il vous demande votre nom d'utilisateur / mot de passe, vous n'avez pas à vous souvenir de passer certains arguments en ligne de commande. Parfois, au travail, nous avons une machine partagée avec une extraction svn partagée de certains projets. Quelqu'un pourrait dire "Bob, tu peux regarder ça sur cette machine" et il le peut, et il peut valider ses modifications en tant qu'utilisateur, sans aucune erreur.
• Disposition du référentiel. Vous pouvez avoir un projet parapluie et des sous-projets et choisir ce qu'il faut vérifier quand.
• Les numéros de révision sont des entiers incrémentants.
• Conçu pour le flux de travail du référentiel central.

D'autres personnes ont posté de bonnes réponses, mais qu'en est-il des autorisations? En utilisant Subversion sur SSH, vous pouvez créer un compte distinct sur votre serveur pour SVN. Différents développeurs peuvent avoir différents accès à différentes parties du référentiel. GIT peut-il faire ça? Je suppose qu'il y a de la gitolite, mais elle ne me semble pas aussi souple ni robuste, et je ne connais personne qui l'utilise réellement.

La vitesse. Il faut parfois 10 ou 15 minutes pour cloner un grand référentiel Git, tandis qu’un référentiel de taille similaire prend environ deux minutes à vérifier.

Je poste ceci comme une réponse plutôt que comme un commentaire.

Je reconnais que les DVCS sont tout à fait dans la tendance en ce moment, mais je vais essayer de dire pourquoi.

Les systèmes DVCS sont meilleurs parce que, comme beaucoup de gens l’ont dit, "c’est ainsi que nous aurions dû travailler depuis le début". C'est vrai, vous pouvez faire avec un DVCS ce que vous utilisiez avec SVN, donc d'une manière qui rend SVN obsolète.

Cependant, tous les projets logiciels ne sont pas aussi performants qu’ils obtiennent:

• Les projets à long terme ont beaucoup profité de DVCS, car ils utilisent moins de temps système, permettent une meilleure gestion (branchement, etc.) et sont largement pris en charge par des hôtes comme Google Code et github.

• Ces projets ne sont pas les seuls, il existe d'autres types de projets en cours de développement dans des entreprises sans aucune aide du monde extérieur ou d'Internet: tout se fait en interne, souvent à court terme. Un bon exemple: un jeu vidéo. Le code évolue rapidement.

Dans ce dernier cas, les développeurs n'ont pas vraiment besoin de branches ou de fonctionnalités sophistiquées que DVCS peut offrir, ils souhaitent simplement partager le code source et les actifs. Le code qu'ils créent n'est pas susceptible d'être réutilisé, car il y a une date limite. Ils s'appuient sur SVN plutôt que sur un DVCS pour plusieurs raisons:

• Les développeurs ont des machines appartenant à l'entreprise et cela pourrait changer rapidement. Configurer un repo est une perte de temps.
• Si ces personnes ne disposent pas de leur propre machine, elles risquent moins de travailler sur le même code source / la même partie du projet. Plus un pour les données centralisées.
• Les vitesses de réseau et les grosses sommes d'argent permettent l'utilisation d'un serveur centralisé qui gère tout le SVN, c'est une mauvaise pratique mais des sauvegardes sont effectuées, etc.
• SVN est simplement plus simple à utiliser, même si ce n’est pas le bon sens: synchroniser des fichiers sur des pairs sans redondance n’est pas un problème simple, et "faire les choses correctement" ne peut tout simplement pas arriver à temps si vous voulez toujours que ce soit parfait.

Pensez à la machine de l'industrie du jeu et à la façon dont SVN permet de gagner du temps. les gens communiquent beaucoup plus sur ces projets parce que les jeux concernent la programmation répétitive et le code adaptatif: rien n’est difficile à coder, il faut le faire correctement, dès que possible. Les programmeurs sont embauchés, ils codent leur partie, la compilent, la testent un peu, s’engagent, c’est fait, les testeurs de jeux s’occuperont du reste.

Les DVCS sont conçus pour Internet et pour des projets très complexes. Les SVN sont destinés aux projets d’équipe restreints, à court terme et à court terme. Vous n'avez pas besoin d'apprendre beaucoup de SVN, c'est presque un FTP avec un diff idiot.

Subversion et Git encouragent tous deux des approches particulières (et très différentes) de développement et de collaboration. Certaines organisations tireront davantage parti de Git, tandis que d'autres tireront davantage profit de Subversion, en fonction de leur organisation et de leur culture.

Git et Mercurial sont tous deux excellents pour les équipes réparties et mal organisées de programmeurs professionnels extrêmement compétents. Ces deux outils DVCS populaires encouragent les petits référentiels, la réutilisation entre développeurs se faisant par le biais de bibliothèques publiées avec des interfaces (relativement) stables.

Subversion, en revanche, encourage une structure de gestion plus centralisée et étroitement couplée, avec davantage de communication entre les développeurs et un plus grand degré de contrôle organisationnel sur les activités de développement quotidiennes. Au sein de ces équipes organisées de manière plus compacte, la réutilisation entre développeurs a généralement lieu via des bibliothèques non publiées avec des interfaces (relativement) instables. TortoiseSVN permet également à Subversion de prendre en charge des équipes multidisciplinaires composées de membres qui ne sont pas des programmeurs professionnels (ingénieurs en systèmes, ingénieurs en algorithmes ou autres spécialistes).

Si votre équipe est distribuée, avec des membres travaillant à domicile ou provenant de nombreux sites internationaux différents, ou s’ils préfèrent travailler seuls et en silence, avec peu de communication en face à face, un DVCS comme Git ou Mercurial sera un bon choix. ajustement culturel.

Si, en revanche, votre équipe est située sur un site unique, avec une approche active du développement en "équipe" et de nombreuses communications en face-à-face, avec un "buzz" en l'air, SVN peut être un élément clé. meilleur ajustement culturel, en particulier si vous avez beaucoup d'équipes multidisciplinaires.

Bien sûr, il est possible de configurer Git et Hg (puissants et flexibles) pour qu’ils fassent à peu près tout ce que vous voulez, mais c’est définitivement plus de travail et ils sont nettement plus difficiles à utiliser, en particulier pour les membres de l’équipe qui ne serait naturellement pas enclin à utiliser quelque forme de contrôle de version que ce soit.

Enfin, je trouve également que le partage de fonctionnalités utilisant le développement de bibliothèques "à chaud" sous Svn (avec une approche basée sur des tests et sur des tests) permet un rythme de développement coordonné difficile à atteindre avec une équipe plus distribuée et faiblement couplée.

Vous trouverez ci-dessous les deux raisons pour lesquelles je reste avec SVN.

1. La courbe d'apprentissage. SVN est plus facile que Git, même la configuration (serveur ou client), la convivialité et les commandes.
2. De meilleurs packages de serveurs comme Subversion Edge , VisualSVN , uberSVN, etc.

Il existe actuellement deux grandes tendances dans le contrôle de version. Distribution et intégration .

Git est excellent en décentralisation.

SVN a construit de nombreux outils qui s’y intègrent. Il est courant de configurer votre serveur SVN de manière à ce que, lorsque vous enregistrez une correction, vous mentionnez le numéro de bogue dans le commentaire d’archivage. Il définit automatiquement cela, mais dans un état "en cours de test", et alerte le testeur assigné dont il a besoin. Regarde ça. Ensuite, vous pouvez marquer une version et obtenir une liste de tous les bogues corrigés dans cette version.

Les outils qui font cela avec SVN sont matures et utilisés tous les jours.

Dans Subversion, vous pouvez modifier les messages de journal (également appelés "messages de validation") une fois la validation effectuée et envoyée. Pour la plupart des applications pratiques, cela est impossible par conception dans les systèmes décentralisés, y compris git. Bien sûr, en git, vous pouvez faire "git commit --amend", mais cela ne vous aide pas après que votre commit ait été poussé ailleurs. Dans SVN, lorsque vous modifiez le message de journal, vous le créez dans le référentiel central que tout le monde partage, afin que tout le monde obtienne la modification sans changer l'identifiant de la révision.

La modification des messages de journal après coup est souvent très utile. En plus de réparer une erreur ou une omission dans un message de journal, il vous permet de faire des choses comme mettre à jour un message de journal pour faire référence à un futur. validation (telle qu'une révision qui corrige un bogue ou termine le travail introduit dans la révision actuelle). .

Soit dit en passant, il n'y a pas de danger de perdre des informations. Les points d'ancrage pre-revprop-change et post-revprop-change peuvent enregistrer l'historique des anciens messages si vous êtes vraiment inquiet, ou envoyer des e-mails avec le diff de message de journal (c'est plus courant, en fait), de sorte qu'il y piste d'audit.