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


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 vraiment 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ù. Il est également idéal pour 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’en ai besoin et qu’il ne m’a jamais manqué.

Y a-t-il quelque chose de mieux? Est-ce que je manque une fonctionnalité dans un autre produit que je pourrais utiliser pour me faciliter la vie? Je suis toujours attaché à l’utilisation des meilleurs logiciels et je n’ai aucun problème à migrer vers les nouvelles technologies.

J'ai entendu parler de GIT et j'ai fait des recherches. Je compte bien essayer mais pendant que je joue avec ça, y a-t-il d'autres systèmes de contrôle de source qui sont considérés comme "standards de l'industrie" et font-ils mieux que SVN?


27
2017-10-22 03:35


origine


Réponses:


Git, Mercurial et Bazaar sont des systèmes de contrôle distribués fonctionnant avec l’idée que vous n'êtes pas toujours connecté au Net et qu’il n’ya pas nécessairement une version centralisée du référentiel.

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

Si vous faites toujours du travail connecté au Net et que vous êtes le seul développeur, vous pouvez probablement vous en tenir à Subversion.

Aussi, veuillez considérer la valeur de garder votre répertoire personnel dans Subversion.


29
2017-10-22 03:41



Mercuriel

J'ai principalement utilisé CVS et SVN, heureux et contenu, puis j'ai commencé à rechercher le contrôle de la source distribuée car il y avait beaucoup de bruit fait sur DSVC. Après avoir utilisé DSVC, j'ai remarqué un changement dans mon style de développement, je suis devenu plus fluide et adaptable. Me permettant de revenir dans le tronc ou la branche expérimentale sans douleur.

  • Mercurial peut évoluer d'un groupe d'hommes à un groupe énorme, par exemple OpenJDK, sans trop de maux de tête.
  • Mercurial est rapide, peut-être pas aussi rapide que GIT, mais il est toujours très rapide
  • Mercurial Queues est un moyen fantastique de gérer les patchs. À la vitesse de l'éclairage graissé.
  • Il peut fonctionner sur différents systèmes d'exploitation, la compatibilité est excellente car il est basé sur python.
  • la courbe d’apprentissage est inférieure à celle de GIT, après quelques lectures, vous obtenez la base des choses (http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/)
  • hg permet (ainsi que beaucoup de DSVC) de s'interfacer avec un contrôle de source SVN d'entreprise avec hg-svn et hgsubversion qui est une merveilleuse extension avec des autorisations et des décaissements, mais pas encore des fonctionnalités de push ou de validation
  • Vous pouvez également configurer un serveur HTTP exécutant la fonction push-pull via SSH
  • ont également une excellente option de se réunir avec vos copains de codage et simplement démarrer le serveur HTTP l'exécuter sur localhost et vos amis peuvent pousser et tirer pendant que vous faites un sprint de code.
  • Vous pouvez également voir l'état actuel du projet via cette page HTTP.
  • Enfin, regardez ici une brève description des commandes simples (http://edong.net/2008v1/docs/dongwoo-Hg-PDF.pdf)

Git

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

Git est cool, mais vous devez constamment maintenir votre code source et le réemballer. Comme il se compose de nombreux scripts bash, il a du mal à fonctionner sur Windows. Mais il est extrêmement rapide, avec de nombreuses fonctionnalités à utiliser. En fait, 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


17
2017-10-22 05:20



Je resterais personnellement avec Subversion. D'un point de vue professionnel, j'ai vu beaucoup d'emplois demander (et savoir) à quoi Subversion était comparée à GIT. Il y a aussi beaucoup d'outils open source et freeware construits autour de Subversion, sans parler de l'immense communauté de Subversion.

Le contrôle des sources ne concerne pas toujours les dernières et les meilleures, mais concerne plus souvent ce qui est essayé et ce qui est vrai.


12
2017-10-22 03:40



La meilleure raison de changer est la nécessité. Cependant, il semble qu'il n'y ait pas vraiment besoin de changer. Vous êtes une "Army of One", donc la plupart des fonctionnalités puissantes ne s'appliquent pas à votre situation. Oui, les gens vont discuter avec moi à ce sujet, mais ils vont pousser cette fonctionnalité ou cette fonctionnalité dont vous n'avez probablement pas vraiment besoin. La synchronisation est tout, si à l'avenir vos besoins changent, changez votre solution.

Il y aura toujours des solutions meilleures ou différentes pour un espace problématique, dans ce cas le contrôle des sources, mais vous devez équilibrer le développement personnel, les améliorations des processus / pratiques et la livraison des produits. Vous pouvez en apprendre plus sur les différentes solutions / applications pour le contrôle de code source afin d'élargir vos connaissances afin de savoir quand il est temps de changer de solution, mais de rester fidèle à ce qui fonctionne pour le moment.


12
2017-10-22 04:49



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

  • Des succursales locales sans fin, faciles à utiliser, sans système de fichiers
  • Travail temporaire
  • Collaboration avant que le public ne s'engage

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


11
2017-10-22 03:50



Personnellement, je resterais aussi 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. Si vous cherchez plus loin, je peux vous recommander des informations sur Intégration continue, il existe de nombreux outils qui peuvent vous aider à créer automatiquement des builds, à rendre vos builds auto-testables, à vérifier l’intégrité de chaque commit et bien plus encore ...


7
2017-10-22 04:19



Mercurial vaut également la peine d'être considéré. les branchements sont beaucoup plus conviviaux et peuvent 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 est TortoiseSVN; il y a un workalike (TortoiseHg) qui est plutôt bon, mais ce n'est tout simplement pas la même chose ..

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


5
2017-10-22 03:51



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

En outre, comme il existe de nombreuses solutions brillantes (pour les problèmes que vous n’avez pas, alors que vous travaillez seul), vous devez considérer 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 (AFAIK), qui importe svn repos en utilisant le format dumpformat. Donc, si vous n'utilisez pas le dumpformat, vous vous en tenez à l'extraction de toutes les branches / balises de svn et à les ajouter à git / BZR / Mercurial manuellement / via un script

Donc, je ne sais pas quelle est la taille de vos pensions (mes pensions vont de 20 Mo à 24 Go), mais il faudra Longtemps pour vérifier un repo entier et même de petits projets avec beaucoup de tags vont manger beaucoup de espace disque dur.

Le problème supplémentaire est le temps jusqu'à ce que votre migration soit effectuée, vous ne pouvez pas continuer à travailler.


3
2017-10-22 17:31



Je suis juste comme vous dans la question de l’investigation constante 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 discours à ce sujet. C'est plus sympa que git in windows. Je pense maintenant "pourquoi svn complique-t-il avec des tâches simples comme les tags". SVN ne sait pas ce qu'est un tag. Pour SVN, une balise est une copie. En mercurial, une balise est un alias pour une révision. Comment cela pourrait-il être compliqué?

Performance c'est un autre problème. Dans Mercurial, votre repo est dans votre machine locale. Donc, c'est très rapide pour un journal, un diff ou un historique.

Bien que je ne sache rien sur les serveurs qui supportent mercurial pour une version en ligne de votre repo.


2
2017-11-19 01:10