SVN est-il démodé? [fermé]


9

Cela ne fait que quelques années que j'ai migré de Visual Source Safe vers SVN. Et SVN pour moi est toujours un peu "WOW! Je peux faire tellement de choses! SVN est tellement cool!"

Mais beaucoup de gens autour de moi continuent de dire "SVN? Vraiment? Meh ..."

Et il y en a tellement que je suis inquiet. Dois-je déplacer mon équipe vers Git / Mercurial ou autre chose de fantaisie? Je sais que j'ai l'air ridicule et la réponse évidente serait "restez avec ce qui fonctionne pour VOUS". SVN fonctionne pour moi ... Mais chaque fois que je crée un nouveau projet dans mon référentiel, je me pose toujours la question - était-ce le moment de déménager?

Alors ... SVN est-il vraiment si mauvais? Est-ce que je rate une énorme opportunité en m'en tenant à elle?


Cela pourrait être une lecture intéressante: stackoverflow.com/questions/161541/svn-vs-git
fouronnes

Êtes-vous un développeur autonome?
TeaDrinkingGeek

6
J'ai toujours utilisé GIT. Maintenant, je dois utiliser SVN au travail .... ... ... ... ... ... ... RAGE.
Ivo Wetzel

@TeaDrinkingGeek: OP dit "Dois-je déplacer mon équipe ..." donc je suppose qu'il y a plus que juste l'OP impliqué (sauf si vous comptez une équipe d'une équipe - mais alors ce n'est généralement pas appelé "mon équipe" ).
FrustratedWithFormsDesigner

lol désolé mec, les yeux sont un peu flous après 12 heures sur l'ordinateur portable. :)
TeaDrinkingGeek

Réponses:


8

Cela dépend entièrement de l'utilisation.

Si vous avez une équipe de personnes dans une pièce et qu’elles y font la plupart de leur travail, si vous avez déjà un processus de construction et de déploiement que vous aimez déjà, et si vous ne cherchez pas à partager votre code avec des personnes à grande échelle (comme vous le feriez avec un projet open source), alors vous ne devriez pas le transpirer.

Il y a peut-être un an, je suis passé de Subversion à git. Git convient parfaitement à ce cas d'utilisation principalement local, mais là où il brille vraiment, c'est le développement distribué. Utilisé localement, il est agréable d'avoir github comme sauvegarde à distance et une jolie interface Web pour le code, et cela me permet de laisser les entrepreneurs participer facilement. Mais je n'en retire pas grand-chose en ce moment, car je n'obtenais pas de Subversion.


8

Ne vous laissez pas emporter par le flux constant d'hypes. Vous avez quelque chose qui fonctionne, continuez à l'utiliser jusqu'à ce qu'il y ait une exigence commerciale qui soit mieux satisfaite avec autre chose (non, un nouveau système de contrôle de source brillant ou un langage de programmation tous les quelques mois, chaque fois que quelque chose de "nouveau et amélioré" est mis en avant, ne va PAS pour répondre aux besoins de votre entreprise mieux que celui que vous utilisez actuellement).

Si SVN fonctionne pour votre organisation, il n'y a donc aucune raison d'investir l'argent / le temps / l'effort nécessaire pour passer à autre chose, bien que certaines personnes le veuillent parce que c'est nouveau et brillant.

Et non, ce n'est pas (comme le pense JBK) une décision qui devrait appartenir à "l'équipe", c'est une décision qui appartient à la direction après avoir consulté toutes les parties intéressées (ce qui inclut au moins vos administrateurs système). C'est une décision commerciale de dépenser de l'argent pour changer votre pile technologique, pas une décision technique.


Je vous voterais un million de fois si je le pouvais.
HLGEM

5

