Qu'est-ce que SVN fait mieux que Git? [fermé]


293

Il ne fait aucun doute que la majorité des débats sur les outils de programmation se résume soit par choix personnel (par l'utilisateur), soit par emphase sur la conception , c'est-à- dire l'optimisation de la conception en fonction de cas d'utilisation particuliers (par le constructeur d'outils). Les éditeurs de texte sont probablement l'exemple le plus important: un codeur travaillant sous Windows au travail et codant à la maison avec Haskell sur un Mac, valorisant l'intégration multiplateforme et du compilateur et choisissant Emacs plutôt que TextMate , etc.

Il est moins courant qu'une technologie nouvellement introduite soit véritablement, manifestement supérieure aux options existantes.

Est-ce en fait le cas des systèmes de contrôle de version (VCS), en particulier des VCS centralisés ( CVS et SVN ) par rapport aux VCS distribués ( Git et Mercurial )?

J'ai utilisé SVN pendant environ cinq ans, et SVN est actuellement utilisé là où je travaille. Il y a un peu moins de trois ans, je suis passé à Git (et GitHub) pour tous mes projets personnels.

Je peux penser à un certain nombre d'avantages de Git par rapport à Subversion (et qui, pour la plupart, sont abstraits des avantages d'un VCS distribué par rapport à un VCS centralisé), mais je ne peux pas penser à un exemple contraire: une tâche (qui est pertinente et qui survient chez un programmeur habituel. flux de travail) que Subversion fait mieux que Git.

La seule conclusion que j'en ai tirée est que je n'ai pas de données - pas que Git est meilleur, etc.

Je suppose que de tels contre-exemples existent, d’où cette question.


3
@jokoon: efficace en termes de quoi? Certainement pas rapide, même Ethernet rapide est lent comparé aux opérations locales.
Maaartinus


4
J'ai toujours pensé que Git était hautement surestimé. C'est une mode, et les programmeurs ne sont pas à l'abri des modes, malgré les nombreuses oppositions à cette idée. Comme tout le monde dans le monde, tout le monde veut le nouveau jouet brillant (Git). Git peut être bon - ou même génial pour certaines personnes - mais il n’a jamais été meilleur que SVN quand on pense de manière objective.
acheté777

3
Je pensais que SVN restait bon à utiliser, la courbe d’apprentissage est bonne alors GIT.
Cheung

5
Cette question a récemment été mise en suspens car elle reposait principalement sur une opinion. Cette classification est fausse; notez que la question était ouverte depuis longtemps; qu'il y a beaucoup de questions sur les vertus du DVCS, et que la question ne demande pas si c'est mieux (opinion), mais qu'est-ce qu'il fait mieux. Les différences ne sont pas des opinions, mais la question de savoir si le produit global est - c'est délicat (mais pas le but de cette question).
Eamon Nerbonne

Réponses:


207

Subversion est un référentiel central

Alors que beaucoup de gens voudront avoir des référentiels distribués pour les avantages évidents de la rapidité et de la multiplicité des copies, il existe des situations dans lesquelles un référentiel central est plus souhaitable. Par exemple, si vous avez un élément de code essentiel auquel vous ne voulez accéder à personne, vous ne voudrez probablement pas le placer sous Git. De nombreuses entreprises souhaitent garder leur code centralisé et (je suppose) tous les projets gouvernementaux (sérieux) sont sous des dépôts centraux.

La subversion est la sagesse conventionnelle

Cela revient à dire que de nombreuses personnes (en particulier les gestionnaires et les responsables) ont la méthode habituelle pour numéroter les versions et considèrent le développement comme une "ligne unique" au fil du temps, codé en dur dans leur cerveau. Sans vouloir vous offenser, la libéralité de Git n'est pas facile à avaler. Le premier chapitre de tout livre Git vous recommande d'effacer tous les idéaux conventionnels de votre esprit et de recommencer à zéro.

Subversion le fait dans un sens et rien d'autre

SVN est un système de contrôle de version. Il a une façon de faire son travail et tout le monde le fait de la même manière. Période. Cela facilite la transition vers / depuis SVN depuis / vers un autre VCS centralisé. Git n’est PAS même un pur VCS - c’est un système de fichiers, il existe de nombreuses topologies pour la configuration des référentiels dans différentes situations - et il n’existe aucune norme. Cela rend plus difficile de choisir un.

Les autres avantages sont:

  • SVN supporte les répertoires vides
  • SVN a un meilleur support Windows
  • SVN peut extraire / cloner un sous-arbre
  • SVN prend en charge le contrôle d'accès exclusif, svn lockce qui est utile pour les fichiers difficiles à fusionner.
  • SVN prend en charge les fichiers binaires et les fichiers volumineux plus facilement (et ne nécessite pas de copier les anciennes versions partout).
  • L'ajout d'un commit implique beaucoup moins d'étapes car il n'y a pas de push / push et vos changements locaux sont toujours implicitement rebasés svn update.

55
"Subversion le fait d'une certaine manière" - je le pensais aussi, jusqu'à ce que je commence à occuper mon poste actuel. Dans mon travail actuel, mon patron, qui affirme ne pas avoir de problèmes de confiance, a configuré le serveur pour qu'il nécessite le verrouillage. Aucune fusion ne se produit dans notre système. Les fichiers sont verrouillés dans le référentiel et personne d'autre ne peut les écrire sans le verrou. Le contrôle de haut en bas, pour ceux dont la constitution l'exige, est définitivement quelque chose que svn fait mieux que git.
Dan Ray

14
L'un des avantages du référentiel central est la facilité de sauvegarde. Si tout le code enregistré est au même endroit et que ce dernier a une sauvegarde hors site, vous ne perdez pas tout si votre bureau est en panne. Avec un DVCS, sauf si vous effectuez des sauvegardes hors site des machines du développeur, vous perdez tout ce qui n'a pas été transféré sur le serveur sauvegardé hors site.
Paul Tomblin

94
Pourquoi ne pas utiliser git de manière centralisée? Vous n'avez qu'un seul référentiel central, et vos développeurs peuvent cloner, tirer et pousser comme ils empruntent, mettent à jour et valident.
David Thornley

29
@PaulTomblin - En fonction du flux de travail, Git peut fournir de meilleures sauvegardes. Par exemple, nous utilisons des dépôts privés github et je pousse souvent mon code vers le haut pour créer des branches. Si mes collègues le savent git fetch origin, chacun d'entre eux dispose d'une sauvegarde de mon code, ainsi que de la sauvegarde fournie par Github. (Nous élaguons régulièrement les branches fusionnées, à la fois localement et sur Github.)
Nathan Long

52
Vous semblez impliquer que central est plus sécurisé pour les grandes entreprises ou les travaux gouvernementaux. Ce n'est tout simplement pas vrai. Si vous avez une copie du code sur votre ordinateur, vous en avez une copie. Peu importe si cela provient d'un serveur central ou d'un système de fichiers central contenant un référentiel DVCS.
John Fisher

131

L'un des avantages de Subversion par rapport à Git peut être que Subversion permet uniquement d'extraire des sous-arbres. Avec Git, le référentiel entier est une unité, vous ne pouvez obtenir que tout ou rien. Avec le code modulaire, cela peut être très agréable comparé aux sous-modules Git. (Bien que les sous-modules Git aient aussi leur place, évidemment.)

Et un petit avantage minime: Subversion peut suivre les répertoires vides. Git suit le contenu du fichier, donc un répertoire sans fichier n'apparaîtra pas.


11
Travailler avec des sous-arbres est IMHO la seule chose que SVN a sur GIT. Point pris, les répertoires vides sont bien, mais pas nécessaires non plus (et peuvent être contournés). Si les sous-modules git et le sous-arbre git étaient moins déroutants, rien ne pourrait empêcher beaucoup de gens de migrer vers GIT. Les autres avantages mentionnés par certaines personnes se résument à la mentalité des développeurs. Par exemple, si vous avez besoin de haut en bas, c'est bien. Je n'aurais pas de travail pour vous cependant.
Jusqu'au

3
C'est drôle de voir que ce sont les seuls types de choses qui peuvent être argumentées en faveur de SVN (et d'autres systèmes de contrôle de version centralisés)
dukeofgaming

