Pourquoi Git est-il meilleur que Subversion ?

08-06-2019
|

Question

j'ai utilisé Subversion pendant quelques années et après utilisation SourceSafe, j'adore Subversion.Combiné avec TortueSVN, je ne peux pas vraiment imaginer comment cela pourrait être mieux.

Pourtant, un nombre croissant de développeurs affirment que Subversion a des problèmes et que nous devrions passer à la nouvelle génération de systèmes de contrôle de versions distribués, tels que Git.

Comment Git améliore-t-il Subversion ?

La solution

Git n'est pas meilleur que Subversion.Mais ce n’est pas pire non plus.C'est différent.

La principale différence est qu’il est décentralisé.Imaginez que vous êtes un développeur en déplacement, que vous développez sur votre ordinateur portable et que vous souhaitez disposer d'un contrôle de code source pour pouvoir remonter 3 heures en arrière.

Avec Subversion, vous avez un problème :Le référentiel SVN peut se trouver dans un endroit que vous ne pouvez pas atteindre (dans votre entreprise et vous n'avez pas Internet pour le moment), vous ne pouvez pas vous engager.Si vous souhaitez faire une copie de votre code, vous devez littéralement le copier/coller.

Avec Git, vous n'avez pas ce problème.Votre copie locale est un référentiel, et vous pouvez vous y engager et bénéficier de tous les avantages du contrôle de code source.Lorsque vous retrouvez la connectivité au référentiel principal, vous pouvez vous y engager.

Cela semble bien au début, mais gardez simplement à l’esprit la complexité supplémentaire de cette approche.

Git semble être le truc "nouveau, brillant et cool".Ce n'est en aucun cas mauvais (il y a une raison pour laquelle Linus l'a écrit pour le développement du noyau Linux après tout), mais j'ai l'impression que beaucoup de gens sautent dans le train du "Contrôle de source distribué" simplement parce qu'il est nouveau et qu'il est écrit par Linus Torvalds, sans réellement savoir pourquoi/si c'est mieux.

Subversion a des problèmes, tout comme Git, Mercurial, CVS, TFS ou autre.

Modifier: Cette réponse a donc maintenant un an et génère encore de nombreux votes positifs, j'ai donc pensé ajouter quelques explications supplémentaires.Au cours de la dernière année depuis la rédaction de ces lignes, Git a gagné en popularité et en soutien, en particulier depuis que des sites comme GitHub ont vraiment décollé.J'utilise à la fois Git et Subversion de nos jours et j'aimerais partager quelques idées personnelles.

Tout d’abord, Git peut être très déroutant au début lorsque l’on travaille de manière décentralisée.Qu'est-ce qu'une télécommande ?et Comment configurer correctement le référentiel initial ?sont deux questions qui se posent au début, surtout par rapport au simple "svnadmin create" de SVN, le "git init" de Git peut prendre les paramètres --bare et --shared ce qui semble être la "bonne" manière de mettre en place un système centralisé. dépôt.Il y a des raisons à cela, mais cela ajoute à la complexité.La documentation de la commande "checkout" est très déroutante pour les personnes qui changent - la "bonne" méthode semble être "git clone", tandis que "git checkout" semble changer de branche.

Git brille VRAIMENT lorsque vous êtes décentralisé.J'ai un serveur à la maison et un ordinateur portable en déplacement, et SVN ne fonctionne tout simplement pas bien ici.Avec SVN, je ne peux pas avoir de contrôle de source local si je ne suis pas connecté au référentiel (oui, je connais SVK ou les moyens de copier le dépôt).Avec Git, c'est de toute façon le mode par défaut.C'est cependant une commande supplémentaire (git commit commit localement, alors que git push origin master pousse la branche master vers la télécommande nommée "origin").

Comme dit plus haut :Git ajoute de la complexité.Deux modes de création de référentiels, paiement vs.cloner, valider contre.pousser...Vous devez savoir quelles commandes fonctionnent localement et lesquelles fonctionnent avec "le serveur" (je suppose que la plupart des gens aiment toujours un "référentiel maître" central).

De plus, les outils sont encore insuffisants, du moins sous Windows.Oui, il existe un complément Visual Studio, mais j'utilise toujours git bash avec msysgit.

SVN a l'avantage d'être BEAUCOUP plus simple à apprendre :Il y a votre référentiel, toutes les modifications qui y sont apportées, si vous savez comment créer, valider et extraire et que vous êtes prêt à partir et que vous pouvez récupérer des éléments comme le branchement, la mise à jour, etc.plus tard.

