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


321

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


5
Oui, git fonctionne sur Mac. Si vous utilisez macports pour l'installer, il installera même un frontal mac pour les interfaces de validation et de navigation.
Seth Johnson


3
@Andre - parce que vous pouvez utiliser MonoDevelop - je passe de Vault à SVN pour pouvoir développer des logiciels .NET sur mon Mac ou PC. Il n'y avait pas de client pour Vault mais il y en avait pour SVN :-)
schmoopy


4
Github / bitbucket + sourcetree = paradis! - sourcetreeapp.com
thecodeassassin

Réponses:


253

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.


24
Pourrait également jeter un œil à Hg (Mercure)
Joel

24
Les choses se sont beaucoup améliorées depuis octobre 2008. Vous pouvez installer TortoiseGit, récupérer la dernière version portable de MSysGit et dire à TortoiseGit où le trouver. Je viens de déplacer mon gros dépôt svn vers git aujourd'hui parce que le mauvais support de changement de nom de svn m'a finalement rendu assez fou.
Nous sommes tous Monica

4
Sur 2 ans, nous avons maintenant de bons outils Windows. Actuellement, j'utilise des netbeans avec MSysGit. J'ai également eu de la chance avec TortoiseGit. Je pense que c'est assez bon pour être utilisé en production. Considérer à quel point il est difficile de gérer des conflits simples dans subversion git est une énorme amélioration.
Keyo

24
Nous utilisons beaucoup Git sur Windows et l'avons depuis longtemps. Git est absolument fantastique sur Windows.
Charlie Flowers

13
@Oli serait bon de mettre à jour votre réponse (en particulier sur le client Windows git) en fonction des commentaires ici et de votre expérience. La réponse actuelle semble biaisée maintenant que 2-3 ans se sont écoulés depuis sa rédaction.
Amit

111

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.


9
D'un autre côté, j'ai eu pas mal de problèmes avec git sur windows, cela a fait des choses vraiment étranges à mon repo. Et j'utilisais la version la plus récente de cygwin (c'était il y a environ un mois).
Roman Plášil

7
@Roman: eh bien, le port Cygwin n'est presque pas la même chose que le port natif win32. Je m'attends à ce que le port Cygwin soit beaucoup moins bien testé ...
SamB

49
"plus de fonctionnalités que vous n'en utiliserez probablement jamais" est un drapeau rouge dans mon livre
BT

26
@ BT "drapeau rouge", je ne suis pas d'accord. Je me surprends souvent à souhaiter qu'il y ait un moyen de faire quelque chose et après un peu de recherche, je découvre qu'il y a quelques commandes que je ne connaissais pas à ce sujet. J'utilise également GIT sur ma machine Windows et je n'ai pas encore rencontré de problème majeur.
testing123

@ testing123 mais ce ne sont pas des fonctionnalités "que vous n'utiliserez probablement [jamais]" car vous avez fini par les utiliser.
mulllhausen

77

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


10
Je ne suis pas en désaccord avec vous sur le fait que git et svn sont fondamentalement différents, mais je ne suis pas d'accord sur bon nombre de vos points. svn a peut-être été écrit pour remplacer les cv, mais ils ne sont en aucun cas liés autrement, tandis que les cv ont commencé en tant que scripts au-dessus de RCS, il y a donc une relation directe. Pourtant, la personne que vous citez a tout à fait raison, les deux gèrent fondamentalement les révisions des fichiers, la mise en œuvre et le processus dans lequel cela se produit (ou comment cela se fait) sont des détails de mise en œuvre. C'est comme la différence entre CRC et SHA1, fondamentalement très différents mais ils font la même chose.
Erik Funkenbusch

37

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.


6
"Veuillez me corriger s'il existe un autre VCS qui gère efficacement les fichiers de 500 Mo +" - Perforce bien sûr!
james creasy

8
Perforce = non gratuit. De plus, Perforce n'est pas disponible pour toutes les plateformes.
WhyNotHugo

4
Pourquoi ne pas mettre le dépôt SVN À L'INTÉRIEUR des conteneurs truecrypt? Vous pouvez également créer un tunnel via ssh et configurer le serveur pour stocker ce dépôt particulier dans un autre fichier truecrypt. Cela a l'avantage supplémentaire que vous pouvez effectuer des extractions partielles de ce dépôt.
WhyNotHugo

1
@Hugo pour autant que je sache, le client Perforce est disponible pour Windows, Unix, les variantes Linux, Mac, Amiga, BeOS, Cygwin, HPUX, IBM AS / 400, OS / 2, DEC VMS et Novell File Server. Y a-t-il une plateforme pertinente manquante dans la liste?
eis

1
Oui, OpenBSD (et je le savais par expérience, je n'avais pas besoin de google ça). Je suppose que cela ne fonctionnera pas non plus sur maemo, bien que je puisse me tromper (et oui, j'utilise git sur maemo).
WhyNotHugo

25

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?


15
Git est incroyablement rapide sur certaines opérations, principalement parce que l'opération n'affecte que votre référentiel local. Un archivage Git, par exemple, ne doit pas être comparé à juste titre à un archivage SVN, car un archivage SVN est également une poussée du changement vers un référentiel intermédiaire pour le reste de votre équipe. Cela nécessite un accès au réseau, et la comparaison de l'engagement sans réseau de Git à un transfert réseau sent la comparaison inappropriée. Si vous vous engagez, puis perdez le disque dur, avec Git, vous avez perdu votre changement. C'est bien si c'est ce à quoi vous vous attendez, mais ce n'est pas prévu dans les SCM non distribués.
Edwin Buck

1
@EdwinBuck Ne tenant pas compte de ce que Waqar a fait, dans les tests même avec le temps réseau pris en compte, git a tendance à être plus rapide: git-scm.com/about/small-and-fast
Sqeaky

Votre point «Créer un référentiel est une opération banale» est extrêmement important, en particulier sous Windows: par rapport à SVN, il est beaucoup plus facile de simuler rapidement un groupe de référentiels distribués interconnectés, tous connectés à un référentiel central (--bare) avec Git que c'est de faire l'analogue avec SVN (installer l'application serveur Windows SVN, etc.). Aussi (bizarrement), je trouve que Git est plus cohérent entre les systèmes d'exploitation: la ligne de commande est très bien conçue et donc suffisante la plupart du temps (et pratiquement identique entre les systèmes d'exploitation) par rapport à diverses applications client / serveur natives SVN ...
Shivan Dragon

1
L'article wiki auquel vous vous référez est plein d'erreurs. Par conséquent, votre réponse est fausse. Voté. Il y a une page de discussion sur le wiki qui fait référence à svnvsgit.com expliquant pourquoi la comparaison est incorrecte.
bahrep

Incroyablement rapide? J'ai déplacé le projet ciforth d'un cvs local vers github. Il s'agit d'un projet simple mais qui contient un grand fichier source principal de 10 000 lignes. Si j'essaie d'utiliser le blâme sur ce fichier, Github tombe dans un temps mort. Surtout si l'on ne se contente pas de dire vite et insiste pour utiliser un tel qualificatif, ce n'est pas une opinion équilibrée, ce qui me rend méfiant à propos de tout ce que vous dites. Groetjes Albert
Albert van der Horst

12

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.


11

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

3
Juste une note: depuis juillet 2011, Google Code prend en charge Git nativement.
Jeremy Salwen

9

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.


9

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.


8

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]


1
Pour info: placez l'URL entre crochets ou remplacez les parenthèses par% 28 et% 29.
PhiLho

1
Le codage URL fonctionnera-t-il pour la syntaxe [] ()?
Hank Gay

16
Il s'agit d'un FUD incorrect. Git est fantastique sur Windows. Et SVN est assez mauvais partout.
Charlie Flowers

6
Pour tous ceux qui me déprécient, veuillez revenir en arrière et regarder les commentaires des développeurs de circa 2008: il est assez clair que Linus et le gang ne se souciaient pas de prendre en charge Windows. C'est très bien: je ne veux pas vraiment le faire non plus, et mon logiciel n'est pas aussi complexe que VCS qui attend un comportement POSIXish du système de fichiers. Il semble injuste, cependant, de qualifier ma déclaration de FUD si vous regardez le contexte.
Hank Gay

2
Peut-être qu'en 2008, git était mauvais sur Windows, mais j'utilise msysgit depuis 2009 et cela fonctionne parfaitement. Cela inclut gitk, l'équivalent de bureau hors ligne de GitHub.
Dan Dascalescu

8

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'ai bon espoir que l'horizon de non-pertinence sera beaucoup plus court que quelques années.
Greg Hewgill

Oui, ce ne sera peut-être qu'un an. Git a une communauté de développement dynamique. Mais la subversion aussi. Dans un an ou deux, vous devrez revoir les deux pour répondre à cette question.
Mnementh

1
C'est maintenant un an ou deux plus tard. À quoi ça ressemble? :)
Merlyn Morgan-Graham

3
Il manque à Git une extension du modèle SCM distribué aux autres phases du pipeline de développement logiciel. Nous n'avons pas de bon modèle pour les systèmes de construction de versions distribuées, les tests automatisés distribués, le contrôle qualité, le contrôle des versions, etc. En tant que tel, Git offre plus au développeur et moins au processus de développement logiciel. Toutes les implémentations de Git bénissent finalement un dépôt pour être le central, ce qui simplifie les capacités Git les plus intéressantes en fac-similés de SVN.
Edwin Buck

1
@hibbelig Git n'a pas de référentiel central, chaque référentiel est effectivement (en raison de sa conception distribuée) égal. Cela signifie que vous retravaillez votre pipeline de production pour éventuellement gérer tous les référentiels de manière égale, ou que vous bénifiez artificiellement un référentiel pour qu'il ait le statut "artificiellement élevé" (alias le référentiel central ). Si vous faites le premier, personne ne sait beaucoup sur la construction de pipelines parallèles où une version pourrait provenir du bureau de n'importe quel développeur, si vous faites le dernier, la promesse d'un traitement distribué est trompée par une convention centralisée.
Edwin Buck

6

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

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


1
Cependant, cela change rapidement. SVN perd des parts de marché, tandis que GIT gagne: Par exemple: wikivs.com/wiki/Git_vs_Subversion#Popularity ou programmers.stackexchange.com/questions/136079/…
Zelphir Kaltstahl

@Zelphir: Je n'appellerais pas 7 ans rapidement, mais oui, GIT gagne des parts de marché et est particulièrement bien meilleur pour fusionner des fichiers.
Burkhard

4

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.


8
Définissez «nativement». msysgit fonctionne très bien
Milan Babuškov

4

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.


4

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?


Je n'appellerais aucun développeur qui a copié un dossier contrôlé par SVN dans un autre projet pour le réutiliser et ne s'attendait pas à des problèmes évidents «intermédiaires». Je les appellerais novices. Oui, vous avez raison, cela est dû au sous-dossier .svn qui indique à SVN à quel référentiel appartiennent les fichiers. Si l'utilisateur supprimait ce sous-dossier .svn, il pourrait alors importer le dossier dans le nouveau projet SVN. Je suis toujours avec SVN moi-même, mais mes besoins sont peu nombreux. GIT est idéal pour les grands projets.
dyasta

3
Les derniers clients svn n'ont pas besoin d'un .svndossier dans chaque sous-répertoire. Cela «corrige» l'erreur de copie avant qu'elle ne se produise.
Edwin Buck

4

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.


3

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é ...


Cependant, le support de Windows nécessite vraiment un peu de travail. Pas tellement que je ne l'ai pas utilisé avec plaisir pour toute ma programmation récente sous Windows (dont j'ai fait pas mal), ou quoi que ce soit, mais quand même ...
SamB

C'est presque 100% du temps avec OS, que les gens "l'ont fait [n'importe quel logiciel] parce qu'ils n'aimaient rien d'autre sur le marché".
WhyNotHugo

@Hugo Avec l'open source, s'ils aimaient autre chose sur le marché, ils y contribueraient au lieu de créer quelque chose de nouveau.
décédé

Ce n'est pas du tout une réponse à la question
Albert van der Horst

@AlbertvanderHorst Non, ce n'est pas le cas, la question a été répondue dans les jours du Far West alors que personne ne savait mieux et a proposé une alternative. On peut dire que dans ma hâte, il semble que j'ai également mal orthographié le nom de Canonical. Honte sur moi!
Omar Kooheji

3

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.


1
Oui, cela fonctionne à merveille. Je l'ai installé via MacPorts et je l'utilise quotidiennement.
Greg Hewgill

Cela fait. C'est génial sur n'importe quel système POSIX (Unix, Linux, Solaris, BSD, etc.). C'est vraiment juste Windows où se situe le problème.
Oli

et git-gui et gitk fonctionnent probablement de la même manière sous OS-X que sous Linux et Windows. Contrairement à tortoiseSVN, quel AFAIK est uniquement Windows?
David Schmitt

@David Schmitt: eh bien, tortoisesvn.tigris.org l' appelle une "extension Windows Shell pour Subversion", donc je suppose que oui ;-).
SamB

@Robert: quelle a été votre expérience avec git sur OS X?
David Schmitt


2

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.


1

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.