1
Pourquoi est-ce drôle? - Les systèmes plus récents tirent les leçons des systèmes plus anciens. RCS sur git présente même un avantage: les fichiers d’historique peuvent facilement être édités à la main et vous pouvez créer des branches par fichier. Mais eolution implique que les fonctionnalités sont perdues ...
johannes

3
J'ai entendu parler d'une société de jeux qui utilise SVN sur GIT pour cette raison - lorsque vous parlez d'un référentiel de plusieurs Go, cela devient soudainement important!
James le

18
A partir de la version 1.8.0 de Git, vous pouvez maintenant utiliser la git subtreecommande pour accomplir exactement cela. Dernier avantage de la subversion mord la poussière :) Détails ici: github.com/gitster/git/blob/… Remarque: Même s'il s'agit d'un lien vers un projet github, git-subtree fait désormais partie de la distribution principale de git.
Carl

51

Je peux penser à trois. Premièrement, il est un peu plus facile de parler, en particulier pour les non-développeurs. Conceptuellement, il est beaucoup plus simple que les options DCVS . Deuxièmement, il y a la maturité, en particulier TortoiseSVN sous Windows. TortoiseHg rattrape vite cependant. Troisièmement, la nature de la bête - une simple image d'un système de fichiers où vous pouvez vérifier des éléments à partir de n'importe quel niveau de l'arborescence - peut s'avérer très pratique dans certains scénarios - comme la gestion de versions d'une variété de fichiers de configuration très différents sur des dizaines des serveurs sans dizaines de référentiels.