Git a l'avantage d'être BEAUCOUP mieux adapté si certains développeurs ne sont pas toujours connectés au référentiel maître.De plus, c'est beaucoup plus rapide que SVN.Et d'après ce que j'ai entendu, le support de branchement et de fusion est bien meilleur (ce qui est normal, car ce sont les principales raisons pour lesquelles il a été écrit).

Cela explique aussi pourquoi il fait autant de buzz sur Internet, car Git est parfaitement adapté aux projets Open Source :Forkez-le simplement, validez vos modifications dans votre propre Fork, puis demandez au responsable du projet d'origine d'extraire vos modifications.Avec Git, cela fonctionne.Vraiment, essayez-le sur Github, c'est magique.

Ce que je vois également, ce sont des ponts Git-SVN :Le dépôt central est un dépôt Subversion, mais les développeurs travaillent localement avec Git et le pont transmet ensuite leurs modifications à SVN.

Mais même avec ce long ajout, je maintiens toujours mon message principal :Git n'est ni meilleur ni pire, c'est juste différent.Si vous avez besoin du "Contrôle de source hors ligne" et que vous êtes prêt à passer un peu plus de temps à l'apprendre, c'est fantastique.Mais si vous disposez d'un contrôle de source strictement centralisé et/ou avez du mal à introduire le contrôle de source en premier lieu parce que vos collègues ne sont pas intéressés, alors la simplicité et l'excellent outil (au moins sous Windows) de SVN brillent.

Autres conseils

Avec Git, vous pouvez pratiquement tout faire hors ligne, car chacun possède son propre référentiel.

Créer des branches et fusionner entre branches est vraiment simple.

Même si vous n'avez pas de droits de validation pour un projet, vous pouvez toujours avoir votre propre référentiel en ligne et publier des « demandes push » pour vos correctifs.Tous ceux qui aiment vos correctifs peuvent les intégrer à leur projet, y compris les responsables officiels.

Il est trivial de créer un projet, de le modifier et de continuer à fusionner les corrections de bugs de la branche HEAD.

Git fonctionne pour les développeurs du noyau Linux.Cela signifie qu'il est très rapide (cela doit l'être) et qu'il s'adapte à des milliers de contributeurs.Git utilise également moins d'espace (jusqu'à 30 fois moins d'espace pour le dépôt Mozilla).

Git est très flexible, très TIMTOWTDI (il existe plusieurs façons de le faire).Vous pouvez utiliser le workflow de votre choix et Git le prendra en charge.

Enfin, il y a GitHub, un excellent site pour héberger vos référentiels Git.

Inconvénients de Git :

c'est beaucoup plus difficile à apprendre, car Git a plus de concepts et plus de commandes.
les révisions n'ont pas de numéros de version comme dans Subversion
de nombreuses commandes Git sont énigmatiques et les messages d'erreur sont très peu conviviaux
il lui manque une bonne interface graphique (comme la grande TortueSVN)

D'autres réponses ont fait du bon travail en expliquant les fonctionnalités principales de Git (qui sont excellentes).Mais il y en a aussi tellement petit façons dont Git se comporte mieux et m'aide à garder ma vie plus saine.Voici quelques petites choses :

Git a une commande « propre ».SVN a désespérément besoin de cette commande, compte tenu de la fréquence à laquelle il videra des fichiers supplémentaires sur votre disque.
Git a la commande « bisect ».C'est bien.
SVN crée des répertoires .svn dans chaque dossier (Git crée uniquement un répertoire .git).Chaque script que vous écrivez et chaque grep que vous effectuez devront être écrits pour ignorer ces répertoires .svn.Vous avez également besoin d'une commande entière ("svn export") juste pour obtenir une copie saine de vos fichiers.
Dans SVN, chaque fichier et dossier peut provenir d’une révision ou d’une branche différente.Au début, cela semble agréable d’avoir cette liberté.Mais ce que cela signifie en réalité, c'est qu'il existe un million de façons différentes de complètement gâcher votre caisse locale.(par exemple, si "svn switch" échoue à mi-chemin ou si vous entrez une commande incorrecte).Et le pire c'est :si jamais vous vous trouvez dans une situation où certains de vos fichiers proviennent d'un endroit et certains d'un autre, le "svn status" vous dira que tout est normal.Vous devrez faire "svn info" sur chaque fichier/répertoire pour découvrir à quel point les choses sont étranges.Si « git status » vous indique que les choses sont normales, alors vous pouvez être sûr que les choses sont vraiment normales.
Vous devez informer SVN chaque fois que vous déplacez ou supprimez quelque chose.Git va juste le découvrir.
Ignorer la sémantique est plus facile dans Git.Si vous ignorez un modèle (tel que *.pyc), il sera ignoré pour tous sous-répertoires.(Mais si vous voulez vraiment ignorer quelque chose pour un seul répertoire, vous le pouvez).Avec SVN, il semble qu'il n'y ait pas de moyen simple d'ignorer un modèle dans tous les sous-répertoires.
Un autre élément impliquant des fichiers ignorés.Git permet d'avoir des paramètres d'ignorance "privés" (en utilisant le fichier .git/info/exclude), qui n'affecteront personne d'autre.

