git vs Subversion - avantages et inconvénients [fermé]

11

Dans l'état actuel des choses, cette question ne convient pas à notre format de questions / réponses. Nous nous attendons à ce que les réponses soient étayées par des faits, des références ou une expertise, mais cette question suscitera probablement un débat, des arguments, des sondages ou une discussion approfondie. Si vous pensez que cette question peut être améliorée et éventuellement rouverte, visitez le centre d'aide pour obtenir des conseils.

Fermé il y a 7 ans .

Je suis un utilisateur de SVN depuis de nombreuses années maintenant et je ne peux pas dire que j'en suis totalement satisfait. Il y a quelques jours, mon partenaire m'a demandé de jeter un coup d'œil à git en disant qu'il "avait de meilleures performances, une fusion et une ramification plus faciles".

J'ai lu des articles de comparaison git vs SVN et je serais heureux si les gens pouvaient résumer les avantages et les inconvénients en utilisant les deux systèmes de contrôle de version.

Maintenant, je regarde des gens qui sont passés d'un système à un autre et qui entendent des opinions subjectives.

Je sais par moi-même que j'aime vraiment la façon dont SVN fonctionne, ayant un référentiel central à partir duquel les gens peuvent passer la commande, sachant que je peux en déployer une copie de développement en direct et une copie de production en direct, mais parfois nous avons des maux de tête, des conflits de tri ou d'autres erreurs et chaque fois que nous devons différencier ou examiner l'historique d'un fichier, nous devons gérer la latence du réseau.

D'un autre côté, avoir une plate-forme distribuée sonne aussi comme un mal de tête, comment pouvez-vous contrôler les accès? avez-vous un référentiel central à partir duquel vous effectuez des push et des mises à jour?

Merci d'avoir jeté un peu plus de lumière sur le problème.

svn repository git

— Adam Benayoun
source

15

Essayez-vous de comparer les deux outils de la perception d'un administrateur système ou en tant que programmeur? Si vous regardez cela du point de vue des programmeurs, vous devriez peut-être le demander sur stackoverflow. Ou encore mieux, vous devriez peut-être regarder ce qui a déjà été demandé à propos de " git svn ".

La chose à propos de git et svn, c'est que ce n'est pas une proposition soit / ou. Vous pouvez exécuter un référentiel SVN, et vos développeurs peuvent utiliser git-svn pour interagir avec eux s'ils pensent que git est un meilleur outil dans un cas particulier.

— Zoredache
source

2

Il n'y a pas vraiment d'avantages à subversion sur git, vraiment. Pendant que git est distribué, tout le monde peut travailler à partir d'un référentiel central à l'aide de branches de suivi à distance. git est plus rapide, plus flexible et la fusion fonctionne réellement. De plus, vous pouvez travailler de manière réaliste hors ligne alors qu'avec subversion, vous ne pouvez pas valider les modifications si vous n'en avez pas. Vous pouvez travailler plus facilement avec des validations individuelles dans git par rapport à ce qu'un ID de validation unique représente l'état du référentiel dans svn.

L'accès est contrôlé soit par des comptes d'utilisateurs / groupes sur le serveur git (vous devez initialiser le référentiel d'origine avec 'git init --bare --shared' pour que les autorisations soient définies de manière appropriée) ou en utilisant des clés ssh. Un contrôle d'accès très granulaire peut être mis en place en utilisant 'gitosis' qui est un addon tiers.

Il faut un peu de temps pour s'habituer à travailler avec git lorsque vous êtes habitué à svn (nous venons de le faire dans mon bureau), mais git est bien plus puissant.

Si vous avez besoin d'une bonne solution, consultez http://progit.org - c'est une copie en ligne complète d'un livre open source.

— Aaron Brown
source

svn peut gérer des fichiers plus volumineux que git

— Joshua

Je ne savais pas que git avait une taille de fichier maximale - quelle est la limite?

— Aaron Brown

2

C'est principalement parce que Git transporte l'historique avec chaque copie de travail, qu'un gros fichier fortement édité prendra beaucoup de place. Si le gros fichier est essentiellement immuable, ça va

— Phil Miller

Je dirais que le commentaire de Joshua est trompeur. Les fichiers extraits sont de la même taille pour SVN et git. Ce qui se passera, c'est que parce que git conserve une copie des informations de repo localement, l'espace disque total requis pour tous les fichiers plus l'historique de repo augmentera à mesure que vous éditez les fichiers, mais pour SVN cet espace est fixe (comme l'historique de repo n'est pas localement).

— Walter

1

Dans mon équipe, nous sommes en train de changer nos systèmes de versions de contrôle de svn en git. Git a une courbe d'apprentissage légèrement plus difficile, j'ai donc commencé à me familiariser avec celui-ci, puis à enseigner aux développeurs comment l'utiliser. Ils ont besoin de connaître tous les avantages d'un système de version de contrôle distribué: plusieurs succursales, pas de référentiel central, vitesse, etc.

Comme vous, nous avions un système pour déployer nos sites, donc nous gardons quelque chose comme un serveur central git où les changements sont tirés et poussés depuis et vers les machines des développeurs. Nos sites tirent les modifications de ce "serveur central", et le reste du processus de déploiement est similaire à celui utilisant svn.

Nous avons essayé de ne pas mélanger les référentiels svn et git, en commençant à migrer nos sites mineurs et à créer de nouveaux référentiels git pour les sites principaux comme s'ils étaient une nouvelle version. L'accès est géré avec les clés ssh. Nous utilisons également gitweb comme interface web (notre système svn est basé sur http)

Cela fonctionne, ce n'est pas un changement d'un jour à l'autre et nous essayons aux développeurs de ne pas prendre ce changement comme une gêne mais une nouvelle compétence pour apprendre un outil qui, à la fin, améliorera notre propre système.

— hdanniel
source