Cela ne veut pas dire que tous les développements ne sont pas transférés à Mercurial.


25
Être plus facile à maîtriser est un avantage important, car cela le rend plus susceptible d'être utilisé. SVN est certainement meilleur que pas de contrôle de version, et si quelqu'un est têtu à propos de vieilles méthodes, alors SVN est peut-être le meilleur choix pour lui.
Envoyé le

12
@ jhocking: Je n'aime pas le SVN, mais si quelqu'un me dit: "Je n'aime pas ces nouveautés DVCS, je vais donc rester avec CVS", alors je le recommanderai sans hésiter : c'est la voie facile pour au moins VCS partiellement raisonnable ;-)
Joachim Sauer le

4
@jhocking Les nouvelles façons de faire ne sont pas toujours les meilleures dans toutes les circonstances. Cela rappelle la vieille histoire selon laquelle la NASA dépensait des millions de dollars pour développer un stylo capable d'écrire en 0g. Les cosmonautes par contre sont faits avec des crayons. Parfois, les anciennes méthodes sont meilleures, ENLEVEZ MAINTENANT MON JARDIN!
maple_shaft

25
@ maple_shaft, et parfois ils ne le sont pas. snopes.com/business/genius/spacepen.asp
Peter Taylor

3
Facilement gokked est hautement subjectif et repose en grande partie sur la façon dont vous essayez d’adapter les nouvelles connaissances à ce que vous savez déjà. Votre source d’apprentissage fait également une grande différence. Si vous consultez les pages de manuel, bonne chance. Si vous êtes enseigné par un bon enseignant qui le dit déjà, vous l'aurez fait. J'ai trouvé git très logique après avoir visionné plusieurs bonnes vidéos sur YouTube. Si vous obtenez votre compréhension de la part de quelqu'un qui l'a déjà bien assimilée, tout est plus facile à comprendre.
WarrenT

32
  • Les référentiels SVN sont plus faciles à gérer du point de vue du gestionnaire et de l'administrateur ( ACL + méthodes d'authentification + hotcopy + miroirs + dumps)
  • Les crochets SVN * sont plus faciles à implémenter et à supporter
  • svn:external a plus de puissance et de flexibilité que les sous-modules
  • Les arbres de référentiels basés sur des systèmes de fichiers sont plus faciles à utiliser que les référentiels monolithiques avec séparation logique uniquement
  • SVN a plus d' outils client différents
  • SVN a des interfaces Web utilisables par des tiers, bien meilleures que celles de Git
  • SVN ne casse pas ton cerveau

23
Ne pas briser votre cerveau? Voulez-vous m'apprendre comment fusionner facilement des branches avec des conflits dans SVN?
WarrenT

4
"Meilleurs" outils / interfaces, c'est une cible en mouvement. Les outils s’améliorent des deux côtés. Aucun d'entre nous ne sait quels outils seront disponibles dans plusieurs années. Cette évaluation d'il y a 10 mois pourrait facilement changer avec le temps et pourrait être périmée maintenant. Je préférerais voir des réponses de fond.
WarrenT

6
Conflits d'arbres? Vérifier. Oui ou non à toutes les options? No. Svn est conçu pour exaspérer. Nettoyer la commande de copie de travail? Non, Revert ne peut pas nettoyer les fichiers sans version.
Warren P

1
Tout supprimer et réessayer permettra de nettoyer les fichiers non versionnés.
jgmjgm

J'adore ta dernière idée, Git m'a brisé la tête: '(
Luke

24

J'ai écrit ceci dans un commentaire sur la réponse de quelqu'un d'autre, mais je suppose que cela mérite d'être une réponse en soi.

La configuration soigneusement choisie par mon entreprise pour SVN nécessite un verrouillage au niveau fichier pour modifier le contenu, et n'utilise jamais la fusion. En conséquence, plusieurs développeurs se disputent les verrous, ce qui peut constituer un goulot d'étranglement majeur et il n'y a jamais aucune chance qu'un conflit de fusion se produise.

