Devrais-je regarder les systèmes de contrôle de version au-delà de Subversion?

Question

Au cours de la dernière année, je suis devenu accro à la subversion. Je suis un développeur unique et je travaille également sur quelques-uns de mes propres projets. Avec SVN, il est très facile de tout gérer - et comme il est hébergé sur un serveur en ligne via HTTPS, je peux accéder à mon code depuis n’importe où. C’est également un excellent moyen de déployer du code sur nos serveurs de production / développement.

Ce que je veux dire, c'est qu'il fait tout ce dont j'ai besoin et qu'il ne m'a jamais manqué.

Y a-t-il quelque chose de mieux? Me manque-t-il une fonctionnalité d'un autre produit que je pourrais utiliser pour me simplifier la vie? J'utilise toujours les meilleurs logiciels et n'ai aucun problème à migrer vers les nouvelles technologies.

J'ai entendu parler de GIT et j'ai fait des recherches. Je prévois d’essayer cela, mais pendant que je déconne, il existe-t-il un autre système de contrôle de source considéré comme "standard de l'industrie"? et font-ils mieux les choses que SVN?

Answer 1

Git, Mercurial et Bazaar sont des systèmes de contrôle distribués basés sur l’idée que vous n’êtes pas toujours connecté au Web et qu’il n’est pas nécessaire d’avoir une version centrale du référentiel.

Si vous faites beaucoup de travail en détachement, parfois appelé "mode avion", comme si vous êtes dans un avion et que vous ne pouvez pas vous engager, jetez un coup d'œil à Bazaar. J'ai trouvé plus facile de s'acclimater que Git ou Mercurial.

Si vous travaillez en permanence sur le Net et que vous êtes le seul développeur, vous pouvez probablement vous en tenir à Subversion.

Prenez également en compte la valeur de conserver votre répertoire personnel dans Subversion .

Answer 2

Mercurial

J’ai principalement utilisé CVS et SVN (content et content), puis j’ai commencé à faire des recherches sur le contrôle de source distribuée car il y avait beaucoup de problèmes avec DSVC. Après avoir utilisé DSVC, j’ai remarqué un changement dans mon style de développement, je suis devenu plus fluide et plus adaptable. Cela me permet de me fondre dans le tronc ou la branche expérimentale sans douleur.

