svn - Pourquoi Git est-il meilleur que Subversion?

Translate

J'ai utiliséSubversionpendant quelques années et après utilisationSourceSafe, J'adore Subversion. Combiné avecÉcailleSVN, Je ne peux pas vraiment imaginer comment ça 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 version distribués, tels queGit.

Comment Git améliore-t-il Subversion?

This question and all comments follow the "Attribution Required."

Toutes les réponses

Translate

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 sur la route, que vous développez sur votre ordinateur portable et que vous souhaitez avoir un contrôle de source pour pouvoir revenir en arrière de 3 heures.

Avec Subversion, vous avez un problème: le référentiel SVN peut être 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 voulez 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 profiter de tous les avantages du contrôle de code source. Lorsque vous retrouvez la connectivité avec le référentiel principal, vous pouvez vous engager contre lui.

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

Git semble être le "nouveau, brillant, 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 je pense que beaucoup de gens sautent dans le train "Distributed Source Control" simplement parce qu'il est nouveau et est écrit par Linus Torvalds, sans en fait savoir pourquoi / si c'est mieux.

Subversion a des problèmes, mais il en va de même pour Git, Mercurial, CVS, TFS ou autre.

Éditer:Donc, cette réponse a maintenant un an et génère encore beaucoup de votes positifs, alors j'ai pensé ajouter quelques explications supplémentaires. Au cours de la dernière année depuis l'écriture de ceci, Git a gagné beaucoup d'élan et de 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 vous travaillez 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, "git init" de Git peut prendre les paramètres --bare et --shared qui semble être la "bonne" façon de mettre en place un dépôt. Il y a des raisons à cela, mais cela ajoute de la complexité. La documentation de la commande "checkout" est très déroutante pour les gens qui changent - la manière "correcte" 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 sur la route, 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 une commande supplémentaire cependant (git commit commite localement, alors que git push origin master pousse la branche master vers la télécommande nommée "origin").

Comme dit ci-dessus: Git ajoute de la complexité. Deux modes de création de référentiels, extraction vs clonage, commit vs push ... 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, l'outillage est encore insuffisant, 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 apportées à celui-ci, si vous savez comment créer, valider et commander et que vous êtes prêt à partir et pouvez récupérer des éléments comme le branchement, la mise à jour, etc. plus tard sur.

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'entends, 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 également pourquoi il gagne autant de buzz sur Internet, car Git est parfaitement adapté aux projets Open Source: il suffit de le Forker, de valider vos modifications sur votre propre Fork, puis de demander au responsable du projet d'origine de retirer vos modifications. Avec Git, cela fonctionne. Vraiment, essayez-le sur Github, c'est magique.

Ce que je vois aussi, ce sont des ponts Git-SVN: le référentiel central est un dépôt Subversion, mais les développeurs travaillent localement avec Git et le pont pousse ensuite leurs modifications vers SVN.

Mais même avec ce long ajout, je reste fidèle à mon message principal: Git n'est ni meilleur ni pire, c'est juste différent. Si vous avez besoin d'un "contrôle de source hors ligne" et la volonté de passer un peu plus de temps à l'apprendre, c'est fantastique. Mais si vous avez un contrôle de source strictement centralisé et / ou que vous 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 outillage (au moins sous Windows) de SVN brillent.

La source
Translate

Avec Git, vous pouvez pratiquement tout faire hors ligne, car tout le monde a son propre référentiel.

Créer des branches et fusionner entre les branches est vraiment facile.

Même si vous ne disposez pas des 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 dans les corrections de bogues de la branche HEAD.

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

