Qu'est-ce que SVN fait mieux que Git?
Il ne fait aucun doute que la majorité des débats sur les outils de programmation distillent soit le choix personnel (par l'utilisateur) ou l'accent sur la conception , c'est-à-dire , optimisant la conception en fonction des cas d'utilisation particuliers (par le constructeur d'outils). Les éditeurs de texte sont probablement l'exemple le plus important - un codeur qui travaille sur Windows au travail et code en Haskell sur le Mac à la maison, valorise l'intégration multiplateforme et compilateur et choisit donc Emacs sur 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 avec les systèmes de contrôle de version (VCS), en particulier centralisés VCS ( CVS et SVN ) contre distribué VCS (- 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 aux avantages de distribué sur VCS centralisé), mais je ne peux pas penser à un contre-exemple - une tâche (qui est pertinente et se pose dans un programmeur habituel workflow) 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
Bien que de nombreuses personnes souhaitent disposer de référentiels distribués pour les avantages évidents de la vitesse et de plusieurs copies, il existe des situations où un référentiel central est plus souhaitable. Par exemple, si vous avez un morceau de code critique auquel vous ne voulez pas que quiconque accède, vous ne voudrez probablement pas le mettre sous Git. De nombreuses entreprises veulent garder leur code centralisé, et (je suppose) tous les projets gouvernementaux (sérieux) sont sous des dépôts centraux.
Subversion est la sagesse conventionnelle
Cela signifie que de nombreuses personnes (en particulier les managers et les patrons) ont la manière habituelle de numéroter les versions et de voir le développement comme une "ligne unique" dans le temps codé en dur dans leur cerveau. Pas d'offense, mais la libéralité de Git n'est pas facile à avaler. Le premier chapitre de tout livre Git vous dit de supprimer 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 de/vers SVN de/vers d'autres VCS centralisés. Git n'est PAS même un pur VCS - c'est un système de fichiers, a de nombreuses topologies pour configurer des référentiels dans différentes situations - et il n'y a pas de norme. Cela rend plus difficile d'en choisir un.
Les autres avantages sont:
SVN prend en charge les répertoires videsSVN a un meilleur support WindowsSVN peut extraire/cloner un sous-arbre- SVN prend en charge le contrôle d'accès exclusif
svn lockqui 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 pull/Push et vos modifications locales sont toujours implicitement rebasées sur
svn update.
Un avantage de Subversion sur Git peut être que Subversion permet de vérifier uniquement les sous-arbres. Avec Git, l'ensemble du référentiel est une unité, vous ne pouvez obtenir que tout ou rien. Avec du code modulaire, cela peut être assez agréable par rapport aux sous-modules Git. (Bien que les sous-modules Git aient aussi leur place, évidemment.)
Et un tout petit avantage: Subversion peut suivre les répertoires vides. Git suit le contenu des fichiers, donc un répertoire sans aucun fichier n'apparaîtra pas.
Je peux penser à trois. Tout d'abord, il est un peu plus facile à gérer, surtout pour les non développeurs. Conceptuellement, c'est beaucoup plus simple que les options DCVS . La deuxième est la maturité, en particulier TortoiseSVN sous Windows. TortoiseHg rattrape rapidement cependant. Troisièmement, la nature de la bête - juste une image d'un système de fichiers où vous pouvez vérifier les choses à n'importe quel niveau de l'arborescence - peut être très pratique dans certains scénarios - comme le versionnage d'une variété de fichiers de configuration très différents sur des dizaines de serveurs sans des dizaines de référentiels.
Cela ne veut pas dire que nous ne déplaçons pas tout le développement vers Mercurial.
- Les référentiels SVN sont plus faciles à gérer du point de vue d'un gestionnaire et d'un administrateur ( ACL + méthodes d'authentification + hotcopy + mirrors + dumps)
- Les crochets SVN * sont plus faciles à mettre en œuvre et à prendre en charge
svn:externala plus de puissance et de flexibilité que les sous-modules- Les arborescences 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 différents outils clients
- SVN possède des interfaces Web utilisables par des tiers, bien meilleures que celles de Git
- SVN ne vous brise pas le cerveau
J'ai écrit cela comme 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 de mon entreprise pour SVN nécessite un verrouillage au niveau des fichiers pour modifier le contenu et n'utilise jamais la fusion. En conséquence, plusieurs développeurs se disputent les verrous, et cela peut être un goulot d'étranglement majeur, et il n'y a jamais de chance de conflit de fusion.
SVN fait certainement un contrôle de gestion descendant mieux que Git. Dans ma migration de skunkworks vers Git (demandant pardon plutôt que permission), j'ai terrifié mon manager à plusieurs reprises avec l'idée qu'il n'y a pas de logiciel - serveur central de contrôle maître renforcé dont nous sommes tous les esclaves.
J'apprécie que vous recherchiez de bonnes informations, mais ce genre de question invite simplement: "Je pense que Git est tellement gagnant, et svn teh suxorz!" réponses.
J'ai essayé et trouvé personnellement Git un peu trop pour ma petite équipe. Il semblait que ce serait formidable pour une grande équipe distribuée ou un groupe d'équipes géographiquement dispersées. Je comprends très bien les avantages de Git, mais le contrôle des sources à mon avis n'est pas quelque chose qui me tient debout la nuit.
Je suis un chasseur de cerfs, et quand mes amis et moi sortons, ils sont armés jusqu'aux dents, hérissés de munitions et d'équipements de haute technologie. Je me présente avec un seul fusil, sept balles et un couteau mâle. Si j'ai besoin de plus de sept tours, je fais quelque chose de mal et je fais aussi bien que n'importe qui d'autre.
Le point que j'essaye de faire est que si vous êtes une petite équipe travaillant sur un projet moyen à petit et que vous êtes déjà familier avec SVN, utilisez-le. C'est certainement mieux que CVS ou (shudder) SourceSafe , et cela ne me prend pas plus de cinq minutes pour configurer un référentiel. Git peut parfois être exagéré.
Mes raisons:
- maturité - à la fois le serveur et les outils (par exemple TortoiseSVN)
- simplicité - moins d'étapes impliquées, un commit est un commit. Les DVCS tels que Git et Mercurial impliquent commit, puis Push.
- gestion binaire - SVN gère mieux les exécutables binaires et les images 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 code source.
- numérotation - SVN a un schéma de numérotation de validation lisible, utilisant uniquement des chiffres - plus facile à suivre les numéros de révision. Git et Hg font cela très différemment.
Tout cela est relatif, et comme l'a 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 - il gère images et binaires fichiers un peu mieux.
Convivialité. Ce n'est pas vraiment le mérite de Subversion mais plutôt TortoiseSVN . TortoiseGit existe, mais il reste encore un long chemin à parcourir pour correspondre à TortoiseSVN.
Si vous demandiez ce que Git fait mieux que SVN, je répondrais GitHub . C'est amusant de voir à quel point les outils tiers font une énorme différence.
Lorsque vous n'avez pas besoin de créer des 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 rendre la branchement/fusion facile.
(Beaucoup de petits projets n'ont jamais à se ramifier s'ils sont bien gérés. Git est destiné aux cas complexes; par conséquent, la plupart de la documentation Git suppose que vous devez effectuer des opérations complexes comme la ramification et la fusion.)
Eh bien, mon grand-père pourrait utiliser SVN sur son ordinateur Windows XP, mais il aurait du mal à utiliser Git. C'est peut-être plus un accomplissement de TortoiseSVN sur TortoiseGit , mais je pense que c'est plutôt lié au fait que Git est intrinsèquement plus puissant et donc plus complexe, et ce serait inutile de le baisser au même niveau.
Maintenant, cela n'a plus vraiment d'importance pour mon grand-père, car il n'a fait aucune programmation ces derniers temps. 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 d'être intuitifs. Mis à part le fait que cela aurait été un gros effort de les faire s'entendre avec un DVCS , il y avait peu à gagner. Et avec seulement deux programmeurs dans l'équipe, il était logique pour nous de nous en tenir à SVN.
Au travail, je ne pouvais pas basculer les développeurs de SVN vers n'importe quel DVCS pour deux raisons:
- Extractions partielles (comme seulement trois dossiers de différentes profondeurs dans l'arborescence du projet)
- Verrouillage de fichiers (rapports au format binaire)
- Sentiment de sécurité lors d'un "svn commit". Étant donné que les validations sont envoyées au serveur, il n'y a aucune erreur possible que je puisse faire qui effacera mes modifications après leur validation. Dans git, les commits sont locaux, donc jusqu'à ce que je pousse, un "rm -rf" errant et c'est fini.
- Les validations sont authentifiées. Par défaut, dans git, je peux dire que je m'engage en tant que personne.
- Moins de commandes à apprendre pour un usage quotidien. 'svn checkout', 'svn up' et 'svn commit' vous mèneront assez loin.
- Les extractions partagées fonctionnent beaucoup mieux. Lorsque vous allez valider, il vous demande votre nom d'utilisateur/mot de passe, vous n'avez pas à vous rappeler de passer certains arguments de ligne de commande. Parfois, au travail, nous avons une machine partagée avec une extraction svn partagée d'un projet. Quelqu'un pourrait dire "Bob pouvez-vous regarder cela sur cette machine" et il le peut, et il peut valider ses modifications en tant qu'utilisateur sans aucun problème.
- Disposition du référentiel. Vous pouvez avoir un projet cadre et des sous-projets et choisir quoi vérifier quand.
- Les numéros de révision incrémentent des entiers.
- Conçu pour le flux de travail du référentiel central.
D'autres personnes ont publié de très bonnes réponses, mais qu'en est-il des autorisations? En utilisant Subversion sur SSH, vous pouvez créer un compte séparé sur votre serveur pour SVN. Différents développeurs peuvent avoir un accès différent à 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 flexible ou 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 Subversion de taille similaire prend quelques minutes pour être extrait.
Subversion et Git encouragent tous deux des approches particulières (et très différentes) du développement et de la collaboration. Certaines organisations tireront davantage parti de Git et d'autres de Subversion, en fonction de leur organisation et de leur culture.
Git et Mercurial sont tous deux excellents pour les équipes réparties et peu organisées de programmeurs professionnels hautement compétents. Ces deux outils DVCS populaires encouragent les petits référentiels, la réutilisation entre développeurs ayant lieu via des bibliothèques publiées avec des interfaces (relativement) stables.
Subversion, d'autre part, encourage une structure de gestion plus centralisée et étroitement couplée, avec plus 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 tendance à se produire via des bibliothèques non publiées avec des interfaces (relativement) instables. TortoiseSVN permet également à Subversion de soutenir des équipes multidisciplinaires avec des membres qui ne sont pas des programmeurs professionnels (par exemple, ingénieurs système, ingénieurs algorithmes ou autres spécialistes du domaine).
Si votre équipe est répartie, avec des membres travaillant à domicile ou à partir de nombreux sites internationaux différents, ou s'ils préfèrent travailler seuls et en silence, avec peu de communication en face à face, alors un DVCS comme Git ou Mercurial sera un bon ajustement culturel.
Si, d'autre part, votre équipe est située sur un seul site, avec une approche de développement active en "équipe" et beaucoup de communication en face à face, avec un "buzz" dans l'air, alors SVN peut être un meilleure adéquation culturelle, surtout si vous avez beaucoup d'équipes interdisciplinaires.
Bien sûr, il est possible de configurer Git et Hg (puissants et flexibles comme ils sont) pour faire à peu près tout ce que vous voulez, mais c'est certainement plus de travail, et ils sont certainement plus difficiles à utiliser, en particulier pour les membres de l'équipe qui ne serait naturellement pas enclin à utiliser n'importe quel forme de contrôle de version que ce soit.
Enfin, je trouve également que le partage de fonctionnalités en utilisant le développement de bibliothèque "à chaud" sous Svn (avec CI et une approche pilotée par les tests) permet un rythme de développement coordonné qui est difficile à atteindre avec une équipe plus distribuée et faiblement couplée.
Je poste cela comme une réponse plutôt qu'un commentaire.
J'admets que le DVCS est tout à fait dans la tendance en ce moment, mais je vais essayer de dire pourquoi.
Le DVCS est meilleur 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 faisiez avec SVN, donc d'une manière qui rend SVN obsolète.
Cependant, tous les projets logiciels ne sont pas aussi bons qu'ils le sont:
Le projet à long terme a beaucoup bénéficié du DVCS, car il utilise moins de temps système, permet une gestion bien meilleure (branchement, etc.) et est 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 qui se développent dans des entreprises sans aucune assistance du monde extérieur ou d'Internet: tout se fait en interne, et 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 fonctions de branchement ou sophistiquées que DVCS peut offrir, ils veulent juste partager le code source et les ressources. Le code qu'ils créent n'est pas susceptible d'être réutilisé, car il y a un délai. Ils s'appuient sur SVN plutôt que sur DVCS pour plusieurs raisons:
- Les développeurs ont des machines qui appartiennent à l'entreprise, et cela pourrait changer rapidement. La configuration d'un dépôt est une perte de temps.
- Si ces gars-là n'ont pas leur propre machine, ils sont moins susceptibles de travailler sur le même code source/partie du projet. Plus un pour les données centralisées.
- les vitesses de réseau et le gros argent permettent l'utilisation d'un serveur centralisé qui gère tout SVN, c'est une mauvaise pratique mais des sauvegardes sont faites etc.
- SVN est juste plus simple à utiliser, même si c'est dans le mauvais sens: synchroniser des fichiers sur des pairs sans redondance n'est pas un problème simple, et "le faire de la bonne façon" ne peut tout simplement pas arriver à temps si vous avez toujours veulent que ce soit parfait.
Pensez à la machine de l'industrie du jeu et à la façon dont SVN vous fait 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: il n'y a rien de difficile à coder, mais cela doit être fait de la bonne façon, 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 petits projets d'équipe à court terme et serrés. Vous n'avez pas besoin d'apprendre beaucoup de SVN, c'est presque un FTP avec un diff stupide.
Voici les deux raisons pour lesquelles je reste avec SVN.
- La courbe d'apprentissage. SVN est plus facile que Git, même la configuration (serveur ou client aussi), la convivialité et les commandes.
- De meilleurs packages de serveur comme Subversion Edge , VisualSVN , berSVN etc.
Il existe actuellement deux grandes tendances dans le contrôle des versions; Distribution et intégration .
Git est excellent en décentralisation.
SVN a construit de nombreux outils qui l'intègrent. Il est courant de configurer votre serveur SVN de sorte que lorsque vous archivez un correctif, vous mentionnez le numéro de bogue dans le commentaire d’archivage, et il le règle automatiquement mais à un état "en test", et alerte le testeur affecté qu’il doit Regarde ça. Ensuite, vous pouvez étiqueter une version et obtenir une liste de tous les bogues corrigés dans cette version.
Les outils qui le font avec SVN sont matures et utilisés tous les jours.