Pourquoi utiliser SVN? Y a-t-il des pros cachés (sur GIT/Mercurial/Bazaar) là-bas? [dupliquer]

je gère actuellement un service de contrôle de version pour une institution de recherche américaine. Nous ne soutenons pas seulement SVN en plus de Git et Mercurial, mais aussi CVS.

la" caractéristique meurtrière " de SVN parmi nos utilisateurs est des clones étroits. Vous pouvez faire un checkout d'un seul sous-répertoire en profondeur dans une hérarchie, télécharger seulement les fichiers liés à ce répertoire, et encore être en mesure de faire des commits. Git a très récemment donné une variation similaire, mais pas tout à fait aussi utile sur ce fonction appelée caisse sparse (voir aussi Caisse Sparse dans Git 1.7.0? ). Cela vous permet de filtrer votre arbre de travail, mais vous oblige tout de même à télécharger toute l'histoire de l'ensemble du projet, ce qui peut être prohibitif même lorsque de grands binaires ne sont pas impliqués. Attention, le disque est bon marché, et si vous absorbez le coup du clone initial à l'avance, les tirages subséquents sont assez rapides, mais cela n'aide pas les gens qui sont partis en voyage avant qu'ils ne réalisent ils avaient besoin de cloner, et dans tous les cas, même les checkouts épars de Git ne vous laisseront pas démarrer votre arbre de travail cinq niveaux plus bas, donc il a l'air un peu moche.

de plus, les utilisateurs trouvent les fichiers authz plus faciles à écrire que les hooks de commit Git, sont plus à l'aise avec la syntaxe et la méthodologie SVN que n'importe quel DVCS, et peut-être le plus important de tous, a déjà plusieurs milliers de commits de valeur de L'histoire dans SVN . Expériences de migration de la Grande Subversion les dépôts de Git ou de Mercurial ont donné des résultats mitigés, et ce sont des scientifiques qui essaient de faire travailler leurs propres projets, sans donner leur temps pour le développement d'un DVCS.

CVS a toujours un suiveur pour une raison similaire. Imaginez, en tant qu'utilisateur Git, avoir des checkouts clairsemés qui vous permettent également de remaper arbitrairement où les dossiers dans la branche apparaissent dans votre arbre de travail, en utilisant un format qui est versionné avec le dépôt et est distribué avec chaque pull habituel, qui vous permet d'écrire des définitions qui peuvent avoir des groupes qui peuvent inclure d'autres groupes, et qui ne sort que les fichiers nécessaires pour le placement du système de fichiers sur un clone. C'est simple dans les modules CVS, et impossible dans tous les DVCS. Pour tous les péchés de CVS (et croyez-moi, nous en sommes tout à fait conscients, et faire tout notre possible pour décourager les nouveaux projets CVS à moins qu'ils ne puissent absolument pas vivre sans modules), il est impossible de convaincre un groupe utilisant cette fonctionnalité de migrer vers un autre système de contrôle de version.

DVCS logiciel a apporté quelques innovations impressionnantes, mais ils manquent également des choses que certains développeurs tiennent pour acquis. Assurez-vous de connaître à l'avance vos besoins avant d'en choisir un.

en parlant de la société pour laquelle je travaille - la raison la plus importante de L'utilisation de SVN est d'être capable de garder d'énormes fichiers binaires au format propriétaire sous le contrôle des versions. Plus précisément, des bibliothèques de milliers de fichiers CAO. Dans ce cas, il fait logique que le VCS soit basé sur des fichiers comme SVN is, plutôt que sur des informations textuelles comme git.

mettre de côté si oui ou non vous pouvez faire des "check-out" peu profonds avec Git, ou la façon dont il stocke données binaires, le fait est que c'est conçu pour suivre les lignes d'information textuelle flottant autour d'un arbre de code source. En plus de cela, Ce modèle n'est pas adapté au suivi des bibliothèques de données binaires.

honnêtement, c'est à peu près la seule raison solide pour laquelle je le recommande :p

SVN est établi et mature, avec également de maturité de l'outillage.

mis à part les autres choses que les gens mentionnent (grandes quantités de données binaires, matures, stables, etc.), svn est construit sur un modèle hiérarchique classique qui est fondamentalement différent des révisions basées sur les correctifs/changements.

notre société a pris la décision de rester avec SVN parce que ce modèle s'adapte à la façon dont nous gérons notre cycle de libération et de ramification. Nous voyons la progression directe des versions comme une aubaine, pas un fléau. Les mises à jour sont poussés à une centralisation de la dépôt, et certaines révisions considérées comme "stables" sont vérifiées dans un environnement en direct. À tout moment, il est immédiatement clair que l'état de chaque environnement à toutes les parties impliquées. (oui, c'est possible avec git. Même la direction qui ne connaît rien au contrôle des révisions ou au développement de logiciels peut dire: "nous avons aimé comment vous l'aviez quand c'était à la version 2547".

d'autre part, je dois mentionner que j'utilise darcs et git pour des projets que moi et mes amis et les co-utilisateurs de logiciels libres travaillent ensemble, car le modèle distribué basé sur des correctifs fonctionne pour nous. Nous pouvons nous déplacer ad-hoc à travers le calendrier du projet et de choisir toutes sortes de changements.

vraiment L'avantage de SVN, mon entreprise, est sa forte hiérarchie et son accessibilité pour les non-programmeurs qui sont déjà familiers avec les concepts de "logging in" et "download".

Subversion a un avantage lorsqu'un dépôt contient beaucoup de données binaires, qui ne se compriment pas bien. Une vérification Subversion ne prend que la tête, mais git clone toute l'histoire, ce qui peut peser plusieurs gigaoctets. Oui, c'est bien pour le mode avion, mais récupérer le clone initial peut prendre des heures.

les gens utilisent toujours Subversion parce qu'il est conçu en utilisant le premier paradigme à venir pour les systèmes de contrôle de version (centralisé). Passer à distribué (et basé sur le changement au lieu de basé sur la version) peut prendre un certain temps pour s'habituer à (comme vous pouvez le voir dans expérience de Joel ), et tant d'équipes décident de ne pas l'utiliser en raison de la résistance au changement.

l'outillage mercuriel est tout à fait mature, comparable à SVN à mon avis.

bien que svn soit établi / mature, je dois admettre que Kenji Kina a raison: il vit dans le passé avec un modèle de contrôle de version qui est dépassé. J'ai seulement utilisé svn, mais après avoir lu/regardé Linus et Joel parler de DVCS, ça sonne comme une idée brillante. Je pense que Forcément fait quelque chose de similaire.

cela ne veut pas dire que svn est mauvais (ça marche plutôt bien!), mais il est plus facile de gérer votre code et d'avoir des commits plus fréquents avec un DVCS. Parce que si tu casses quelque chose, il est facile à défaire. Si vous branche, il est facile de fusionner. En général, ils ont corrigé beaucoup de maux de tête majeurs que la plupart ont avec Subversion.

si vous n'avez jamais utilisé un autre système de contrôle de version avant, et que vous êtes d'accord pour le déployer vous-même, et écrire du code (et pas des documents ou des images ou des choses pour lesquelles vous n'avez pas besoin de texte/de diffing), faites-vous une faveur et regardez dans les DVCS. Ensuite, vous n'aurez pas besoin d'être rééduqués .

passez par ce http://www.stevestreeting.com/2009/09/28/early-stage-gitmercurialbazaar-evaluation-thoughts/