Réponses
Trop de publicités?
D'une part, SVN intégration (IDE, cadres de travail, les wikis, ...) est très mature, ainsi que ses Interfaces utilisateur et du code dans les navigateurs (même si DVCS comme Git et Mercurial progrès tous les jours).
D'autre part, l'introduction d'un DVCS dans un environnement d'Entreprise n'est pas une tâche triviale:
- Certaines exigences ne sont pas facilement rencontré (en termes de sécurité et de contrôle d'accès, de l'administration et de la restriction d'accès)
- Le DVCS paradigme est plus complexe à comprendre, avec beaucoup de avantages et des inconvénients.
- Vous avez vraiment besoin de tirer parti de ses nombreux flux de travail au lieu de s'appuyer sur le SVN centralisé.
- La transition de CVC à DVCS est difficile
Juste pour être clair, à l'aide d'un DVCS peut être un choix très valable:
- pour un nouveau projet, où les développeurs ne sont pas à égalité avec les anciens outils ou de processus
- surtout quand les développeurs ne sont pas située géographiquement au même endroit (souvent le cas avec le développement open-source, c'est pourquoi DVCS sont principalement utilisés là-bas).
StackOverflow (pas un projet open source) est à l'aide de Mercurial (voir HgInit, écrit par Joel Spolsky).
Ils ont migré à partir de SVN à un DVCS:
- en partie parce que leurs développeurs sont maintenant partout dans le monde(!)
et aussi parce que la fusion des installations d'un DVCS sont beaucoup plus avancés que dans le SVN.
(dont ils ont besoin pour maintenir parallèlement de nombreuses versions légèrement différentes de leur code de base, entre les sites, StackExchange sites de V1 et V2, la Zone 51, ...)
Voir "différences entre les DVCS et CVC", ou "Quels sont les avantages de l'Mercurial ou git sur le svn pour la ramification/fusion?".-
Pour un environnement d'entreprise (où je suis), toute transition d'aucune sorte n'est pas anodin, car il faut être:
- financés (de l'argent, même si les outils sont gratuits)
- pris en charge (c'est à dire d'avoir les bonnes personnes avec les bonnes compétences)
- intégré (avec des existants, héritage des outils, des Interfaces graphiques, IDEs comme Visual Studio ou beaucoup d'autres, ...)
- administrés (en terme de communes des serveurs, même pour un DVCS)
- documenté (en particulier pour les utilisateurs qui viennent avec un CVC comme SVN arrière-plan)
Donc DVCS peut également être très utile dans un environnement d'entreprise:
(Voir "de l'Entreprise taux d'adoption de Git?" ou "Git-Source Basé sur le Contrôle dans l'Entreprise: il est conseillé d'Outils et de Pratiques?".)
Il est (même pour les nouveaux projets) tout simplement pas aussi faciles à mettre en place que dans une plus petite structure ou en open-source environnements.
Est-il considéré comme meilleur pour un seul développeur?
Si quoi que ce soit, Subversion est pire pour un seul développeur (plus difficile à configurer).
Mais une bonne raison de continuer à utiliser SVN est l'inertie. Si SVN fonctionne bien pour votre projet (ou dans votre entreprise), il n'est pas nécessaire de passer par les difficultés de basculement. Il pourrait y avoir des coûts de formation impliqués dans l'enseignement à tout le monde des nouveaux outils (et des nouveaux flux de travail), sans réel avantage.
Je pense que la Subversion fonctionne encore mieux qu'Mercurial et Git pour les gros fichiers comme des actifs médias, des fichiers Photoshop, After Effects, composites, etc. Je me souviens de Linus Torvalds mentionner les gros fichiers comme l'un des très peu de problèmes potentiels avec Git dans ce Google de Parler de Technologie. Mercurial a quelques extensions pour stocker de gros fichiers à l'extérieur d'un référentiel. Il semble donc qu'ils souffrent tous les deux une dégradation des performances et/ou d'autres problèmes dans ce scénario.
Subversion, d'autre part, est utilisé par le Mélangeur Ouvert Projet de Film. Je ne pense pas qu'ils l'utilisent pour stocker les images rendues, car ce serait au moins un peu de gigaoctets de données pour chaque passe de rendu. Mais encore, avec toutes les scènes 3d, objets, plates-formes, des textures, scripts, c'est toujours un grand espace de stockage avec de nombreux fichiers volumineux.
Je peux voir pourquoi, où vous pouvez continuer à utiliser SVN si vous aviez été à l'utiliser pour un long moment. Surtout dans une petite entreprise ou de codage de cercle, la transition à partir de SVN soit git ou Mercurial, quand vous pourriez ne pas être en utilisant l'une des fonctionnalités les plus puissantes d'entre eux, pourrait vous faire préjudiciables à faire de l'interrupteur. Comme l'a souligné par Thilo, une grande entreprise en utilisant SVN va trouver que le changement monumental.
Aussi, je pense que SVN a encore est des endroits, en particulier quand il s'agit de l'enseignement de contrôle de révision. Mais cela, par ma propre expérience de l'apprentissage de SVN à l'université, contre l'enseignement de moi-même git, donc mon avis ne sera pas objectif sur ce point.
Cela étant dit, si vous avez été à partir d'un référentiel à partir de zéro, je ne peux pas penser à une situation où vous pourriez décider de SVN est absolument nécessaire. Peut-être lorsque vous traitez avec les systèmes existants.
ou héritage des utilisateurs ;)