• Mercurial peut évoluer d’un groupe composé d’un seul homme à un énorme, à savoir OpenJDK, sans trop de maux de tête.
• Mercurial est rapide, peut-être pas aussi rapide que GIT, mais reste très rapide
• Mercurial Queues est un moyen fantastique de gérer les correctifs. À la vitesse de l'éclairage graissé.
• Il peut fonctionner sur différents systèmes d'exploitation. La compatibilité est excellente car elle est basée sur python.
• la courbe d’apprentissage est inférieure à celle de l’ITG. Après quelques lectures, vous obtenez un aperçu de base ( http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ )
• hg permet (ainsi que de nombreux DSVC) de vous connecter à un contrôle source SVN d'entreprise avec hg-svn et hgsubversion, une extension formidable avec des autorisations et des extractions, mais pas encore de fonctionnalité de validation ou de validation
• Vous pouvez également configurer un serveur HTTP en mode push-pull via SSH
• dispose également d'une option vraiment intéressante permettant de se réunir avec vos amis de codage et de démarrer simplement le serveur HTTP, puis de l'exécuter sur localhost afin que vos amis puissent effectuer des poussées et des extractions tout en faisant un sprint de code.
• Vous pouvez également voir l'état actuel du projet via cette page HTTP.
• cherchez ici une brève description des commandes simples ( http: // edong.net/2008v1/docs/dongwoo-Hg-PDF.pdf )

Git

• essayé, son support pour svn est meilleur que mercurial. mais puisque hgsubversion est en hausse et devient une compétition pour git svn.

Git est cool, mais vous devez constamment maintenir votre code source depo et le remballer. Composé de nombreux scripts bash, il a du mal à s’exécuter sous Windows. Mais il est extrêmement rapide, avec de nombreuses fonctionnalités à utiliser. En réalité, la quantité de fonctionnalités peut être un inconvénient.

BZR

• jamais essayé

Je n’ai pas regardé en arrière depuis que j'ai commencé avec HG

Answer 3

Personnellement, je resterais avec Subversion. En tant que professionnel, j'ai vu beaucoup plus d'emplois demander (et savoir) ce que Subversion a été comparé à GIT. Il existe également de nombreux outils open source et gratuits basés sur Subversion, sans oublier l’énorme communauté de Subversion.

Le contrôle de source ne concerne pas toujours les éléments les plus récents et les plus performants, mais plutôt ce qui est essayé et vrai.

Answer 4

La nécessité de changer est la meilleure raison de changer. Cependant, il semble qu'il n'y ait pas de réel besoin de changer. Vous êtes un " Armée d'un seul " la plupart des fonctionnalités puissantes ne s'appliquent donc pas à votre situation. Oui, les gens vont discuter avec moi à ce sujet, mais ils vont pousser cette fonctionnalité ou cette fonctionnalité dont vous n’auriez probablement pas besoin. Le timing est primordial, si à l’avenir vos besoins changent, changez votre solution.

Il y aura toujours des solutions meilleures ou différentes pour un espace de problèmes, dans ce cas le contrôle de source, cependant vous devez équilibrer développement personnel, améliorations des processus / pratiques et livraison du produit de travail. Vous pouvez en apprendre davantage sur les différentes solutions / applications de contrôle de code source pour étendre vos connaissances et reconnaître le moment opportun pour changer de solution, tout en conservant ce qui fonctionne pour le moment.

Answer 5

Voici 3 raisons de passer à git à partir de Subversion (à partir de MarkMcB):

• Succursales locales sans fin, faciles, sans système de fichiers
• Cacher le travail temporaire
• Collaboration avant les commits publics

(Lisez l'article lié pour des explications complètes et des comparaisons directes sur la manière de faire les trois choses à la fois dans git et Subversion.)

Answer 6

Personnellement, je resterais avec Subversion, Y a-t-il quelque chose de mieux?

Subversion est un excellent système de contrôle de version, et vous en êtes satisfait. Par conséquent, si vous cherchez plus loin, je peux vous recommander d'obtenir des informations sur Intégration continue , il existe de nombreux outils qui peuvent vous aider à créer des constructions automatiques, à effectuer vos tests automatiques, à vérifier l'intégrité de chaque livraison, et bien plus encore. ..

Answer 7

Mercurial mérite également d’être pris en compte; la création de branches est beaucoup plus conviviale et peut fonctionner sans connexion réseau. Je n'ai jamais sérieusement essayé de séparer le travail en branches avant de passer de SVN à Mercurial.

La seule chose qui me manque sérieusement, c’est TortoiseSVN; il y a un workalike (TortoiseHg) qui est assez bon, mais ce n'est tout simplement pas la même chose.

Quoi qu’il en soit, créer un référentiel Mercurial à partir d’un SVN est trivialement facile ... essayez-le et voyez si cela vous convient ou non.

Answer 8

Règle no. 1: "Ne jamais modifier un système en cours d'exécution"

De plus, comme il existe de nombreuses nouvelles solutions brillantes (pour les problèmes que vous n’avez pas, car vous travaillez seul), vous devez envisager le coût du passage à un nouveau VCS: L’importation de subversion dans Mercurial / git n’est pas une tâche facile

il n'y a pas d'outil (autant que je sache), qui importe svn repos à l'aide du fichier dumpformat. Donc, si vous n'utilisez pas dumpformat, vous devrez vous en tenir à toutes les branches / balises de svn et les ajouter à git / BZR / Mercurial manuellement / via un script

Je ne sais donc pas quelle est la taille de vos pensions (mes pensions vont de 20 Mo à 24 Go), mais il faudra longtemps pour consulter une pension complète et même de petits projets avec beaucoup de balises consommeront beaucoup d'espace disque dur .

Le problème supplémentaire est le temps qui vous est imparti pour continuer votre migration.

Answer 9

Je suis comme vous dans le dossier des enquêtes constantes pour obtenir le meilleur outil.

J'ai essayé SVN pour le travail SOLO et quelqu'un m'a recommandé Mercurial (hg). Maintenant, je fais des keynotes à ce sujet. C'est plus sympathique que git dans Windows. Je pense maintenant "pourquoi svn complique-t-il les tâches simples comme les balises". SVN ne sait pas ce qu'est un tag. Pour SVN, une balise est une copie. Dans mercurial, une balise est un alias pour une révision. À quel point cela pourrait-il être compliqué?

La performance est un autre problème. Dans Mercurial, votre dépôt est dans votre ordinateur local. C'est donc très rapide pour un journal, un diff ou un historique.

Bien que je ne sache rien des serveurs prenant en charge Mercurial pour une version en ligne de votre référentiel.

Answer 10

Si SVN répond à tous vos besoins, je ne vois pas la raison du changement. Si la curiosité est le moteur de votre quête d'un contrôle de source différent, alors je vous recommanderais de lire sur git ou une autre solution distribuée de scm et d'essayer de déterminer s'il est rentable d'investir pour changer (ce dont je doute que ce soit dans votre cas).

Answer 11

Il y a un vieux proverbe Yankee.

Si ce n'est pas cassé, ne le corrigez pas.

Answer 12

Cela vaut vraiment la peine de regarder dans " distribué " VC même si vous n'utilisez pas réellement un flux de travail distribué. Pouvoir avoir des branches privées et contrôler vos commits locaux vaut la peine d'apprendre git. J'utilise principalement git-svn (avec d'autres membres de l'équipe utilisant des clients SVN standard, nous avions donc un flux de travail normal et centralisé), et tout fonctionnait sans faille.