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

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

SVN est conçu pour être plus central où Git est basé sur chaque utilisateur ayant leur propre git repo et ces repos push change de retour dans un central. Pour cette raison, Git donne aux individus un meilleur contrôle de version locale.

pendant ce temps vous avez le choix entre TortoiseGit , GitExtensions (et si vous hébergez votre dépôt "central" sur github, leur propre client-Github for Windows ).

si vous cherchez à sortir de SVN, vous pourriez vouloir évaluer Bazaar pour un peu. C'est l'un des systèmes de contrôle de version de la prochaine génération qui ont cet élément distribué. Il n'est pas POSIX charge comme git donc il y a Windows natif construit et il a un puissant open source, les marques de soutien.

mais il se peut que vous n'ayez pas encore besoin de ce genre de fonctionnalités. Regardez les caractéristiques, les avantages et les inconvénients des VCSes distribuées . Si vous avez besoin de plus D'offres SVN, envisagez-en une. Si vous ne le faites pas, vous voudrez peut-être vous en tenir à L'intégration supérieure des postes de travail de SVN (actuellement).

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

je recommanderais certainement git plutôt que subversion; c'est tout simplement beaucoup plus polyvalent et permet un" développement hors ligne " d'une manière que subversion ne pourrait jamais vraiment. Il est disponible sur presque toutes les plateformes imaginables et dispose de plus de fonctionnalités que vous ne pourrez probablement jamais utiliser.

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

C'est mieux? Outre le lien habituel WhyGitIsBetterThanX , ils sont différents:

one est un VCS Central basé sur la copie bon marché pour les branches et les étiquettes 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 en 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 le troisième de la mise en œuvre d'un revision control : RCS, puis CVS et enfin SVN Gérer les répertoires de données suivies en versions. SVN offre des fonctionnalités VCS (labeling et merging), 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 balise), 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 un file content management (un outil conçu pour fusionner des fichiers), développé en 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'histoire des données (et pas une donnée elle-même), et où les tags sont une véritable méta-données.

pour dire qu'ils ne sont pas" fondamentalement " différents parce que vous pouvez atteindre la même chose, résoudre le même problème, est... plaine faux sur de nombreux niveaux.

• si vous avez beaucoup de 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 une fois beaucoup plus facilement avec Git qu'avec SVN, surtout si un grand nombre de fichiers sont impliqués (la vitesse devient alors importante)
• si vous avez partielle fusionne pour un travail en cours, vous prendrez avantage de la Git staging area (index) pour ne commettre que ce dont vous avez besoin, planquer le reste, et passer à une autre branche.
• si vous avez besoin de développement hors ligne... 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.

toujours les commentaires sur cette ancienne réponse (supprimé) a insisté:

VonC: Vous confondez la différence fondamentale dans la mise en œuvre (les différences sont très fondamentales, nous sommes tous deux clairement d'accord là-dessus) avec la différence dans les buts.

Ce sont deux outils utilisés dans le même but: c'est la raison pour laquelle de nombreuses équipes qui ont utilisé SVN avec succès ont pu le jeter en faveur de git.

S'ils ne résolvaient pas le MÊME PROBLÈME, Ce substituabilité n'existerait pas.

, à laquelle j'ai répondu:

"substituabilité"... terme intéressant ( utilisé dans la programmation informatique ).

Bien sûr, Git n'est pas un sous-type de SVN.

vous pouvez obtenir les mêmes caractéristiques techniques (étiquette, branche, fusion) avec les deux, mais Git ne se met pas sur votre chemin et vous permettent de se concentrer sur le contenu des fichiers , sans penser à l'outil m'.

vous ne pouvez certainement pas (toujours) simplement remplacer SVN par GIT" sans modifier aucune des propriétés souhaitables de ce programme (exactitude, tâche exécutée, ...) "(qui est une référence à la ci-dessus):

• L'un est un outil de révision étendue, l'autre un véritable système de contrôle de version.
• un est adapté petit à moyen projet monolithique avec simple fusionner le flux de travail et (pas trop) les versions parallèles. SVN est suffisant pour cela, et vous n'aurez peut-être pas besoin de toutes les fonctionnalités de Git.
• l'autre permet pour les projets moyens à grands basés sur des composants multiples ( un rapport par composant ), avec un grand nombre de fichiers à fusionner entre plusieurs branches dans un flux de travail de fusion complexe, les versions parallèles dans les branches, les fusions retrofit, et ainsi de suite. Vous pourriez le faire avec SVN, mais vous êtes bien mieux avec Git.
  
  SVN ne peut tout simplement pas gérer n'importe quel projet de n'importe quelle taille avec n'importe quel flux de travail de fusion. Git peut.

encore une fois, leur nature est fondamentalement différente (ce qui conduit ensuite à une mise en œuvre différente, mais ce n'est pas la question).

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!).

le but 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 (dans la portée ou la complexité).

2 principaux avantages de SVN rarement Cités:

1. les fichiers de taille importante. 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 (corrigez-moi s'il y a un autre VCS qui gère efficacement les fichiers 500MB+). Cela est dû au fait que les comparaisons diff sont diffusées en continu (c'est un point très essentiel). Le Rsync est inacceptable parce qu'il n'est pas bidirectionnel.

2. Partielle référentiel (subdir) de caisse/d'archivage. Mercurial et bzr ne supportent pas cela, et le soutien 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 à partir de mon dir maison.

Juste mon expérience.

après avoir fait plus de recherche, et en passant en revue 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é capable de le suivre, et j'ai beaucoup utilisé, y compris Subversion, Perforce, darcs, BitKeeper, ClearCase et CVS.
• il est entièrement distribué. Le référentiel propriétaire Je ne peux pas dicter comment je travaille. Je peux créer des branches et propager des modifications pendant que je suis déconnecté sur mon ordinateur portable, puis plus tard synchroniser cela avec un certain nombre d'autres dépôts.
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 Branches
• sont même moins chères qu'elles ne le sont en 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 supprimer ce fichier.
• Contrairement aux branches Subversion, elles ont une histoire complète. sans avoir à effectuer une copie étrange et à parcourir la copie. Quand J'ai utilisé Subversion, j'ai toujours trouvé qu'il était maladroit de regarder l'historique d'un fichier sur branch qui s'est produit avant que la branche ne soit créée. de #git: spearce: Je ne comprends pas une chose à propos de SVN dans la page. J'ai fait une branche que j'ai SVN et la navigation dans l'histoire l'a bien montré toute l'histoire 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 le fait toujours correctement. Ce qui signifie qu'il y a moins de chance de faire une erreur en fusionnant deux branches ensemble.
Les fusions de succursales
• sont enregistrées comme suit: une partie de la propre histoire de l' référentiel. Si je fusionne deux branches ensemble, ou si je fusionne à nouveau une branche dans le tronc d'où elle vient, cette opération de fusion est enregistrée comme faisant partie de l'histoire du repository comme ayant été effectuée par moi, et quand. Il est difficile de contester qui a effectué la fusion quand il est juste là dans le journal.
• la création d'un dépôt est une opération insignifiante: mkdir foo; cd foo; git init C'est tout. Ce qui veut dire que je crée un dépôt Git pour tout ce que jour. J'ai tendance à utiliser un référentiel par classe. La plupart de ces dépôts sont en dessous de 1 Mo dans le disque car ils ne stockent que des notes de cours, des devoirs, et mes réponses en LaTeX.
• les formats de fichiers internes du dépôt sont incroyablement simples. Cela signifie réparation est très facile à faire, mais encore mieux parce qu'il est si simple son très difficile d'obtenir 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 lui-même. Et j'ai vu Berkley DB s'est corrompu trop souvent pour faire confiance à mon code au BDB backend de Subversion.
• le format de fichier de Git est très bon à la compression des données, malgré c'est un format très simple. Le dépôt CVS du projet Mozilla est d'environ 3 Go; il est d'environ 12 Go au format fsfs de Subversion. En Git, c'est environ 300 MB.

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

j'aimerais entendre ce que les autres ont à dire après la lecture de ce qui précède?

je mettrais en place un dépôt Subversion. En le faisant de cette façon, les développeurs individuels peuvent choisir D'utiliser des clients Subversion ou des clients Git (avec git-svn ). Utiliser git-svn ne vous donne pas tous les avantages d'une solution complète Git, mais il donne aux développeurs individuels beaucoup de contrôle sur leur propre flux de travail.

je crois qu'il sera un temps relativement court avant Git fonctionne aussi bien sur Windows que sur Unix et Mac OS X (puisque vous avez demandé).

Subversion dispose d'excellents outils pour Windows, tels que TortoiseSVN pour L'intégration dans Explorer et AnkhSVN pour L'intégration dans Visual Studio.

la chose drôle est: J'héberge des projets dans les Repos Subversion, mais j'y accède via la commande git Clone.

s'il vous Plaît lire Développer avec Git sur un Google Code du Projet

bien que Google Code nativement parle Subversion, vous pouvez facilement utiliser Git au cours du développement. À la recherche de "git" svn " suggère que cette pratique est et nous vous encourageons aussi pour l'expérimenter.

utiliser Git sur un dépôt Svn me donne des avantages:

1. je peux travailler distribué sur plusieurs machines, engageant et tirant à partir de et à eux
2. j'ai un centrale backup/public dépôt svn pour les autres à vérifier
3. Et ils sont libres d'utiliser Git pour leur propre

Certainement svn , puisque Windows est-au mieux-un citoyen de deuxième classe dans le monde de la git (voir http://en.wikipedia.org/wiki/Git_(logiciel)#Portabilité pour plus de détails).

mise à jour: désolé pour le lien cassé, mais j'ai renoncé à essayer de travailler ainsi avec URIs qui contiennent des parenthèses. [lien fixe maintenant. - ed]

pas vraiment répondre à votre question, mais si vous voulez les avantages de contrôle de révision distribué - il semble que vous faites - et vous utilisez Windows je pense que vous seriez mieux en utilisant Mercurial plutôt que Git comme Mercurial a beaucoup mieux Windows support. Mercurial a aussi un port Mac.

si votre équipe est déjà familiarisée avec les logiciels de gestion de versions et de sources comme cvs ou svn, alors, pour un projet simple et de petite taille (comme vous le prétendez), je vous recommande de vous en tenir à SVN. Je suis très à l'aise avec svn, mais pour le projet e-commerce que je réalise actuellement sur django, j'ai décidé de travailler sur git (j'utilise Git en mode svn, c'est-à-dire avec un repo centralisé que je pousse et tire pour collaborer avec au moins un autre développeur). L'autre développeur est à l'aise avec SVN, et alors que les expériences des autres peuvent différer, nous avons tous les deux un très mauvais moment embrassant git pour ce petit projet. (Nous sommes tous les deux des utilisateurs de Linux hardcore,si cela importe.)

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

le point principal est que Git est un VCS distribué et Subversion un VCS centralisé. Les VCSs 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 Est le support d'outils. Quels VCS sont mieux pris en charge par les outils que vous prévoyez utiliser?

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

et Git travaille sur Windows uniquement via Cygwin ou MSYS . Subversion supporte Windows depuis le début. Comme le git-solutions pour windows peut travailler pour vous, il peut y avoir des problèmes, les développeurs de Git travaillent avec Linux et n'ont pas de portabilité dans le l'esprit depuis le début. Pour le moment, je préférerais Subversion pour développement sous Windows. Dans quelques années, cela pourrait être hors de propos.

maintenant le monde a un peu changé. Git a maintenant une bonne implémentation sous windows. Bien que je n'ai pas testé sur windows (car je n'utilise plus ce système), je suis assez confiant, que tous les principaux VCS (SVN, Git, Mercurial, Bazaar) ont Windows-implémentation correcte maintenant. Cet avantage pour SVN a disparu. Les autres points (centralisé vs. distribué et la vérification pour le soutien d'outil) restent valables.

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

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

Git n'est pas nativement supporté 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 plutôt que SVN, mais il faut du temps pour franchir le seuil si vous venez de CVS, SVN land.

je choisirais probablement Git parce que je pense qu'il est beaucoup plus puissant que SVN. Il existe des services D'Hébergement de Code bon marché qui fonctionnent tout simplement bien pour moi - vous n'avez pas à faire des sauvegardes ou tout travail 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 l'intégration avec SVN beaucoup mieux.

j'ai utilisé SVN depuis longtemps, mais chaque fois que j'ai utilisé Git, j'ai senti que Git est très puissant, léger, et bien qu'un peu de courbe d'apprentissage impliqué, mais est mieux que SVN.

ce que j'ai noté, c'est que chaque projet SVN, au fur et à mesure de sa croissance, devient un projet de très grande envergure à moins qu'il ne soit exporté. Où as, Git project (avec Git data) est très léger en taille.

en SVN, j'ai traité avec des développeurs, des novices aux experts, et les novices et les intermédiaires semblent introduire des conflits de fichiers s'ils copient un dossier d'un autre projet SVN afin de le réutiliser. Alors qu'en Git, on copie le dossier et ça marche, parce que Git ne le présente pas .dossiers git dans tous ses sous-dossiers (comme SVN).

après avoir beaucoup travaillé avec SVN depuis longtemps, je pense enfin à déplacer mes développeurs et moi à Git, car il est facile de collaborer et de fusionner le travail, ainsi que l'un des grands avantages est qu'un les modifications de la copie locale peuvent être propagées autant de fois que désiré, puis finalement poussées vers la branche sur le serveur en une seule fois, contrairement à SVN (où nous devons propager les modifications de temps en temps dans le dépôt sur le serveur).

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

il s'agit de ceci:

votre développement 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 aurez besoin de créer des ramifications pour différents changements, et puis de fusionner ces changements de nouveau à la ligne principale de développement (connu pour Git comme la branche principale), alors git fera beaucoup plus pour vous.

avez-vous essayé Bzr ?

il est assez bon, connonical (les gens qui font Ubuntu) fait parce qu'ils n'ont pas aimé quoi que ce soit 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 l'installerai 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 on git

SVN semble être un bon choix sous Windows, comme indiqué par d'autres personnes.

si une partie de votre développeur veut essayer GIT, il peut toujours utiliser git-SVN où le dépôt SVN est recréé dans un dépôt GIT. Ensuite, il devrait pouvoir travailler localement avec GIT et ensuite utiliser SVN pour publier ses modifications dans le dépôt principal.

Vous devez aller avec un DVCS, c'est comme un saut quantique 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 construit des constructions nocturnes du projet sur chacune des plateformes.

DVCS tout en étant distribué signifie généralement que vous allez créer un serveur central juste pour les gens de pousser les changements à et à partir.