Git est très flexible, très TIMTOWTDI (il y a plus d'une façon de le faire). Vous pouvez utiliser le flux de travail de votre choix et Git le prendra en charge.

Enfin, il y aGitHub, 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 cryptiques et les messages d'erreur sont très peu conviviaux
  • il manque une bonne interface graphique (comme la grandeÉcailleSVN)
La source
Translate

D'autres réponses ont bien expliqué les fonctionnalités de base de Git (qui sont excellentes). Mais il y en a aussi tellementpeucomment Git se comporte mieux et aide à garder ma vie plus saine. Voici quelques petites choses:

  1. Git a une commande 'clean'. 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.
  2. Git a la commande 'bisect'. C'est bien.
  3. SVN crée des répertoires .svn dans chaque dossier (Git crée uniquementunerépertoire .git). Chaque script que vous écrivez, et chaque grep que vous faites, devra être écrit 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.
  4. 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 fait, c'est qu'il existe un million de façons différentes pour que votre caisse locale soit complètement foutue. (par exemple, si "svn switch" échoue à mi-chemin, ou si vous entrez une commande incorrecte). Et le pire, c'est que si jamais vous vous trouvez dans une situation où certains de vos fichiers proviennent d'un endroit, et certains d'entre eux 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 bizarres. Si "git status" vous dit que les choses sont normales, alors vous pouvez être sûr que les choses sont vraiment normales.
  5. Vous devez informer SVN chaque fois que vous déplacez ou supprimez quelque chose. Git va juste le comprendre.
  6. Ignorer la sémantique est plus facile dans Git. Si vous ignorez un modèle (tel que * .pyc), il sera ignoré pendanttoutsous-répertoires. (Mais si vous voulez vraiment ignorer quelque chose pour un seul répertoire, vous pouvez). Avec SVN, il semble qu'il n'y ait pas de moyen facile d'ignorer un modèle dans tous les sous-répertoires.
  7. 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.
La source
Translate

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

Brièvement:

  • Pistes Gitcontenu plutôt que fichiers
  • Les branches sont légèreset la fusion estfacile, et je veux direvraiment facile.
  • Il est distribué, fondamentalement chaque référentiel est une branche. C'est beaucoup plus facile à développer simultanément et en collaboration qu'avec Subversion, à mon avis. Cela fait aussihors lignedéveloppement possible.
  • Iln'impose aucun workflow, comme on le voit surle site Web lié ci-dessus, il existe de nombreux flux de travail possibles avec Git. Un flux de travail de style Subversion est facilement imité.
  • Les dépôts Git sont beaucouptaille de fichier plus petiteque les référentiels 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 plusutilise désormais un seul répertoirecomme Git.)
  • lemise en scèneLa zone est géniale, elle vous permet de voir les changements que vous allez valider, de valider des changements partiels et de faire diverses autres choses.
  • Cacherest inestimable lorsque vous faites du développement «chaotique», ou que vous voulez simplement corriger un bogue pendant que vous travaillez encore sur autre chose (sur une branche différente).
  • Vous pouvezréécrire l'histoire, ce qui est idéal pour préparer des ensembles de patchs et corriger vos erreurs (avantvous publiez les commits)
  • … Et unlotplus.

Il y a quelques inconvénients:

  • Il n'y a 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 incluentTortueGitetGitHub 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-module. Git 1.7+ prend en charge les extractions éparses.
  • Cela peut être plus difficile à apprendre, même si je n'ai pas trouvé que c'était le cas (il y a environ un an). Git a récemment amélioré son interface et est assez convivial.

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

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

et

git clone [email protected]:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Là où Git brille vraiment, c'est le branchement et le travail avec d'autres personnes.

La source
Parker Lee
Translate

Google Tech Talk: Linus Torvalds sur git

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

La page de comparaison de Git Wiki

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

La source
Translate

Eh bien, il est distribué. Les benchmarks indiquent qu'il est considérablement plus rapide (compte tenu de 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 me souffle encore).

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 endépartré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 validations.

Avec un contrôle de version distribué, vous n'avez pas d'instantané, mais plutôt l'ensemble de la base de code. Voulez-vous faire un diff avec une version de 3 mois? Pas de problème, la version de 3 mois est toujours sur votre ordinateur. Cela ne signifie pas seulement que les choses sont beaucoup plus rapides, mais si vous êtes déconnecté de votre serveur central, vous pouvez toujours effectuer de nombreuses 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 prendrait beaucoup d'espace sur votre disque dur, mais d'après quelques points de repère que j'ai vus, cela prend en fait moins. Ne me demandez pas comment. Je veux dire, il a été construit par Linus, il sait une chose ou deux sur les systèmes de fichiers, je suppose.

La source
Translate

Les principaux points que j'aime à propos de DVCS sont les suivants:

  1. Vous pouvez commettre des choses cassées. Cela n'a pas d'importance car les autres ne les verront pas tant que vous ne les publiez pas. L'heure de publication est différente de l'heure de validation.
  2. Pour cette raison, vous pouvez vous engager plus souvent.
  3. 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.
  4. Vous pouvez rechercher votre historique (trouver quand une fonction a changé)
  5. 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.
  6. 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 ...
  7. 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.

La source
Christopher Lee
Translate

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

Lisez s'il vous plaîtDéveloppez avec Git sur un projet Google Code

Bien que Google Code parle nativement de 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 me donne des avantages:

  1. Je peux travaillerdistribuésur plusieurs machines, s'engager et tirer depuis et vers elles
  2. j'ai uncentral backup/publicdépôt svn pour que les autres puissent le vérifier
  3. Et ils sont libres d'utiliser Git pour leur propre compte
La source
Si.
Translate

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 qui bénéficient du contrôle de version et qui devraient vivre à proximité 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, à la fois dans l'outillage client et la formation, entre Subversion et git. Je ne vois pas de scénario oùtoutLe système de contrôle de révision distribué sera plus facile à utiliser ou à expliquer à un non-programmeur. J'adorerais avoir tort, car alors je pourrais évaluer git et espérer qu'il soit accepté par des personnes qui ont besoin d'un contrôle de version 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 de contrôle de révision distribué, j'aurais du mal à donner une réponse honnête, car nous n'en avons pas besoin.

Avertissement: Je me suis intéressé à Subversion très tôt (vers 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 passe avec la plupart des éditeurs de logiciels. Avec autant de programmeurs qui sautent dans le train en marche git, je me demande combien d'entreprises vont manquer les avantages de l'utilisation du contrôle de version en dehors du code source? Même si vous avez des systèmes séparés pour différentes équipes, vous manquez certains des 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.

La source
Translate

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

La source
Prima Lee
Translate

Une des choses qui me dérange à propos de SubVersion est qu'il met 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 pascetteun gros problème, mais de petites choses comme ça s'additionnent.

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

La source
Adair Lee
Translate

David Richards WANdisco Blog sur Subversion / GIT

L'émergence de GIT a amené avec elle une race de fondamentalistes DVCS - les «Gitterons» - qui pensent que tout autre chose que GIT est de la merde. Les Gitteron semblent penser que l'ingénierie logicielle se produit sur leur propre île et oublient souvent que la plupart des organisations n'emploient pas exclusivement des ingénieurs logiciels seniors. 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 regard, détenait moins de trois pour cent du marché tandis que Subversion comptait environ cinq millions d'utilisateurs et environ la moitié de le marché global.

Le problème que nous avons vu était que les Gitteron tiraient des coups (bon marché) sur Subversion. Tweets comme "Subversion est tellement [lent / merdique / restrictif / ne sent pas bon / me regarde d'une manière amusante] et maintenant j'ai GIT et [tout fonctionne dans ma vie / ma femme est tombée enceinte / j'ai 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.

La source
Translate

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

La source
Hazel Lee
Translate

Tout dépend de la facilité d'utilisation / des étapes nécessaires pour faire quelque chose.

Si je développe un seul projet sur mon PC / ordinateur portable, git est meilleur, 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 les 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 pousser et tirer l'un de l'autre.

Une fois que vous aurez dépassé cela, j'opterais pour la 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 compensés par la nécessité de faire des étapes supplémentaires pour se synchroniser 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 tellement.

SVN a également l'avantage de meilleurs outils GUI, mais l'écosystème git semble rattraper rapidement son retard, donc je ne m'inquiéterais pas à ce sujet à long terme.

La source
Abigail Lee
Translate

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

La source
Clement Lee
Translate

Git et DVCS en général sont parfaits pour les développeurs faisant beaucoup de codage indépendamment les uns des autres, car chacun a sa propre branche. Si vous avez besoin d'un changement de la part de quelqu'un d'autre, cependant, 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 faites des choses comme les versions centralisées. Quelqu'un doit être responsable de faire ce push / pull à partir du référentiel de tous les autres, de résoudre tous les conflits qui auraient été résolus au moment de la validation initiale avant, puis de faire la construction, puis de demander à tous les autres développeurs de resynchroniser leurs dépôts.

Tout cela peut être résolu avec des processus humains, bien sûr; DVCS vient de casser quelque chose qui a été corrigé par le contrôle de version centralisé afin de fournir de nouvelles commodités.

La source
Translate

J'aime Git parce qu'il aide en fait un développeur de communication à un développeur 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 aide à gérer un grand pool de développeurs travaillant sur un seul projet.

Par exemple, disons que vous faites confiance à 5 développeurs et que vous ne tirez que les codes de leur référentiel. Chacun de ces développeurs a son propre réseau de confiance d'où ils tirent 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é du développement.

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

La source
Translate

Quelques réponses y ont fait allusion, mais je tiens à préciser 2 points:

1) La possibilité de faire 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 qui n'inclut qu'une partie des modifications. Avec Subversion, c'est difficile.

2) La capacité 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 de développement de correctifs. Subversion est simplement un VCS.

La source
Translate

Je pense que Subversion va bien… jusqu'à ce que vous commenciez à fusionner… ou à faire quelque chose de compliqué… ou à faire quoi que ce soit que Subversion pense être compliqué (comme faire des requêtes pour savoir quelles branches ont gâché un fichier particulier, où un changementréellementprovient de, détection de copier-coller, etc) ...

Je ne suis pas d'accord avec la réponse gagnante, en disantavantage principalde GIT est un travail hors ligne - c'est certainement utile, mais cela ressemble plus à un extra 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 qu'il est incroyablement puissant et rapide et, 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?

La source
Sigrid Lee
Translate

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

La source
Translate

J'adore pouvoir gérer les branches locales de mon code source dans Git sans brouiller l'eau 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 aussi génial 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 ne veuille afficher le journal. J'aime vraiment la façon dont Tortoise {Git | SVN} aide à lire les journaux de commit.

La source
Rosemary Lee
Translate

C'est la mauvaise question à se poser. Il est trop facile de se concentrer sur les verrues de git et de formuler un argument sur la raison pour laquelle la subversion est apparemment meilleure, du moins pour certains cas d'utilisation. Le fait que git ait été initialement conçu comme un ensemble de construction de contrôle de version de bas niveau et possède une interface baroque orientée développeur Linux, il est plus facile pour les guerres saintes de gagner en popularité et en légitimité perçue. Les partisans de Git frappent le tambour avec des millions d'avantages de flux de travail, que les gars de svn déclarent inutiles. Très vite, tout le débat est défini comme centralisé vs 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, sont tributaires de l'insécurité perçue de git et de l'état de préparation de svn pour le succès à long terme de leurs produits.

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

Alors que vous pouvez prendre git et créer un remplacement de subversion centralisé assez facilement, bien qu'il soit là depuis plus de deux fois plus longtemps, svn n'a jamais été en mesure de faire fonctionner 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 sont allés de cette façon à l'origine, cela rend certainement les vérifications partielles très simples. Malheureusement, cela rend également impossible de suivre correctement l'historique. Maintenant, évidemment, vous êtes censé utiliser les conventions de disposition des référentiels de subversion pour séparer les branches des répertoires normaux, et svn utilise des heuristiques pour faire fonctionner les choses pour les cas d'utilisation quotidiens. Mais tout cela ne fait que masquer une décision de conception de bas niveau très médiocre et limitante. Être capable de faire un diff 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, ce qui permet de créer des fonctionnalités plus intelligentes et utiles. Vous pouvez voir la quantité d'efforts qui ont été consacrés à l'extension de la subversion, et pourtant à quel point elle est loin de la récolte actuelle des VCS modernes en termes d'opérations fondamentales comme la résolution de fusion.

Voici maintenant mes conseils sincères et agnostiques pour tous ceux qui croient encore que Subversion est assez bon pour un avenir prévisible:

Subversion ne rattrapera jamais les nouvelles races de VCS qui ont appris des erreurs de RCS et CVS; c'est une impossibilité technique à moins qu'ils ne réoutillent le modèle de référentiel à partir de zéro, mais alors ce ne serait pas vraiment svn n'est-ce pas? Peu importe à quel point vous pensez ne pas avoir 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 claire qu'avec svn, je ne dirais certainement jamais une telle opinion sur win-vs-linux ou emacs-vs-vi, mais dans ce cas, c'est le cas la coupe à blanc, et le contrôle des sources est un outil si fondamental dans l'arsenal du développeur, que je pense 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 que 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 un programmeur, vous serez un programmeur plus efficace si vous apprenez à utiliser des VCS mieux conçus, que ce soit Git, Mercurial, Darcs ou bien d'autres.

La source
Translate

Subversion est très simple à utiliser. Je n'ai jamais trouvé ces dernières années un problème ou que quelque chose ne fonctionne pas comme prévu. Il existe également de nombreux excellents outils d'interface graphique 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 où vous validez toutes les modifications. Mais vous pouvez également l'utiliser principalement hors ligne et ne transmettre les modifications que de temps à autre au référentiel distant. Mais Git est plus complexe et a une courbe d'apprentissage plus raide. Je me suis retrouvé dans la première fois à commettre de mauvaises branches, à créer indirectement des branches 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 a 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, 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 pas de sauvegarde si quelque chose est perdu sur votre machine locale. Avec SVN, vous travaillez principalement avec un référentiel distant qui correspond é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 les besoins d'un système de contrôle de version distribué.

Est-ce que Git est meilleur que SVN? Les développeurs qui n'ont besoin que d'un historique des 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 comme le stockage non trouvé avec SVN qui peuvent rendre la vie plus facile. 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 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 coffrehttp://www.jgit.org/updates) La manière la plus préférée d'utiliser Git de nos jours est la ligne de commande.

La source
Translate

Évier Ericde 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.
Des articles peuvent être trouvés sur son blog,www.ericsink.com:

La source
Godfery Lee
Translate

Pour les personnes à la recherche d'une bonne interface graphique Git,Syntevo SmartGitpourrait être une bonne solution. Son propriétaire, mais gratuit pour un usage non commercial, fonctionne sous Windows / Mac / Linux et prend même en charge SVN en utilisant une sorte de pont git-svn, je pense.

La source
Simona Lee
Translate

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

Je pense qu'il est assez sûr de dire que parmi les développeurs, le SVN Vs. L'argument 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 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 version distribués (DVCS).

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

Regardez sa vidéo et dites-nous ce que vous en pensez soit en commentant ce blog, soit en publiant sur nos forums. L'inscription est simple et ne prendra qu'un instant!

La source
Charlotte Lee
Translate

Git dans Windows est maintenant assez bien pris en charge.

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

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

La source
Translate

J'ai habité à Git land ces derniers temps, et je l'aime pour des projets personnels, mais je ne pourrais pas encore changer de projet de travail depuis Subversion étant donné le changement de mentalité requis par le personnel, sans aucun avantage pressant. De plus, le plus gros projet que nous menons en interne est extrêmement dépendant desvn: externesqui, d'après ce que j'ai vu jusqu'à présent, ne fonctionne pas aussi bien et parfaitement dans Git.

La source
Yar
Translate

Premièrement, le contrôle des versions simultanées semble être un problème facile à résoudre. Ce n'est pas du tout. En tous cas...

SVN est assez peu intuitif. Git est encore pire. [spéculation sarcastique] Cela peut ê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 de 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, je suis un croyant. Maintenant, le contrôle de version fonctionne pour moi ET l'équipe / le projet au lieu de simplement travailler pour le projet. Quand j'ai besoin d'une succursale, je me branche. Parfois, c'est une branche qui a une branche correspondante sur le serveur, et parfois non. Sans parler de tous les autres avantages sur lesquels je vais devoir étudier (grâce en partie au manque mystérieux et absurde d'interface utilisateur qui est un système de contrôle de version moderne).

La source
Omar Lee
Translate

Pourquoi je pense que Subversion est meilleur que Git (du 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/

La source