"Pourquoi Git est meilleur que X" décrit les différents avantages et inconvénients de Git par rapport aux autres SCM.

Brièvement:

Pistes Git du contenu plutôt que des fichiers
Les branches sont légères et la fusion est facile, et je veux dire vraiment facile.
C'est distribué, fondamentalement, chaque référentiel est une branche.Il est beaucoup plus facile de développer simultanément et en collaboration qu'avec Subversion, à mon avis.Cela fait aussi hors ligne développement possible.
Il n'impose aucun workflow, comme on le voit sur le site Web lié ci-dessus, de nombreux workflows sont possibles avec Git.Un flux de travail de style Subversion est facilement imité.
Les dépôts Git sont nombreux taille de fichier plus petite que les dépôts Subversion.Il n'y a qu'un seul répertoire ".git", par opposition à des dizaines de dépôts ".svn" (notez Subversion 1.7 et versions ultérieures utilise désormais un seul répertoire comme Git.)
Le mise en scène La zone est géniale, elle vous permet de voir les modifications que vous allez valider, de valider des modifications partielles et de faire diverses autres choses.
Cachette est inestimable lorsque vous effectuez un développement "chaotique", ou que vous souhaitez simplement corriger un bug pendant que vous travaillez encore sur autre chose (sur une branche différente).
Tu peux réécrire l'histoire, ce qui est idéal pour préparer des ensembles de correctifs et corriger vos erreurs (avant vous publiez les commits)
… et un parcelle plus.

Il y a quelques inconvénients :

Il n’existe pas encore beaucoup de bonnes interfaces graphiques pour cela.C'est nouveau et Subversion existe depuis bien plus longtemps, c'est donc naturel car il y a quelques interfaces en développement.Certains bons incluent TortueGit et GitHub pour Mac.
~~Les extractions partielles/clones de référentiels ne sont pas possibles pour le moment (j'ai lu que c'est en développement).Cependant, il existe un support de sous-modules.~~ Git 1.7+ prend en charge les extractions clairsemées.
Cela pourrait être plus difficile à apprendre, même si je n’ai pas trouvé que ce soit le cas (il y a environ un an).Git a récemment amélioré son interface et est très convivial.

Dans l'utilisation la plus simpliste, Subversion et Git sont à peu près identiques.Il n'y a pas beaucoup de différence entre :

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Là où Git brille vraiment, c'est en créant des branches et en travaillant avec d'autres personnes.

Discussion technique Google :Linus Torvalds sur git

http://www.youtube.com/watch?v=4XpnKHJAok8

La page de comparaison du Git Wiki

http://git.or.cz/gitwiki/GitSvnComparsion

Eh bien, c'est distribué.Les benchmarks indiquent qu'il est considérablement plus rapide (étant donné sa nature distribuée, les opérations telles que les différences et les journaux sont toutes locales, donc bien sûr, c'est incroyablement plus rapide dans ce cas), et les dossiers de travail sont plus petits (ce qui m'épate toujours).

Lorsque vous travaillez sur Subversion ou sur tout autre système de contrôle de révision client/serveur, vous créez essentiellement des copies de travail sur votre machine en départ révisions.Cela représente un instantané dans le temps de ce à quoi ressemble le référentiel.Vous mettez à jour votre copie de travail via des mises à jour et vous mettez à jour le référentiel via des commits.

Avec un contrôle de version distribué, vous n'avez pas un instantané, mais plutôt l'intégralité de la base de code.Tu veux faire une différence avec une version vieille de 3 mois ?Pas de problème, la version vieille de 3 mois est toujours sur votre ordinateur.Cela ne signifie pas seulement que les choses sont beaucoup plus rapides, mais que si vous êtes déconnecté de votre serveur central, vous pouvez toujours effectuer la plupart des opérations auxquelles vous êtes habitué.En d’autres termes, vous n’avez pas seulement un instantané d’une révision donnée, mais l’intégralité de la base de code.