SVN a définitivement un meilleur contrôle hiérarchique que Git. Dans ma migration de Skunkworks vers Git (demande de pardon plutôt que de permission), j'ai souvent terrifié mon manager en lui faisant croire qu'il n'existait aucun serveur central maître contrôlé par logiciel, auquel nous sommes tous esclaves.


La centralité est une affaire de mythe et non de fait. Personne ne peut m'empêcher de changer quoi que ce soit. Avec un CVC, ils peuvent m'empêcher de changer quelque chose de manière centralisée. Même chose dans un DVD. Le mot commit dans les cvcs confondent commit et push.
Warren P

@ JonathanHenson: ce n'est certainement pas la seule raison pour laquelle Torvalds déteste les SVN. SVN peut être centralisé et peut être un meilleur CVS, mais cela n'en fait pas un bon logiciel. Torvalds déteste CVS / SVN non pas parce qu’ils sont centralisés mais parce qu’il considère qu’ils sont pathétiquement mauvais. Qu'il ait raison ou non, c'est à vous de décider, mais vous avez vu l'immense succès de Linux (et d'Android), qui tourne sur des milliards de périphériques, et de Git, qui prend d'assaut le monde à son tour, je, d réfléchir à deux fois avant de ne pas être d'accord avec lui. La conférence que Torvalds a donnée à Google sur Git il y a des années est incroyable.
Cedric Martin

lol. Votre responsable a raison d'être terrifié par l'absence d'un système de sauvegarde adéquat. Le simple fait de dire "mais sa DVCS pour que quelqu'un en ait une copie" ne vole pas - je sais, quand j'ai vu git utilisé à ma dernière place, ils n'avaient littéralement aucune copie de certaines pensions. Notez que le verrouillage peut être utile dans certaines situations et que git échoue à cet égard - à moins que vous ne possédiez un outil de fusion magique pour les images ou d’autres fichiers binaires. git ne fonctionne vraiment que pour les fichiers texte.
gbjbaanb

22

Mes raisons:

  • la maturité - à la fois le serveur et les outils (par exemple, TortoiseSVN)
  • simplicité - sans étapes, un commit est un commit. Les DVCS tels que Git et Mercurial impliquent un commit, puis un push.
  • traitement binaire - SVN gère les exécutables et les images binaires mieux que Git / Hg. Particulièrement utile avec les projets .NET car j'aime vérifier les outils liés à la construction dans le contrôle de source.
  • numérotation - SVN a un schéma de numérotation de validation lisible, utilisant uniquement des chiffres - il est plus facile de suivre les numéros de révision. Git et Hg font cela très différemment.

1
"Commencer le schéma de numérotation" n'est possible que si vous avez des lignes principales canoniques. Sinon, lequel obtient la numérotation majeure?

1
+1 le nombre dans svn. Ce numéro est unique. il existe des outils pour utiliser ce numéro dans le fichier app-numéro-version xx.yy.zz.12882, où 12882 correspond au numéro de version svn. S'il y a un problème de production, vous pouvez demander le numéro de version et le numéro de révision exact pour lequel le logiciel a été
compilé

22

J'apprécie le fait que vous recherchiez de bonnes informations, mais ce type de question invite simplement à dire: "Je pense que Git a tant de succès, et svn teh suxorz!" réponses.

J'ai personnellement essayé de trouver Git un peu trop pour ma petite équipe. Cela semblait idéal pour une grande équipe distribuée ou un groupe d'équipes dispersées géographiquement. Je comprends très bien les avantages de Git, mais le contrôle de la source, à mon avis, ne me garde pas éveillé la nuit.

Je suis un chasseur de cerfs et lorsque mes amis et moi-même sortons, ils sont armés jusqu'aux dents, hérissés de munitions et de matériel de haute technologie. Je me présente avec un seul fusil, sept balles et un couteau à couteau. Si j'ai besoin de plus de sept tours, je fais quelque chose de mal et je le fais aussi bien que quiconque.

Ce que j'essaie de dire, c'est que si vous êtes une petite équipe travaillant sur un projet de taille moyenne à petite et que vous connaissez déjà SVN, utilisez-le. C'est certainement mieux que CVS ou (frémir) SourceSafe , et cela ne me prend pas plus de cinq minutes pour mettre en place un référentiel. Git peut parfois être exagéré.


3
Vraiment? Ensuite, je vous suggère de regarder fossile .
Spencer Rathbun

