Dois-je utiliser SVN ou Git? [fermé]

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

SVN est un repo et beaucoup de clients. Git est un référentiel avec beaucoup de dépôts clients, chacun avec un utilisateur. Il est décentralisé à un point où les gens peuvent suivre leurs propres modifications localement sans avoir à pousser les choses vers un serveur externe.

SVN est conçu pour être plus central, où Git est basé sur le fait que chaque utilisateur possède son propre référentiel Git et que ces dépôts repoussent les modifications vers un central. Pour cette raison, Git offre aux individus un meilleur contrôle de version locale.

En attendant, vous avez le choix entre TortoiseGit , GitExtensions (et si vous hébergez votre git-repository "central" sur github, leur propre client - GitHub pour Windows ).

Si vous cherchez à sortir de SVN, vous voudrez peut-être évaluer Bazaar un peu. Il fait partie de la prochaine génération de systèmes de contrôle de version qui ont cet élément distribué. Il ne dépend pas de POSIX comme git, il existe donc des versions natives de Windows et il est soutenu par de puissantes marques open source.

Mais vous n'avez peut-être même pas encore besoin de ce type de fonctionnalités. Jetez un œil aux caractéristiques, avantages et inconvénients des VCS distribués . Si vous avez besoin de plus que des offres SVN, envisagez-en une. Si vous ne le faites pas, vous voudrez peut-être vous en tenir à l'intégration de bureau supérieure (actuellement) de SVN.

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

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

Voici une copie d'une réponse que j'ai faite à une question en double depuis supprimée à propos de Git vs. SVN (septembre 2009).

Mieux? Mis à part le lien habituel WhyGitIsBetterThanX , ils sont différents:

l'un est un VCS central basé sur une copie bon marché pour les branches et les balises, l'autre (Git) est un VCS distribué basé sur un graphique de révisions. Voir aussi Concepts de base de VCS .

Cette première partie a généré 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 contrôle de révision : RCS, puis CVS et enfin SVN gèrent des répertoires de données versionnées. SVN offre des fonctionnalités VCS (étiquetage et fusion), mais sa balise 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 de balises), et sa fusion est toujours 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 une gestion de contenu de fichier (un outil conçu pour fusionner des fichiers), évolué vers un véritable système de contrôle de version , basé sur un DAG ( Directed Acyclic Graph ) de 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 vraies métadonnées.

Dire qu'ils ne sont pas "fondamentalement" différents parce que vous pouvez réaliser la même chose, résoudre le même problème, c'est ... tout simplement faux à tant de niveaux.

• si vous avez de nombreuses fusions complexes, les faire avec SVN sera plus long et plus sujet aux erreurs. si vous devez créer plusieurs branches, vous devrez les gérer et les fusionner, encore plus facilement avec Git qu'avec SVN, surtout si un nombre élevé de fichiers est impliqué (la vitesse devient alors importante)
• si vous avez des fusions partielles pour un travail en cours, vous profiterez de la zone de transit Git (index) pour valider uniquement ce dont vous avez besoin, cacher le reste 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 référentiel local, quel que soit le workflow que vous souhaitez suivre avec d'autres référentiels.

Pourtant, les commentaires sur cette ancienne réponse (supprimée) insistaient:

VonC: Vous confondez une différence fondamentale de mise en œuvre (les différences sont très fondamentales, nous sommes tous les deux clairement d'accord là-dessus) avec une différence de but.
Ce sont deux outils utilisés dans le même but: c'est pourquoi de nombreuses équipes qui utilisaient auparavant SVN ont réussi à le vider en faveur de Git.
S'ils ne résolvaient pas le même problème, cette substituabilité n'existerait pas.

auquel j'ai répondu:

"substituabilité" ... terme intéressant ( utilisé en programmation informatique ).
Bien sûr, Git n'est guère un sous-type de SVN.

Vous pouvez obtenir les mêmes fonctionnalités techniques (tag, branche, fusion) avec les deux, mais Git ne vous gêne pas et vous permet de vous concentrer sur le contenu des fichiers , sans penser à l'outil lui-même.

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

• L'un est un outil de révision étendu, l'autre un véritable système de contrôle de version.
• L'un est adapté aux projets monolithiques petits à moyens avec un flux de travail de fusion simple et (pas trop) des versions parallèles. SVN est suffisant à cet effet, et vous n'aurez peut-être pas besoin de toutes les fonctionnalités de Git.
• L'autre permet des projets de taille moyenne à grande basés sur plusieurs composants ( un dépôt 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 de mise à niveau, etc. Vous pourriez le faire avec SVN, mais vous êtes beaucoup mieux avec Git.
  SVN ne peut tout simplement pas gérer un projet de n'importe quelle taille avec un flux de travail de fusion. Git peut.

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

L'objectif final 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 classe de problème (en termes de portée ou de complexité).

2 avantages clés du SVN rarement cités:

1. Prise en charge de fichiers volumineux. En plus du code, j'utilise SVN pour gérer mon répertoire personnel. SVN est le seul VCS (distribué ou non) qui ne s'étouffe pas sur mes fichiers TrueCrypt (veuillez me corriger s'il y a un autre VCS qui gère efficacement les fichiers de 500 Mo +). C'est parce que les comparaisons diff sont diffusées (c'est un point très essentiel). Rsync est inacceptable car il n'est pas bidirectionnel.

2. Checkout / checkin de référentiel partiel (subdir). Mercurial et bzr ne le supportent pas, et le support de git est limité. C'est mauvais dans un environnement d'équipe, mais inestimable si je veux vérifier quelque chose sur un autre ordinateur depuis mon répertoire personnel.

Juste mes expériences.

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

(Quelques extraits ci-dessous):

• C'est incroyablement rapide. Aucun autre SCM que j'ai utilisé n'a été en mesure de le suivre, et j'en ai beaucoup utilisé, notamment Subversion, Perforce, darcs, BitKeeper, ClearCase et CVS.
• Il est entièrement distribué. Le propriétaire du référentiel ne peut pas dicter comment je travaille. Je peux créer des branches et valider les modifications lorsque je suis déconnecté de mon ordinateur portable, puis le synchroniser plus tard avec n'importe quel nombre d'autres référentiels.
• La synchronisation peut se produire sur de nombreux supports. Un canal SSH, via HTTP via WebDAV, par FTP, ou en envoyant des e-mails contenant des correctifs à appliquer par le destinataire du message. Un référentiel central n'est pas nécessaire, mais peut être utilisé.
• Les succursales sont encore moins chères qu'en Subversion. La création d'une branche est aussi simple que d'écrire un fichier de 41 octets sur le disque. La suppression d'une branche est aussi simple que la suppression de ce fichier.
• Contrairement aux branches Subversion, elles portent toute leur histoire. sans avoir à effectuer une copie étrange et à parcourir la copie. Lorsque j'utilise Subversion, je trouve toujours gênant de consulter l'historique d'un fichier sur une branche qui s'est produit avant la création de la branche. de #git: spearce: Je ne comprends rien à SVN dans la page. J'ai fait une branche i SVN et en parcourant l'historique j'ai montré toute l'histoire 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 le fait toujours correctement. Ce qui signifie qu'il y a moins de chance de faire une erreur lors de la fusion de deux branches.
• Les fusions de branches sont enregistrées dans le cadre de l'historique approprié du référentiel. Si je fusionne deux branches ensemble, ou si je fusionne une branche dans le tronc dont elle est issue, cette opération de fusion est enregistrée dans le cadre de l'historique du repostage comme ayant été effectuée par moi, et quand. Il est difficile de contester qui a effectué la fusion lorsqu'il se trouve juste dans le journal.
• La création d'un référentiel est une opération banale: mkdir foo; cd foo; git init C'est tout. Ce qui signifie que je crée un référentiel Git pour tout de nos jours. J'ai tendance à utiliser un référentiel par classe. La plupart de ces référentiels ont moins de 1 Mo sur le disque car ils ne stockent que des notes de cours, des 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 encore mieux car elle est si simple qu'il est très difficile de se corrompre. Je ne pense pas que quiconque 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 de fois pour faire confiance à mon code au backend bdb de Subversion.
• Le format de fichier de Git est très bon pour compresser des données, malgré son format très simple. Le référentiel CVS du projet Mozilla fait environ 3 Go; c'est environ 12 Go au format fsfs de Subversion. Dans Git, c'est environ 300 Mo.

Après avoir lu tout cela, je suis convaincu que Git est la voie à suivre (bien qu'il existe un peu de courbe d'apprentissage). J'ai également utilisé Git et SVN sur les plates-formes Windows.

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

Je mettrais en place un référentiel Subversion. De cette façon, les développeurs individuels peuvent choisir d'utiliser des clients Subversion ou des clients Git (avec git-svn). L'utilisation git-svnne vous donne pas tous les avantages d'une solution Git complète, mais elle donne aux développeurs individuels beaucoup de contrôle sur leur propre flux de travail.

Je pense qu'il faudra un temps relativement court avant que Git ne fonctionne aussi bien sur Windows que sur Unix et Mac OS X (puisque vous l'avez demandé).

Subversion possède d'excellents outils pour Windows, tels que TortoiseSVN pour l'intégration Explorer et AnkhSVN pour l'intégration Visual Studio.

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

Veuillez lire Développer avec Git sur un projet Google Code

Bien que Google Code parle nativement 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.

L'utilisation de Git sur un référentiel Svn me donne des avantages:

1. Je peux travailler réparti sur plusieurs machines, en validant et en tirant depuis et vers elles
2. J'ai un dépôt central backup/public svn pour que les autres puissent le vérifier
3. Et ils sont libres d'utiliser Git pour leur propre compte

Je ne réponds pas vraiment à votre question, mais si vous voulez les avantages du contrôle de révision distribué - cela ressemble à vous - et vous utilisez Windows, je pense que vous feriez mieux d'utiliser Mercurial plutôt que Git as Mercurial a un bien meilleur support Windows. Mercurial possède également un port Mac.

Si votre équipe est déjà familière avec les logiciels de contrôle de version et de code source comme cvs ou svn, alors, pour un projet simple et petit (tel que vous le prétendez), je vous recommande de vous en tenir à SVN. Je suis vraiment à l'aise avec svn, mais pour le projet de commerce électronique actuel que je fais sur django, j'ai décidé de travailler sur git (j'utilise git en mode svn, c'est-à-dire avec un dépôt centralisé sur lequel je pousse et tire afin de collaborer avec au moins un autre développeur). L'autre développeur est à l'aise avec SVN, et bien que les expériences des autres puissent différer, nous avons tous les deux beaucoup de mal à adopter git pour ce petit projet. (Nous sommes tous les deux des utilisateurs inconditionnels de Linux, si cela importe.)

Votre kilométrage peut varier, bien sûr.

Certainement svn, puisque Windows est - au mieux - un citoyen de seconde classe dans le monde de git(voir http://en.wikipedia.org/wiki/Git_(software)#Portability pour plus de détails).

MISE À JOUR: Désolé pour le lien brisé, mais j'ai renoncé à essayer de faire fonctionner SO avec des URI qui contiennent des parenthèses. [lien corrigé maintenant. -ed]

Le point principal est que Git est un VCS distribué et Subversion un centralisé. Les VCS distribués sont un peu plus difficiles à comprendre, mais présentent de nombreux avantages. Si vous n'avez pas besoin de ces avantages, Subversion peut être le meilleur choix.

Une autre question concerne le support d'outils. Quel VCS est mieux supporté par les outils que vous prévoyez d'utiliser?

EDIT: Il y a trois ans, j'ai répondu de cette façon:

Et Git ne fonctionne pour l'instant sur Windows que via Cygwin ou MSYS . Subversion a pris en charge Windows depuis le début. Comme les solutions git pour Windows peuvent fonctionner pour vous, il peut y avoir des problèmes, car la plupart des développeurs de Git travaillent avec Linux et n'avaient pas la portabilité en tête depuis le début. Pour le moment, je préférerais Subversion pour le développement sous Windows. Dans quelques années, cela pourrait ne plus être pertinent.

Maintenant, le monde a un peu changé. Git a maintenant une bonne implémentation sur Windows. Bien que je n'aie pas testé minutieusement sur Windows (car je n'utilise plus ce système), je suis assez confiant, que tous les principaux VCS (SVN, Git, Mercurial, Bazaar) ont maintenant une implémentation Windows appropriée. Cet avantage pour SVN a disparu. Les autres points (centralisés vs distribués et la vérification de la prise en charge des outils) restent valides.

J'opterais pour SVN car il est plus répandu et mieux connu.

Je suppose que Git serait mieux pour les utilisateurs de Linux.

Git n'est pas nativement pris en charge sous Windows, pour l'instant. Il est optimisé pour les systèmes Posix. Cependant, exécuter Cygwin ou MinGW vous permet d'exécuter Git avec succès.

De nos jours, je préfère Git à SVN, mais il faut un certain temps pour dépasser le seuil si vous venez de CVS, SVN land.

Je choisirais probablement Git car je pense qu'il est beaucoup plus puissant que SVN. Il existe des services d'hébergement de code bon marché qui fonctionnent très bien pour moi - vous n'avez pas besoin de faire de sauvegardes ni de travaux de maintenance - GitHub est le candidat le plus évident.

Cela dit, je ne sais rien de l'intégration de Visual Studio et des différents systèmes SCM. J'imagine que l'intégration avec SVN est nettement meilleure.

J'utilise SVN depuis longtemps, mais chaque fois que j'utilisais Git, je sentais que Git est beaucoup plus puissant, léger et bien qu'un peu de courbe d'apprentissage soit impliqué mais meilleur que SVN.

Ce que j'ai noté, c'est que chaque projet SVN, à mesure qu'il grandit, devient un projet de très grande taille à moins qu'il ne soit exporté. Alors que le projet GIT (avec les données Git) est très léger.

Dans SVN, j'ai traité avec des développeurs de novices à experts, et les novices et intermédiaires semblent introduire des conflits de fichiers s'ils copient un dossier d'un autre projet SVN afin de le réutiliser. Alors que, je pense que dans Git, vous copiez simplement le dossier et cela fonctionne, car Git n'introduit pas les dossiers .git dans tous ses sous-dossiers (comme le fait SVN).

Après avoir beaucoup travaillé avec SVN depuis longtemps, je pense enfin à déplacer mes développeurs et moi vers Git, car il est facile de collaborer et de fusionner le travail, ainsi qu'un grand avantage est que les modifications d'une copie locale peuvent être validées autant souhaité, puis finalement poussé vers la branche sur le serveur en une seule fois, contrairement à SVN (où nous devons valider les modifications de temps en temps dans le référentiel sur le serveur).

Quelqu'un qui peut m'aider à décider si je dois vraiment aller avec Git?

Cela se résume à ceci:

Votre développement sera-t-il linéaire? Si c'est le cas, vous devriez vous en tenir à Subversion.

Si d'un autre côté, votre développement ne sera pas linéaire, ce qui signifie que vous devrez créer une ramification pour différents changements, puis fusionner ces changements vers la ligne de développement principale (connue par Git comme la branche principale), alors Git fera l'affaire. BEAUCOUP plus pour vous.

avez-vous essayé Bzr ?

C'est assez bon, connonical (les gens qui font Ubuntu) l'ont fait parce qu'ils n'aimaient rien d'autre sur le marché ...

Puis-je développer la question et demander si Git fonctionne bien sur MacOS?

Réponse aux commentaires: Merci pour la nouvelle, j'avais hâte de l'essayer. Je vais l'installer chez moi sur mon Mac.

Il y a une vidéo intéressante sur YouTube à ce sujet. C'est de Linus Torwalds lui-même: Goolge Tech Talk: Linus Torvalds sur git

SVN semble être un bon choix sous Windows, comme l'ont souligné d'autres personnes.

Si certains de vos développeurs veulent essayer GIT, il peut toujours utiliser GIT-SVN où le référentiel SVN est recréé dans un référentiel GIT. Il devrait ensuite pouvoir travailler localement avec GIT, puis utiliser SVN pour publier ses modifications dans le référentiel principal.

Il faut aller avec un DVCS, c'est comme un bond en avant dans la gestion des sources. Personnellement, j'utilise Monotone et son temps de développement accéléré sans fin. Nous l'utilisons pour Windows, Linux et Mac et il est très stable. J'ai même buildbot qui fait des builds nocturnes du projet sur chacune des plateformes.

Le DVCS, tout en étant distribué, signifie généralement que vous créerez un serveur central uniquement pour que les gens puissent y apporter des modifications.