On pourrait penser que Git occuperait beaucoup d'espace sur votre disque dur, mais d'après quelques benchmarks que j'ai vus, cela prend en réalité moins.Ne me demandez pas comment.Je veux dire, il a été construit par Linus, il connaît une chose ou deux sur les systèmes de fichiers, je suppose.

Les principaux points que j'aime chez DVCS sont ceux-là :

Vous pouvez commettre des choses cassées.Cela n'a pas d'importance car les autres personnes ne les verront pas tant que vous ne les publierez pas.L’heure de publication est différente de l’heure de validation.
Grâce à cela, vous pouvez vous engager plus souvent.
Vous pouvez fusionner des fonctionnalités complètes.Cette fonctionnalité aura sa propre branche.Tous les commits de cette branche seront liés à cette fonctionnalité.Vous pouvez le faire avec un CVCS, mais avec DVCS, c'est la valeur par défaut.
Vous pouvez rechercher votre historique (trouver quand une fonction a changé)
Vous pouvez annuler une extraction si quelqu'un bousille le référentiel principal, vous n'avez pas besoin de corriger les erreurs.Effacez simplement la fusion.
Lorsque vous avez besoin d'un contrôle de source dans n'importe quel répertoire, faites :git init.et vous pouvez valider, annuler les modifications, etc...
C'est rapide (même sous Windows)

La principale raison d’un projet relativement important est l’amélioration de la communication créée par le point 3.D’autres sont de jolis bonus.

Le plus drôle c'est :J'héberge des projets dans Subversion Repos, mais j'y accède via la commande Git Clone.

Lisez s'il vous plaît Développer avec Git sur un projet Google Code

Bien que Google Code parle nativement la subversion, vous pouvez facilement utiliser GIT pendant le développement.La recherche de "Git SVN" suggère que cette pratique est répandue, et nous vous encourageons également à l'expérimenter.

Utiliser Git sur un référentiel Svn m'apporte des avantages :

Je peux travailler distribué sur plusieurs machines, commits et tirant de et vers eux
j'ai un central backup/public dépôt svn que d'autres peuvent consulter
Et ils sont libres d’utiliser Git pour leur propre compte

Toutes les réponses ici sont comme prévu, centrées sur le programmeur, mais que se passe-t-il si votre entreprise utilise le contrôle des révisions en dehors du code source ?Il existe de nombreux documents qui ne sont pas du code source et qui bénéficient du contrôle de version et devraient être proches du code et non dans un autre CMS.La plupart des programmeurs ne travaillent pas de manière isolée : nous travaillons pour des entreprises au sein d'une équipe.

Dans cet esprit, comparez la facilité d'utilisation, tant au niveau des outils clients que de la formation, entre Subversion et git.Je ne vois pas de scénario où n'importe lequel Le système de contrôle de révision distribué sera plus facile à utiliser ou à expliquer à un non-programmeur.J'aimerais avoir tort, car je serais alors en mesure d'évaluer git et d'avoir l'espoir qu'il soit accepté par les personnes qui ont besoin d'un contrôle de version et qui ne sont pas des programmeurs.

Même dans ce cas, si la direction me demandait pourquoi nous devrions passer d'un système de contrôle de révision centralisé à un système distribué de contrôle des révisions, j'aurais du mal à donner une réponse honnête, car nous n'en avons pas besoin.

Clause de non-responsabilité:Je me suis intéressé à Subversion très tôt (autour de la v0.29), donc je suis évidemment partial, mais les entreprises pour lesquelles j'ai travaillé depuis lors bénéficient de mon enthousiasme car j'ai encouragé et soutenu son utilisation.Je soupçonne que c'est ainsi que cela se produit avec la plupart des éditeurs de logiciels.Avec autant de programmeurs prenant le train en marche avec Git, je me demande combien d’entreprises vont passer à côté des avantages de l’utilisation du contrôle de version en dehors du code source ?Même si vous disposez de systèmes distincts pour différentes équipes, vous passez à côté de certains avantages, tels que l'intégration (unifiée) du suivi des problèmes, tout en augmentant les exigences en matière de maintenance, de matériel et de formation.

Subversion est toujours un système de contrôle de version beaucoup plus utilisé, ce qui signifie qu'il dispose d'un meilleur support d'outils.Vous trouverez des plugins SVN matures pour presque tous les EDI, et de bonnes extensions d'explorateur sont disponibles (comme TurtoiseSVN).A part ça, je devrai être d'accord avec Michael:Git n'est ni meilleur ni pire que Subversion, c'est différent.

L'une des choses qui me dérangent à propos de SubVersion est qu'elle place son propre dossier dans chaque répertoire d'un projet, alors que git n'en met qu'un dans le répertoire racine.Ce n'est pas que c'est une grosse affaire, mais de petites choses comme celle-là s'additionnent.