7
ne sonnons pas l'alarme à la moindre possibilité de controverse. Les sujets importants sont souvent les plus controversés et les plus susceptibles d’invoquer des points de vue très partagés. Donc, "ce genre de question" est important et la possibilité d'une réponse en dehors des limites n'est pas plausible de ne pas l'afficher. Je suppose que les utilisateurs de ce site sont des adultes. De plus, la façon dont mon Q était formulé était, si ce n’était neutre, respectueuse des gens de la subversion - les réponses sensibles à mon Q devront indiquer les avantages de la subversion par rapport à git, et non l’inverse.
Doug

@SpencerRathbun, merci! Je vais devoir regarder ça. Ce n'est pas tellement que j'aime svn que j'ai un dégoût pour git.
maple_shaft

10
@Spencer - Au contraire, en tant qu'utilisateur des deux gitet hg, je suggérerais mercurial est destiné à tous ceux qui pensent que gitc'est trop. TortoiseHG serait très familier à toute personne habituée à TortoiseSVN (elle partage même les mêmes superpositions d’explorateur sur Windows). C'est certainement beaucoup plus facile que VSS et je serais surpris qu'il faille plus de quelques secondes pour configurer un dépôt HG, valider l'état initial et le cloner sur un lecteur partagé.
Mark Booth le

@ MarkBooth Comme indiqué dans la question initiale, je pense que c'est une question de désirs et de besoins. Sur mon lieu de travail actuel, il n'y avait pas de prise en pension avant mon arrivée. J'avais besoin de quelque chose qui comprenne tout ou presque tous les outils de projet que je voulais, qui sont faciles à utiliser, qui gardent tout au lieu de deltas et qui fonctionnent par équipes de 1 ou 2 personnes.
Spencer Rathbun

20

Tout cela est relatif et, comme dit maple_shaft, si l’on travaille pour vous, ne changez pas!

Mais si vous voulez vraiment quelque chose , je dirais que c'est peut-être mieux pour les concepteurs, les programmeurs Web et autres - cela gère un peu mieux les images et les fichiers binaires.


2
Comment SVN les gère-t-il mieux? Git considère chaque fichier comme un BLOB.
WarrenT