Je crois qu'il ne faut jamais prendre de décisions par ignorance. Si vous ne savez pas ce que vous manquez, vous devriez essayer git assez longtemps jusqu'à ce que vous le fassiez, alors vous pouvez prendre une décision éclairée. Le saut au contrôle distribué ne peut pas vraiment être compris sans l'essayer et sans abandonner certaines vieilles habitudes pendant que vous le faites. La majeure partie de la puissance du DVCS est que vous pouvez créer autant de branches que vous le souhaitez, pour la raison que vous voulez. Si vous l'essayez pendant un mois et que vous n'avez pas créé au moins 5 succursales, vous ne l'avez pas testé selon ses propres conditions. C'est l'erreur de la plupart des gens qui n'obtiennent pas de git. Après cela, si vous revenez à svn, vous en connaîtrez au moins les raisons.


5
Je suis fortement en faveur de prendre la plupart des décisions par ignorance relative. Vous lui suggérez de prendre un mois pour essayer git. C'est du vrai travail. Il ne devrait le faire que s'il y a des raisons de croire que cela améliorera beaucoup sa situation. Sinon, il y a probablement quelque chose d'autre sur lequel il devrait passer son mois d'expérimentation. Par exemple redis ou mongo ou rails ou node.js ou BDD l'une des nouvelles choses tout aussi chaudes.
William Pietri

Mais Git est une nouveauté chaude. Et l'expérience de nombreux utilisateurs Git suggère qu'il va faire sa situation beaucoup mieux.
Kyralessa

3

Je n'ai pas utilisé Git, mais j'ai utilisé Mercurial, et je ne vois vraiment pas quel est le problème. Cela ressemble beaucoup à SVN, sauf que les choses de base comme l'enregistrement et le paiement sont plus compliquées (nécessitent deux étapes au lieu d'une). En retour, il est censé faire beaucoup de choses plus avancées que je n'ai jamais eu besoin de faire beaucoup plus simple. Ma réaction aux affirmations selon lesquelles le DVCS est intrinsèquement supérieur est fondamentalement "OK, bien sûr, je vais vous croire sur parole", puis je continue avec SVN, qui fonctionne très bien pour moi.


L'énorme problème avec DVCS est que vous pouvez faire tout votre travail "hors ligne". Cette caractéristique impose l'exigence que le DVCS ait un puissant mécanisme de fusion qui peut gérer le rebasage et la ramification; le type de tâches qui ne sont tout simplement pas possibles avec un VCS centralisé. La supériorité que les gens revendiquent vient des workflows activés plutôt que de la supériorité technique. Si vous n'utilisez pas ou n'avez pas besoin de ce type de flux de travail, c'est bien aussi.
greyfade

1
C'est parce que l'enregistrement et le retrait n'existent pas dans DVCS. Vous utilisez hg en remplacement de SVN plutôt que d'utiliser hg comme il est censé être utilisé. La même chose s'appliquerait à tout DVCS.
alternative

@Mathepic: Eh bien, vous pouvez changer le nom si vous le souhaitez, mais le concept fondamental de transfert de données entre la copie de travail locale et le référentiel officiel existe dans tout système de contrôle de source.
Mason Wheeler

1
non. Il n'y a pas une telle opération dans un DVCS.
alternative

3
oui il y a - l'intérêt d'un référentiel central pour pousser la version `` maître '' est un cas d'utilisation très valide, que ce soit pour la sauvegarde, le serveur de build, la gestion des versions, ou juste un moyen de mieux coordonner les équipes.
gbjbaanb

-2

La réponse évidente ici est de laisser l'équipe décider et d'avoir une discussion sur la meilleure option pour tout le monde afin que ce ne soit pas quelqu'un qui appelle les coups de feu dans le vide. Il peut y avoir diverses opinions et préoccupations à traiter, mais je préfère suggérer d'aller chercher une réponse consensuelle plutôt que d'essayer d'être dictatorial sur ce qu'il faut utiliser.


3
Avez-vous une idée du coût en heures-homme du passage d'un système de contrôle de source à un autre ou du risque de perdre des choses dans le processus si quelqu'un nouveau dans le nouveau système fait une erreur en convertissant le code existant? Ce n'est PAS une décision d'équipe, c'est une décision commerciale et ne doit être entreprise que si vous avez des besoins réels auxquels votre système actuel ne peut pas répondre.
HLGEM
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.