Bien sûr, SubVersion a Tortoise, ce qui est [généralement] très sympa.

David Richards Blog WANdisco sur Subversion / GIT

L’émergence du GIT a amené avec elle une race de fondamentalistes du DVCS – les « Gitterons » – qui pensent que tout autre chose que le GIT est de la merde.Les Gitterons semblent penser que l’ingénierie logicielle se déroule sur leur propre île et oublient souvent que la plupart des organisations n’emploient pas exclusivement des ingénieurs logiciels expérimentés.Ce n’est pas grave, mais ce n’est pas ce que pense le reste du marché, et je suis heureux de le prouver :GIT, au dernier coup d'œil, détenait moins de trois pour cent du marché tandis que Subversion compte environ cinq millions d'utilisateurs et environ la moitié du marché global.

Le problème que nous avons constaté était que les Gitterons tiraient des coups (bon marché) sur Subversion.Des tweets comme « Subversion est tellement [lent/merdique/restrictif/ne sent pas bon/me regarde d'une drôle de façon] et maintenant j'ai GIT et [tout fonctionne dans ma vie/ma femme est tombée enceinte/j'ai eu une petite amie après 30 ans d'essais/J'ai gagné six fois en courant sur la table de blackjack].Vous voyez l'image.

Git facilite également la création de branches et la fusion.Subversion 1.5 vient d'ajouter le suivi des fusions, mais Git est encore meilleur.Avec Git, le branchement est très rapide et bon marché.Cela rend plus réalisable la création d’une branche pour chaque nouvelle fonctionnalité.Les référentiels Oh et Git sont très efficaces en termes d'espace de stockage par rapport à Subversion.

Tout dépend de la facilité d'utilisation et des étapes requises pour faire quelque chose.

Si je développe un seul projet sur mon PC/ordinateur portable, git est préférable, car il est beaucoup plus facile à configurer et à utiliser.Vous n'avez pas besoin d'un serveur et vous n'avez pas besoin de continuer à saisir l'URL du référentiel lorsque vous effectuez des fusions.

S'il n'y avait que 2 personnes, je dirais que git est également plus facile, car vous pouvez simplement vous pousser et vous tirer l'un de l'autre.

Une fois que vous avez dépassé cela, j'opterais pour Subversion, car à ce stade, vous devez configurer un serveur ou un emplacement « dédié ».

Vous pouvez le faire aussi bien avec git qu'avec SVN, mais les avantages de git sont contrebalancés par la nécessité d'effectuer des étapes supplémentaires pour la synchronisation avec un serveur central.Dans SVN, vous vous engagez simplement.Dans git, vous devez git commit, puis git push.L'étape supplémentaire devient ennuyeuse simplement parce que vous finissez par en faire trop.

SVN bénéficie également de meilleurs outils GUI, mais l'écosystème git semble rattraper son retard rapidement, donc je ne m'inquiéterais pas de cela à long terme.

Git facile a une belle page comparant l'utilisation réelle de Git et SVN ce qui vous donnera une idée de ce que Git peut faire (ou faire plus facilement) par rapport à SVN.(Techniquement, ceci est basé sur Easy Git, qui est un wrapper léger au-dessus de Git.)

Git et DVCS en général sont parfaits pour les développeurs qui codent beaucoup indépendamment les uns des autres, car chacun a sa propre branche.Cependant, si vous avez besoin d'un changement de la part de quelqu'un d'autre, elle doit s'engager dans son dépôt local, puis elle doit vous transmettre cet ensemble de modifications ou vous devez le lui retirer.

Mon propre raisonnement me fait également penser que DVCS rend les choses plus difficiles pour l'assurance qualité et la gestion des versions si vous effectuez des choses comme des versions centralisées.Quelqu'un doit être responsable de faire ce push/pull à partir du référentiel de tout le monde, de résoudre tous les conflits qui auraient été résolus au moment de la validation initiale auparavant, puis de faire la construction, puis de demander à tous les autres développeurs de resynchroniser leurs dépôts.

Bien entendu, tout cela peut être résolu par des processus humains ;DVCS vient de casser quelque chose qui a été corrigé par le contrôle de version centralisé afin d'offrir de nouvelles commodités.

J'aime Git car il aide réellement les développeurs de communication à développer dans une équipe de taille moyenne à grande.En tant que système de contrôle de version distribué, grâce à son système push/pull, il aide les développeurs à créer un écosystème de code source qui permet de gérer un large pool de développeurs travaillant sur un seul projet.

Par exemple, disons que vous faites confiance à 5 développeurs et que vous extrayez uniquement les codes de leur référentiel.Chacun de ces développeurs dispose de son propre réseau de confiance à partir duquel il extrait les codes.Ainsi, le développement est basé sur ce tissu de confiance des développeurs où la responsabilité du code est partagée entre la communauté de développement.

Bien sûr, il existe d'autres avantages qui sont mentionnés dans d'autres réponses ici.

Quelques réponses y ont fait allusion, mais je souhaite expliciter 2 points :

1) La possibilité d'effectuer des commits sélectifs (par exemple, git add --patch).Si votre répertoire de travail contient plusieurs modifications qui ne font pas partie de la même modification logique, Git facilite grandement la réalisation d'une validation n'incluant qu'une partie des modifications.Avec Subversion, c'est difficile.

2) La possibilité de s’engager sans rendre le changement public.Dans Subversion, tout commit est immédiatement public, et donc irrévocable.Cela limite considérablement la capacité du développeur à « s'engager tôt, s'engager souvent ».