4
@WarrenT à cause des flux de travail, avec git vous branchez et fusionnez beaucoup (ou pourquoi vous ne l'utilisez pas) et vous ne pouvez tout simplement pas fusionner des fichiers binaires. Par conséquent, vous mettez souvent la propriété "needs lock" sur les fichiers binaires de SVN.
gbjbaanb

1
Certains fichiers binaires peuvent (théoriquement) être fusionnés, par exemple un document ODT.
Donal Fellows

18

Facilité d'utilisation. Ce n'est pas vraiment le mérite de Subversion, mais bien celui de TortoiseSVN . TortoiseGit existe, mais il reste encore beaucoup de chemin à parcourir pour égaler TortoiseSVN.

Si vous demandiez ce que Git fait mieux que SVN, je répondrais GitHub . C'est drôle de voir à quel point les outils tiers font une telle différence.


1
Assembla (pour tout SCM pris en charge - SVN dans la liste) est meilleur que github, je pense
Lazy Badger

il y a aussi les programmes smartgit, GitXL, etc. maintenant, des programmes qui simplifient l'utilisation de git
wirrbel

@LazyBadger, Je n'en ai jamais entendu parler.
Pacerier

16

Lorsque vous n'avez pas besoin de créer de branches et de fusionner , SVN (avec TortoiseSVN sous Windows) est très facile à comprendre et à utiliser. Git est trop complexe pour les cas simples, car il essaie de faciliter la création de branches / fusions.

(De nombreux petits projets ne doivent jamais créer de branches si ils sont bien gérés. Git est destiné aux cas complexes. La plupart de la documentation Git suppose donc que vous devez effectuer des opérations complexes telles que la création de branches et la fusion.)


8
L'utilisation des gitbranches et des fusions n'est pas une opération complexe J'utilise même des branches dans un projet individuel, même lorsqu'il n'y a aucune exigence de version multiple. Garder du travail, vous ne pouvez pas continuer pour le moment dans une branche, branchez-vous lorsque vous découvrez qu'il est bien préférable d'essayer une autre solution ... Cependant, je conviens que gitc'est un peu plus difficile à apprendre.
Maaartinus

Chaque fois que vous avez besoin de faire des corrections de bugs dans les anciennes versions, vous devez créer des branches et des fusions.

1
Pourquoi les gens ne considèrent-ils pas l'idée que mercurial est plus facile que svn ou git?
Warren P

Je pense en partie que, dans la mesure où SVN n’avait jusqu’à récemment pas pris en charge la création de branches et la fusion sans coût très élevé, les programmeurs ont pu mieux se prendre en main face aux gestionnaires quand ils voulaient continuer à changer les choses. Un outil doit fonctionner dans le cadre des politiques d'une entreprise et permet également de définir les politiques d'une entreprise.
Ian

14

Eh bien, mon grand-père pourrait utiliser SVN sur son ordinateur Windows XP, mais il aurait du mal à utiliser Git. Peut-être est-ce plus un accomplissement de TortoiseSVN sur TortoiseGit , mais je pense qu'il est plutôt lié au fait que Git est intrinsèquement plus puissant et donc plus complexe, et il serait inutile de stupide vers le bas au même niveau.

Maintenant, cela n'a pas vraiment d'importance pour mon grand-père, car il n'a pas encore programmé. Cependant, j’étais une fois dans une équipe où nos graphistes utilisaient également notre contrôle de source.

Et ce sont des gens qui s'attendent simplement à ce que leurs outils fonctionnent (moi aussi, mais j'ai une chance réaliste de les faire fonctionner en cas d'échec) et à être intuitifs. Mis à part le fait qu'il aurait été très difficile de les amener à s'entendre avec un DVCS , il y avait peu à gagner. Et comme il n'y avait que deux programmeurs dans l'équipe, il était logique que nous nous en tenions également à SVN.


git est l'approche la plus "philosophique" du contrôle de version. vous commencez à penser à la sémantique des commits, des branches, etc. Ainsi, les personnes qui veulent utiliser un VCS comme outil de "sauvegarde" et de distribution ont plus de difficultés, mais ce n'est pas si difficile
girrbel

11

Au travail, je ne pouvais pas passer des développeurs SVN à un DVCS pour deux raisons:

  • Extractions partielles (comme seulement trois dossiers de profondeurs différentes dans l'arborescence du projet)
  • Verrouillage de fichier (rapports au format binaire)

8
  • Sens de la sécurité lors de l'exécution d'un 'svn commit'. Étant donné que les commits sont envoyés au serveur, je ne peux faire aucun bazar qui effacera mes modifications après leur validation. Dans git, les commits sont locaux, donc, jusqu'à ce que j'appuie, un 'rm -rf' errant et tout est fini.
  • Les commits sont authentifiés. Par défaut, je peux dire que je commets en tant que personne.
  • Moins de commandes à apprendre pour un usage quotidien. 'svn checkout', 'svn up' et 'svn commit' vous mèneront loin.
  • Les caisses partagées fonctionnent beaucoup mieux. Lorsque vous vous engagez, il vous demande votre nom d'utilisateur / mot de passe, vous n'avez pas à vous souvenir de passer certains arguments en ligne de commande. Parfois, au travail, nous avons une machine partagée avec une extraction svn partagée de certains projets. Quelqu'un pourrait dire "Bob, tu peux regarder ça sur cette machine" et il le peut, et il peut valider ses modifications en tant qu'utilisateur, sans aucune erreur.
  • Disposition du référentiel. Vous pouvez avoir un projet parapluie et des sous-projets et choisir ce qu'il faut vérifier quand.
  • Les numéros de révision sont des entiers incrémentants.
  • Conçu pour le flux de travail du référentiel central.

+1 pour le problème d'authentification. Les commits Git doivent être signés et les signatures doivent être vérifiées, ce qui est difficile.
Christian

6

D'autres personnes ont posté de bonnes réponses, mais qu'en est-il des autorisations? En utilisant Subversion sur SSH, vous pouvez créer un compte distinct sur votre serveur pour SVN. Différents développeurs peuvent avoir différents accès à différentes parties du référentiel. GIT peut-il faire ça? Je suppose qu'il y a de la gitolite, mais elle ne me semble pas aussi souple ni robuste, et je ne connais personne qui l'utilise réellement.


2
D'autres ont mis cela en avant en mentionnant le "contrôle de gestion descendant". Ceci est un élément clé pour mon environnement - certaines zones de nos référentiels doivent être verrouillées en lecture seule ou même en absence de lecture pour certains groupes d'utilisateurs. Nous devons également avoir un emplacement unique sur lequel nous pouvons pointer et dire "ceci est la copie maîtresse faisant autorité, si votre copie ne correspond pas à ce qui est ici, ce n'est pas officiel."
Alroc

1
dépositaire béni du chef de projet et des lieutenants donne le contrôle sur qui peut s’engager. Le repo Git publié sur un serveur compatible http-auth (utilisant les mêmes modules apache que svn fait) effectue l'authentification et indique qui peut cloner / extraire quoi. Certes, les autorisations ne sont pas aussi détaillées que svn par répertoire, mais pour moi, cela ressemble plus à de la micro-gestion qu’à un besoin réel.
Hubert Kario

@HubertKario - cela soulève la question "Vos meilleurs programmeurs devraient-ils passer leur temps à vérifier le code des autres?" En fait, la réponse à cette question m'intéresse tellement que je l'ai postée ici: programmers.stackexchange.com/questions/181817/…
GlenPeterson

5

La vitesse. Il faut parfois 10 ou 15 minutes pour cloner un grand référentiel Git, tandis qu’un référentiel de taille similaire prend environ deux minutes à vérifier.


6
Mais la caisse / le clonage est une opération rare. Dans la plupart des scénarios, git est plus rapide que subversion.
11h16

5
git clone --depth=1est votre ami si vous ne vous souciez pas de l'histoire
Hubert Kario

4

Je poste ceci comme une réponse plutôt que comme un commentaire.

Je reconnais que les DVCS sont tout à fait dans la tendance en ce moment, mais je vais essayer de dire pourquoi.

Les systèmes DVCS sont meilleurs parce que, comme beaucoup de gens l’ont dit, "c’est ainsi que nous aurions dû travailler depuis le début". C'est vrai, vous pouvez faire avec un DVCS ce que vous utilisiez avec SVN, donc d'une manière qui rend SVN obsolète.

Cependant, tous les projets logiciels ne sont pas aussi performants qu’ils obtiennent:

  • Les projets à long terme ont beaucoup profité de DVCS, car ils utilisent moins de temps système, permettent une meilleure gestion (branchement, etc.) et sont largement pris en charge par des hôtes comme Google Code et github.

  • Ces projets ne sont pas les seuls, il existe d'autres types de projets en cours de développement dans des entreprises sans aucune aide du monde extérieur ou d'Internet: tout se fait en interne, souvent à court terme. Un bon exemple: un jeu vidéo. Le code évolue rapidement.

Dans ce dernier cas, les développeurs n'ont pas vraiment besoin de branches ou de fonctionnalités sophistiquées que DVCS peut offrir, ils souhaitent simplement partager le code source et les actifs. Le code qu'ils créent n'est pas susceptible d'être réutilisé, car il y a une date limite. Ils s'appuient sur SVN plutôt que sur un DVCS pour plusieurs raisons:

  • Les développeurs ont des machines appartenant à l'entreprise et cela pourrait changer rapidement. Configurer un repo est une perte de temps.
  • Si ces personnes ne disposent pas de leur propre machine, elles risquent moins de travailler sur le même code source / la même partie du projet. Plus un pour les données centralisées.
  • Les vitesses de réseau et les grosses sommes d'argent permettent l'utilisation d'un serveur centralisé qui gère tout le SVN, c'est une mauvaise pratique mais des sauvegardes sont effectuées, etc.
  • SVN est simplement plus simple à utiliser, même si ce n’est pas le bon sens: synchroniser des fichiers sur des pairs sans redondance n’est pas un problème simple, et "faire les choses correctement" ne peut tout simplement pas arriver à temps si vous voulez toujours que ce soit parfait.

Pensez à la machine de l'industrie du jeu et à la façon dont SVN permet de gagner du temps. les gens communiquent beaucoup plus sur ces projets parce que les jeux concernent la programmation répétitive et le code adaptatif: rien n’est difficile à coder, il faut le faire correctement, dès que possible. Les programmeurs sont embauchés, ils codent leur partie, la compilent, la testent un peu, s’engagent, c’est fait, les testeurs de jeux s’occuperont du reste.

Les DVCS sont conçus pour Internet et pour des projets très complexes. Les SVN sont destinés aux projets d’équipe restreints, à court terme et à court terme. Vous n'avez pas besoin d'apprendre beaucoup de SVN, c'est presque un FTP avec un diff idiot.


Pouvez-vous expliquer l'exemple de l'industrie du jeu?
johnny

3

Subversion et Git encouragent tous deux des approches particulières (et très différentes) de développement et de collaboration. Certaines organisations tireront davantage parti de Git, tandis que d'autres tireront davantage profit de Subversion, en fonction de leur organisation et de leur culture.

Git et Mercurial sont tous deux excellents pour les équipes réparties et mal organisées de programmeurs professionnels extrêmement compétents. Ces deux outils DVCS populaires encouragent les petits référentiels, la réutilisation entre développeurs se faisant par le biais de bibliothèques publiées avec des interfaces (relativement) stables.

Subversion, en revanche, encourage une structure de gestion plus centralisée et étroitement couplée, avec davantage de communication entre les développeurs et un plus grand degré de contrôle organisationnel sur les activités de développement quotidiennes. Au sein de ces équipes organisées de manière plus compacte, la réutilisation entre développeurs a généralement lieu via des bibliothèques non publiées avec des interfaces (relativement) instables. TortoiseSVN permet également à Subversion de prendre en charge des équipes multidisciplinaires composées de membres qui ne sont pas des programmeurs professionnels (ingénieurs en systèmes, ingénieurs en algorithmes ou autres spécialistes).

Si votre équipe est distribuée, avec des membres travaillant à domicile ou provenant de nombreux sites internationaux différents, ou s’ils préfèrent travailler seuls et en silence, avec peu de communication en face à face, un DVCS comme Git ou Mercurial sera un bon choix. ajustement culturel.

Si, en revanche, votre équipe est située sur un site unique, avec une approche active du développement en "équipe" et de nombreuses communications en face-à-face, avec un "buzz" en l'air, SVN peut être un élément clé. meilleur ajustement culturel, en particulier si vous avez beaucoup d'équipes multidisciplinaires.

Bien sûr, il est possible de configurer Git et Hg (puissants et flexibles) pour qu’ils fassent à peu près tout ce que vous voulez, mais c’est définitivement plus de travail et ils sont nettement plus difficiles à utiliser, en particulier pour les membres de l’équipe qui ne serait naturellement pas enclin à utiliser quelque forme de contrôle de version que ce soit.

Enfin, je trouve également que le partage de fonctionnalités utilisant le développement de bibliothèques "à chaud" sous Svn (avec une approche basée sur des tests et sur des tests) permet un rythme de développement coordonné difficile à atteindre avec une équipe plus distribuée et faiblement couplée.



1

Il existe actuellement deux grandes tendances dans le contrôle de version. Distribution et intégration .

Git est excellent en décentralisation.

SVN a construit de nombreux outils qui s’y intègrent. Il est courant de configurer votre serveur SVN de manière à ce que, lorsque vous enregistrez une correction, vous mentionnez le numéro de bogue dans le commentaire d’archivage. Il définit automatiquement cela, mais dans un état "en cours de test", et alerte le testeur assigné dont il a besoin. Regarde ça. Ensuite, vous pouvez marquer une version et obtenir une liste de tous les bogues corrigés dans cette version.

Les outils qui font cela avec SVN sont matures et utilisés tous les jours.


-1

Dans Subversion, vous pouvez modifier les messages de journal (également appelés "messages de validation") une fois la validation effectuée et envoyée. Pour la plupart des applications pratiques, cela est impossible par conception dans les systèmes décentralisés, y compris git. Bien sûr, en git, vous pouvez faire "git commit --amend", mais cela ne vous aide pas après que votre commit ait été poussé ailleurs. Dans SVN, lorsque vous modifiez le message de journal, vous le créez dans le référentiel central que tout le monde partage, afin que tout le monde obtienne la modification sans changer l'identifiant de la révision.

La modification des messages de journal après coup est souvent très utile. En plus de réparer une erreur ou une omission dans un message de journal, il vous permet de faire des choses comme mettre à jour un message de journal pour faire référence à un futur. validation (telle qu'une révision qui corrige un bogue ou termine le travail introduit dans la révision actuelle). .

Soit dit en passant, il n'y a pas de danger de perdre des informations. Les points d'ancrage pre-revprop-change et post-revprop-change peuvent enregistrer l'historique des anciens messages si vous êtes vraiment inquiet, ou envoyer des e-mails avec le diff de message de journal (c'est plus courant, en fait), de sorte qu'il y piste d'audit.


1
c'est aussi facile à faire en git; par exemple, git --amend; Vous pouvez également le faire via git reset --soft HEAD ^, qui ne fait que revenir en arrière, mais ne modifie pas l'index et vous permet de modifier / réécrire le message de validation.
Doug

Salut doug Oui, vous pouvez le faire pour votre référentiel local, mais je parle d'une fois que vous avez poussé le changement ailleurs - "git commit --amend" ne vous aide pas beaucoup alors. Dans SVN, vous pouvez modifier le message de journal sur le serveur central, précisément parce qu'il existe un concept de serveur central. C'est ce que je voulais dire par "impossible par conception dans les systèmes décentralisés". Je vais modifier ma réponse pour que cela soit plus clair.
Karl Fogel

1
J'adore la façon dont "on peut jouer avec l'histoire" est prétendument une fonctionnalité . Je considérerais cela comme un bug si ce n'était pas intentionnel.
cHao
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.