Dois-je utiliser SVN ou Git ?

Question

Je démarre un nouveau projet distribué. Dois-je utiliser SVN ou Git, et pourquoi ?

Answer 1

SVN est un repo et de nombreux clients. Git est un dépôt avec de nombreux dépôts clients, chacun avec un utilisateur. Il est décentralisé à un point tel que les utilisateurs peuvent suivre leurs propres modifications localement sans avoir à les envoyer à un serveur externe.

SVN est conçu pour être plus central alors que Git est basé sur le fait que chaque utilisateur a son propre dépôt Git et que ces dépôts remontent les modifications vers un dépôt central. C'est pourquoi Git offre aux individus un meilleur contrôle local des versions.

Entre-temps, vous avez le choix entre TortoiseGit , GitExtensions (et si vous hébergez votre dépôt git "central" sur github, leur propre serveur client - GitHub pour Windows ).

Si vous envisagez de vous passer de SVN, vous devriez évaluer les éléments suivants Bazar pendant un certain temps. C'est l'un des systèmes de contrôle de version de la prochaine génération qui comporte un élément distribué. Il n'est pas dépendant de POSIX comme git, donc il existe des versions natives pour Windows et il est soutenu par de puissantes marques de logiciels libres.

Mais il se peut que vous n'ayez pas encore besoin de ce type de fonctionnalités. Jetez un coup d'œil à les caractéristiques, avantages et inconvénients des VCS distribués . Si vous avez besoin de plus que ce qu'offre SVN, envisagez d'en utiliser un. Si vous n'en avez pas besoin, vous pouvez vous en tenir à l'intégration bureautique (actuellement) supérieure de SVN.

Answer 2

Je n'ai jamais compris ce concept de "git n'est pas bon sous Windows" ; je développe exclusivement sous Windows et je n'ai jamais eu de problèmes avec git.

Je recommanderais sans hésiter git plutôt que subversion ; il est tout simplement beaucoup plus polyvalent et permet le "développement hors ligne" d'une manière que subversion n'a jamais vraiment pu faire. Il est disponible sur presque toutes les plateformes imaginables et possède plus de fonctionnalités que vous n'en utiliserez probablement jamais.

Answer 3

Voici une copie d'une réponse que j'ai faite de certaines questions en double ont été supprimées depuis à propos de Git vs. SVN (septembre 2009).

Mieux ? Outre le lien habituel PourquoiGitIsBetterThanX Ils sont différents :

l'un est un VCS central basé sur une copie bon marché pour les branches et les étiquettes l'autre (Git) est un VCS distribué basé sur un graphe de révisions. Voir aussi Concepts fondamentaux du VCS .

---

Cette première partie a suscité des commentaires mal informés prétendant que l'objectif fondamental des deux programmes (SVN et Git) est le même, mais qu'ils ont été mis en œuvre de manière très différente.
Pour clarifier la différence fondamentale entre SVN et Git Permettez-moi de reformuler :

• SVN est la troisième implémentation d'un révision contrôle : RCS, puis CVS et enfin SVN gérer des répertoires de données versionnées. SVN offre des fonctionnalités VCS (étiquetage et fusion), mais son étiquette n'est qu'une copie de répertoire (comme une branche, sauf que vous n'êtes pas "censé" toucher à quoi que ce soit dans un répertoire d'étiquette), et sa fusion est encore compliquée, actuellement basée sur des méta-données ajoutées pour se souvenir de ce qui a déjà été fusionné.

• Git est un gestion du contenu des fichiers (un outil permettant de fusionner des fichiers), a évolué vers un véritable système de contrôle de version sur la base d'un DAG ( Graphique acyclique dirigé ) des commits, où les branches font partie de l'historique des données (et non des données elles-mêmes), et où les balises sont de véritables méta-données.

Dire qu'ils ne sont pas "fondamentalement" différents parce qu'ils permettent de réaliser la même chose, de résoudre le même problème, est... tout simplement faux à bien des égards.

• si vous avez de nombreuses fusions complexes, les réaliser avec SVN sera plus long et plus sujet aux erreurs. si vous devez créer de nombreuses branches, vous devrez les gérer et les fusionner, encore une fois beaucoup plus facilement avec Git qu'avec SVN, surtout si un grand nombre de fichiers sont concernés (la vitesse devient alors importante).
• si vous avez des fusions partielles pour un travail en cours, vous profiterez de la zone de transit de Git (index) pour ne livrer que ce dont vous avez besoin, mettre le reste de côté et passer à une autre branche.
• si vous avez besoin d'un développement hors ligne... eh bien, avec Git, vous êtes toujours "en ligne", avec votre propre dépôt local, quel que soit le flux de travail que vous souhaitez suivre avec d'autres dépôts.

---

Les commentaires sur cette ancienne réponse (supprimée) insistent toujours :

VonC : Vous confondez une différence fondamentale de mise en œuvre (les différences sont très fondamentales, nous sommes tous deux clairement d'accord sur ce point) avec une différence d'objectif.
Il s'agit de deux outils utilisés dans le même but : c'est la raison pour laquelle de nombreuses équipes qui utilisaient SVN auparavant ont réussi à s'en débarrasser au profit de Git.
S'ils n'ont pas résolu le même problème, cette substituabilité n'existerait pas.

ce à quoi j'ai répondu :

"substituabilité"... terme intéressant ( utilisés dans la programmation informatique ).
Bien entendu, Git n'est pas un sous-type de SVN.

Vous pouvez réaliser les mêmes fonctionnalités techniques (tag, branch, merge) avec les deux, mais Git ne se met pas en travers de votre chemin. vous permettent de vous concentrer sur le contenu des fichiers sans penser à l'outil lui-même.

Vous ne pouvez certainement pas (toujours) remplacer SVN par Git "sans altérer aucune des propriétés souhaitables de ce programme (correction, tâche accomplie, ...)" (ce qui est une référence à la directive définition de la substituabilité ) :

• L'un est un outil de révision étendu, l'autre un véritable système de contrôle des versions.
• L'une d'entre elles est adaptée aux projets monolithiques de petite ou moyenne envergure, avec un processus de fusion simple et des versions parallèles (pas trop nombreuses). SVN est suffisant pour cela, et vous n'avez peut-être pas besoin de toutes les fonctionnalités de Git.
• L'autre permet de réaliser des projets de moyenne ou grande envergure basés sur des composants multiples ( un repo par composant ), avec un grand nombre de fichiers à fusionner entre plusieurs branches dans un flux de travail de fusion complexe, des versions parallèles dans les branches, des fusions rétroactives, etc. Vous pouvez le faire avec SVN, mais il vaut mieux utiliser Git.
  SVN ne peut tout simplement pas gérer un projet, quelle que soit sa taille, avec un flux de travail de fusion. Git le peut.

Encore une fois, leur nature est fondamentalement différente (ce qui conduit à une mise en œuvre différente, mais ce n'est pas le sujet).
L'un voit le contrôle de révision comme des répertoires et des fichiers, l'autre ne voit que le contenu du fichier (à tel point que les répertoires vides ne sont même pas enregistrés dans Git !)

L'objectif général peut être le même, mais vous ne pouvez pas les utiliser de la même manière, ni résoudre la même catégorie de problèmes (en termes de portée ou de complexité).

Answer 4

2 avantages clés de SVN qui sont rarement cités :

1. Prise en charge de fichiers volumineux. Outre le code, j'utilise SVN pour gérer mon répertoire personnel. SVN est le seul VCS (distribué ou non) qui ne s'étouffe pas avec mes fichiers TrueCrypt (merci de me corriger s'il existe un autre VCS qui gère efficacement les fichiers de plus de 500 Mo). Ceci est dû au fait que les comparaisons de diff sont diffusées (c'est un point essentiel). Rsync est inacceptable parce qu'il n'est pas bidirectionnel.

2. Vérification partielle du dépôt (sous-répertoire). Mercurial et bzr ne supportent pas cela, et le support de git est limité. C'est une mauvaise chose dans un environnement d'équipe, mais inestimable si je veux vérifier quelque chose sur un autre ordinateur à partir de mon répertoire personnel.

Ce n'est que mon expérience.

Answer 5

Après avoir fait des recherches plus approfondies et consulté ce lien : https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(Quelques extraits ci-dessous) :

• Il est incroyablement rapide. Aucun autre SCM que j'ai utilisé n'a été capable de le suivre, et j'en ai utilisé beaucoup, y compris Subversion, Perforce, darcs, BitKeeper, ClearCase et CVS.
• Il est entièrement distribué. Le propriétaire du dépôt ne peut pas me dicter ma façon de travailler. Je peux créer des branches et livrer des modifications tout en étant déconnecté sur mon ordinateur portable, puis les synchroniser plus tard avec un nombre quelconque d'autres dépôts.
• La synchronisation peut se faire sur plusieurs supports. Un canal SSH, par HTTP via WebDAV, par FTP, ou par l'envoi de courriels contenant des correctifs à appliquer par le destinataire du message. Un dépôt central n'est pas nécessaire, mais il peut être utilisé.
• Les branches sont encore moins chères que dans Subversion. Créer une branche est aussi simple que d'écrire un fichier de 41 octets sur le disque. Supprimer une branche est aussi simple que de supprimer ce fichier.
• Contrairement à Subversion, les branches conservent leur historique complet. sans avoir à effectuer une copie étrange et à parcourir la copie. Lorsque j'utilisais Subversion, j'ai toujours trouvé gênant de regarder l'historique d'un fichier sur une branche qui s'est produit avant la création de la branche. from #git : spearce : I don't understand one thing about SVN in the page. J'ai créé une branche dans SVN et la navigation dans l'historique a montré tout l'historique d'un fichier dans la branche.
• La fusion de branches est plus simple et plus automatique dans Git. Dans Subversion, vous devez vous souvenir de la dernière révision à partir de laquelle vous avez fusionné afin de pouvoir générer la commande de fusion correcte. Git le fait automatiquement et toujours correctement. Cela signifie qu'il y a moins de risque de faire une erreur lors de la fusion de deux branches.
• Les fusions de branches sont enregistrées dans l'historique de l'application dépôt. Si je fusionne deux branches ensemble, ou si je fusionne une branche dans le tronc d'où elle vient, cette opération de fusion est enregistrée dans l'historique du référentiel comme ayant été effectuée par moi, et quand. Il est difficile de contester l'identité de l'auteur de la fusion lorsque celle-ci figure dans le journal.
• La création d'un dépôt est une opération triviale : mkdir foo ; cd foo ; git init C'est tout ce qu'il faut faire. Ce qui signifie que je crée un dépôt Git pour tout ces jours-ci. J'ai tendance à utiliser un dépôt par classe. La plupart de ces dépôts ne dépassent pas 1 Mo car ils ne contiennent que les notes de cours, les devoirs et mes réponses LaTeX.
• Les formats de fichiers internes du référentiel sont incroyablement simples. Cela signifie que la réparation est très facile à faire, mais mieux encore, parce que c'est si simple qu'il est très difficile d'être corrompu. Je ne pense pas que quelqu'un ait jamais eu un dépôt Git corrompu. J'ai vu Subversion avec fsfs se corrompre. Et j'ai vu Berkley DB se corrompre trop souvent pour confier mon code au backend bdb de Subversion.
• Le format de fichier de Git est très efficace pour compresser les données, même si Malgré sa simplicité, le format de Git est très efficace pour compresser les données. Le dépôt CVS du projet Mozilla pèse environ 3 Go ; il pèse environ 12 Go dans le format fsfs de Subversion. Dans Git, il est d'environ 300 Mo.

Après avoir lu tout cela, je suis convaincu que Git est la voie à suivre (bien qu'il y ait une petite courbe d'apprentissage). J'ai utilisé Git et SVN sur des plateformes Windows également.

J'aimerais savoir ce que d'autres ont à dire après avoir lu ce qui précède ?