Git est plus qu'un simple VCS ;c'est aussi un outil pour développer des correctifs.Subversion n'est qu'un VCS.

Je pense que Subversion va bien..jusqu'à ce que vous commenciez à fusionner.ou faire quelque chose de compliqué..ou faire tout ce que Subversion juge compliqué (comme faire des requêtes pour savoir quelles branches ont perturbé un fichier particulier, où un changement en fait vient, détection des copier-coller, etc)...

Je ne suis pas d'accord avec la réponse gagnante, disant que principal avantage de GIT est un travail hors ligne - c'est certainement utile, mais cela ressemble plus à un supplément pour mon cas d'utilisation.SVK peut également fonctionner hors ligne, mais je ne me demande toujours pas dans lequel investir mon temps d'apprentissage).

C'est juste que c'est incroyablement puissant et rapide et, bien - après s'être habitué aux concepts - très utile (oui, dans ce sens :convivial).

Pour plus de détails sur une histoire de fusion, voir ceci :Utiliser git-svn (ou similaire) *juste* pour aider avec une fusion svn ?

Grâce au fait qu'il n'a pas besoin de communiquer constamment avec un serveur central, presque toutes les commandes s'exécutent en moins d'une seconde (évidemment, git push/pull/fetch sont plus lents simplement parce qu'ils doivent initialiser les connexions SSH).Le branchement est beaucoup plus facile (une simple commande pour créer un branchement, une simple commande pour fusionner)

J'adore pouvoir gérer les branches locales de mon code source dans Git sans brouiller les pistes du référentiel central.Dans de nombreux cas, je vais extraire le code du serveur Subversion et exécuter un référentiel Git local juste pour pouvoir le faire.C'est également formidable que l'initialisation d'un référentiel Git ne pollue pas le système de fichiers avec un tas de dossiers .svn ennuyeux partout.

Et en ce qui concerne la prise en charge des outils Windows, TortoiseGit gère très bien les bases, mais je préfère toujours la ligne de commande à moins que je souhaite afficher le journal.J'aime vraiment la façon dont Tortoise{Git|SVN} aide lors de la lecture des journaux de validation.

Ce n’est pas la bonne question à poser.Il est trop facile de se concentrer sur les défauts de Git et de formuler un argument sur les raisons pour lesquelles la subversion est apparemment meilleure, du moins pour certains cas d'utilisation.Le fait que git ait été conçu à l'origine comme un ensemble de construction de contrôle de version de bas niveau et qu'il dispose d'une interface baroque orientée développeur Linux permet aux guerres saintes de gagner plus facilement du terrain et une légitimité perçue.Les partisans de Git frappent le tambour avec des millions d'avantages en matière de flux de travail, que les gars de SVN déclarent inutiles.Très vite, l'ensemble du débat est défini comme centralisé ou distribué, ce qui sert les intérêts de la communauté des outils SVN d'entreprise.Ces sociétés, qui publient généralement les articles les plus convaincants sur la supériorité de la subversion dans l'entreprise, dépendent de l'insécurité perçue de git et de la préparation de svn à l'entreprise pour le succès à long terme de leurs produits.

Mais voici le problème : La subversion est une impasse architecturale.

Alors que vous pouvez prendre git et créer un remplacement de subversion centralisé assez facilement, même s'il existe depuis plus de deux fois plus longtemps, svn n'a jamais été en mesure de faire fonctionner même le suivi de fusion de base aussi bien que dans git.L'une des raisons fondamentales à cela est la décision de conception de rendre les branches identiques aux répertoires.Je ne sais pas pourquoi ils ont choisi cette voie à l'origine, cela rend certainement les paiements partiels très simples.Malheureusement, cela rend également impossible le suivi correct de l’historique.Maintenant, évidemment, vous êtes censé utiliser les conventions de présentation du référentiel Subversion pour séparer les branches des répertoires normaux, et svn utilise des heuristiques pour que les choses fonctionnent pour les cas d'utilisation quotidiens.Mais tout cela ne fait que dissimuler une décision de conception de bas niveau très médiocre et limitante.Être capable d'effectuer une comparaison par référentiel (plutôt que par répertoire) est une fonctionnalité de base et critique pour un système de contrôle de version, et simplifie considérablement les composants internes, permettant de créer des fonctionnalités plus intelligentes et utiles par-dessus.Vous pouvez voir la quantité d'efforts qui ont été déployés pour étendre la subversion, et pourtant à quel point elle est loin de la récolte actuelle de VCS modernes en termes d'opérations fondamentales comme la résolution de fusion.

Voici maintenant mon conseil sincère et agnostique pour tous ceux qui croient encore que Subversion est assez bon dans un avenir prévisible :

Subversion ne rattrapera jamais les nouvelles générations de VCS qui ont appris des erreurs de RCS et CVS ;c'est une impossibilité technique à moins qu'ils ne réorganisent le modèle de référentiel à partir de zéro, mais alors ce ne serait pas vraiment svn, n'est-ce pas ?Même si vous pensez ne pas connaître les capacités d'un VCS moderne, votre ignorance ne vous protégera pas des pièges de Subversion, dont beaucoup sont des situations impossibles ou faciles à résoudre dans d'autres systèmes.

Il est extrêmement rare que l'infériorité technique d'une solution soit aussi nette qu'avec svn, certainement je n'exprimerais jamais une telle opinion sur win-vs-linux ou emacs-vs-vi, mais dans ce cas c'est tellement clearcut, et le contrôle de code source est un outil tellement fondamental dans l'arsenal du développeur que j'estime qu'il doit être déclaré sans équivoque.Indépendamment de la nécessité d'utiliser svn pour des raisons d'organisation, j'implore tous les utilisateurs de svn de ne pas laisser leur esprit logique construire une fausse croyance selon laquelle les VCS plus modernes ne sont utiles que pour les grands projets open source.Quelle que soit la nature de votre travail de développement, si vous êtes programmeur, vous serez un programmeur plus efficace si vous apprenez à utiliser des VCS mieux conçus, qu'il s'agisse de Git, Mercurial, Darcs ou bien d'autres.

Subversion est très simple à utiliser.Je n'ai jamais rencontré de problème ces dernières années ou que quelque chose ne fonctionne pas comme prévu.Il existe également de nombreux excellents outils GUI et la prise en charge de l'intégration SVN est importante.

Avec Git, vous obtenez un VCS plus flexible.Vous pouvez l'utiliser de la même manière que SVN avec un référentiel distant dans lequel vous validez toutes les modifications.Mais vous pouvez également l'utiliser principalement hors ligne et transférer les modifications uniquement de temps en temps vers le référentiel distant.Mais Git est plus complexe et sa courbe d’apprentissage est plus abrupte.Je me suis retrouvé dans un premier temps à m'engager dans de mauvaises branches, à créer des branches indirectement ou à recevoir des messages d'erreur avec peu d'informations sur l'erreur et où je dois chercher avec Google pour obtenir de meilleures informations.Certaines choses simples comme la substitution de marqueurs ($Id$) ne fonctionnent pas mais GIT dispose d'un mécanisme de filtrage et de hook très flexible pour fusionner vos propres scripts et ainsi vous obtenez tout ce dont vous avez besoin et plus encore, mais cela nécessite plus de temps et de lecture de la documentation. ;)

Si vous travaillez principalement hors ligne avec votre référentiel local, vous n'avez aucune sauvegarde si quelque chose est perdu sur votre ordinateur local.Avec SVN, vous travaillez principalement avec un référentiel distant qui est également votre sauvegarde sur un autre serveur...Git peut fonctionner de la même manière mais ce n'était pas l'objectif principal de Linus d'avoir quelque chose comme SVN2.Il a été conçu pour les développeurs du noyau Linux et pour les besoins d'un système de contrôle de version distribué.

Git est-il meilleur que SVN ?Les développeurs qui n'ont besoin que d'un historique de versions et d'un mécanisme de sauvegarde ont une vie agréable et facile avec SVN.Les développeurs travaillant souvent avec des branches, testant plusieurs versions en même temps ou travaillant principalement hors ligne peuvent bénéficier des fonctionnalités de Git.Il existe des fonctionnalités très utiles, telles que le stockage introuvable avec SVN, qui peuvent vous faciliter la vie.Mais d’un autre côté, tout le monde n’aura pas besoin de toutes les fonctionnalités.Je ne peux donc pas voir les morts de SVN.

Git a besoin d'une meilleure documentation et le rapport d'erreurs doit être plus utile.De plus, les interfaces graphiques utiles existantes ne le sont que rarement.Cette fois, je n'ai trouvé qu'une seule interface graphique pour Linux prenant en charge la plupart des fonctionnalités de Git (git-cola).L'intégration d'Eclipse fonctionne mais n'est pas officiellement publiée et il n'y a pas de site de mise à jour officiel (seulement un site de mise à jour externe avec des versions périodiques du tronc http://www.jgit.org/updates) Ainsi, la façon la plus préférée d'utiliser GIT ce jour-là est la ligne de commande.

Éric Évier de SourceGear a écrit une série d'articles sur les différences entre les systèmes de contrôle de version distribués et non distribués.Il compare les avantages et les inconvénients des systèmes de contrôle de version les plus populaires.Lecture très intéressante.
Les articles sont à retrouver sur son blog, www.ericsink.com:

Pour les personnes recherchant une bonne interface graphique Git, Syntevo SmartGit pourrait être une bonne solution.Son propriétaire, mais gratuit pour une utilisation non commerciale, fonctionne sous Windows/Mac/Linux et prend même en charge SVN en utilisant une sorte de pont git-svn, je pense.

http://subversion.wandisco.com/component/content/article/1/40.html

Je pense qu'il est assez prudent de dire que parmi les développeurs, le SVN Vs.Le débat sur Git fait rage depuis un certain temps maintenant, chacun ayant sa propre opinion sur ce qui est le meilleur.Cela a même été évoqué dans les questions posées lors de notre webinaire sur Subversion en 2010 et au-delà.

Hyrum Wright, notre directeur de l'Open Source et président de Subversion Corporation parle des différences entre Subversion et Git, ainsi que d'autres systèmes de contrôle de versions distribués (DVCS).

Il parle également des changements à venir dans Subversion, tels que Working Copy Next Generation (WC-NG), qui, selon lui, inciteront un certain nombre d'utilisateurs de Git à se reconvertir vers Subversion.

Regardez sa vidéo et dites-nous ce que vous pensez en commentant sur ce blog ou en la publiant sur nos forums.L'inscription est simple et ne prendra que quelques instants !

Git sous Windows est désormais assez bien pris en charge.

Découvrez GitExtensions = http://code.google.com/p/gitextensions/

et le manuel pour une meilleure expérience Windows Git.

J'ai vécu dans le pays Git ces derniers temps, et je l'aime pour mes projets personnels, mais je ne serais pas encore en mesure d'y transférer des projets de travail depuis Subversion étant donné le changement de pensée requis de la part du personnel, sans aucun avantage urgent.De plus, le plus gros projet que nous menons en interne dépend extrêmement de svn:externes ce qui, d'après ce que j'ai vu jusqu'à présent, ne fonctionne pas aussi bien et de manière transparente dans Git.

Premièrement, le contrôle de version simultané semble être un problème facile à résoudre.Ce n'est pas du tout le cas.De toute façon...

SVN n'est pas du tout intuitif.C'est encore pire.[spéculation sarcastique] Cela pourrait être dû au fait que les développeurs, qui aiment les problèmes difficiles comme le contrôle de version simultané, n'ont pas beaucoup d'intérêt à créer une bonne interface utilisateur.[/sarcastique-spéculation]

Les partisans du SVN pensent qu'ils n'ont pas besoin d'un système de contrôle de version distribué. Je pensais ça aussi. Mais maintenant que nous utilisons exclusivement Git, j'y crois.Désormais, le contrôle de version fonctionne pour moi ET pour l'équipe/le projet au lieu de simplement travailler pour le projet.Quand j’ai besoin d’une branche, je branche.Parfois, c'est une branche qui a une branche correspondante sur le serveur, et parfois non.Sans parler de tous les autres avantages que je devrai étudier (en partie grâce au manque obscur et absurde d'interface utilisateur qu'est un système de contrôle de version moderne).

Pourquoi je pense que Subversion est meilleur que Git (au moins pour les projets sur lesquels je travaille), principalement en raison de sa convivialité et de son flux de travail plus simple :

http://www.databasesandlife.com/why-subversion-is-better-than-git/

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow