Quels sont vos systèmes de contrôle de version préférés?
Il s'agit davantage d'une question de discussion que d'une tentative réelle de déterminer le "meilleur", car cela varie clairement selon les besoins de l'organisation. Je suis plus curieux des arguments en faveur de différents systèmes à travers les catégories (centralisé vs distribué, ouvert vs propriétaire, etc.).
Alors, quel est selon vous le meilleur système de contrôle de version?
Mercuriel
En raison de sa capacité sophistiquée à créer des branches et à fusionner du code, c'est le meilleur que j'ai utilisé. L'ensemble du paradigme DVCS est tellement logique. Je n'ai pas utilisé Git, mais je suppose qu'il est également admissible.
Git
Git est fantastique, et je le recommanderais particulièrement à tous ceux qui travaillent sur des projets open source: il est beaucoup plus facile d'apporter une petite modification ponctuelle à un projet sur Git, surtout s'il est hébergé sur GitHub, que sur e- envoi de correctifs à propos de SVN.
Une grande mise en garde pour les utilisateurs de Windows: les outils Windows de Git, bien que certainement utilisables, ne sont pas tout à fait à la hauteur. Quand j'ai été obligé d'utiliser Windows pendant un certain temps, j'ai essayé l'interface Windows de Mercurial avec un outil d'intégration Hg-Git pour pouvoir utiliser mes référentiels Git, et j'ai trouvé que c'était beaucoup plus facile à utiliser.
Avertissement: depuis ce post, j'ai trouvé Mercurial et je l'aime beaucoup mieux que SVN. Donc, ce post est un peu obsolète avec les commentaires Pro SVN et anti-DVCS général, mais les trucs anti-git sont toujours pertinents
Je suis fan de SVN sur Git.
Pourquoi? Parce que SVN était beaucoup plus facile pour un seul développeur ou une petite équipe, et git (spécifiquement msysgit) m'a laissé un mauvais goût dans la bouche.
Lorsque j'étais stagiaire dans une petite boutique, j'ai été initié à git sur Windows. J'ai immédiatement remarqué la quantité de travail qu'il a fallu pour le faire fonctionner avec Github. Tout d'abord, j'ai dû générer une clé privée ssh, coller la clé publique dans Github, puis faire apparaître pageant et ouvrir ma clé privée chaque fois que je voulais pousser, ce qui était extrêmement ennuyeux.
Et je n'ai jamais vraiment aimé que je déroule tout le référentiel. Je dois admettre que je n'ai jamais travaillé avec quelque chose d'énorme, mais j'aurais peur de télécharger le référentiel de KDE dans Git si le référentiel entier et ses révisions sont sur ma HD.
Ensuite, il y a eu le processus déroutant pour faire un commit. TMK, je devais d'abord "mettre en scène" tous les fichiers que je voulais valider (ce qui était nul quand vous aviez beaucoup de fichiers, il m'a fallu un certain temps pour trouver la commande manuelle pour tout mettre en scène), puis faire le commit, puis pousser vers le principal repo (pourquoi est-ce une opération séparée?!).
Vous disposiez également des données de validation pas (!) Très utiles. Oh, regardez, ceci est la partie 14f74433245ae17aeeaa de l'arbre 2167a4934d0a4a7db0de et du parent d7042abb4821d3faf600. Qu'est-ce que ça veut dire? Je devrais être en mesure de comprendre les choses assez rapidement et ne pas avoir à consulter une documentation étrange.
En parlant de documentation, au moins quand je l'utilisais, il semblait que tout était au format de fichier Linux, IE confus et inutile pour moi. Je pouvais rarement trouver beaucoup d'aide dans les documents et simplement utilisé à google.
Et avec les commits, la seule chose que je n'ai pas aimé était le manque de numéros de version. Maintenant, je sais que c'est à cause de la conception de git, mais tout logiciel a besoin d'un numéro de version. Je me souviens encore des validations du marqueur qui apparaitraient "Version modifiée en 1.8.6" ou quelque chose de similaire, mais vous ne pouviez toujours pas faire de nombres. Pour moi, avoir la version 1.8.6.5164 (la dernière partie est le numéro de révision) me dit beaucoup plus que simplement 1.8.6 et une note disant que quelque chose de mineur a changé, essayez-le
Obtenir un logiciel spécifique, le programme de base sur Windows est msysgit, qui est une interface terrible. Il s'est verrouillé sur moi plusieurs fois, avait une interface horrible et l'intégration CLI-GUI était au mieux incertaine. Les accros de la ligne de commande autour de moi détestaient encore plus l'interface graphique.
Voyons maintenant SVN. Et puisque je suis sur Windows et que j'ai un compte Google, spécifiquement TortoiseSVN et Google Code.
Tout d'abord, l'intégration complète de Shell pour tout faire sur le référentiel (et pour vous, Linux, RabbitVCS fait la même chose), aucune interface graphique principale n'est nécessaire. Obtenir un référentiel est facile en tant que paiement, aucun SSH n'est nécessaire (je ne me souviens pas si Github a besoin de SSH pour les pulls), et aucun repo complet + toutes les validations passées assis sur votre HD.
L'engagement est extrêmement facile, principalement parce qu'aucun SSH ou staging n'est requis. Vous vérifiez simplement tous les fichiers que vous voulez en utilisant l'option très utile de sélectionner tout qui dans ma version msysgit n'était pas disponible, tapez un message de validation et appuyez sur validation. Google Code vous demande alors vos informations de connexion (que la plupart des clients stockent), et vous avez terminé. Simple, facile et sans SSH
Numéros de version? Avec un code simple, vous pouvez ajouter un numéro de version et un numéro de validation à toutes les extractions, ce qui rend les choses beaucoup plus faciles. Vous obtenez également des numéros de version utilisables qui montrent réellement un changement, par exemple 1.8.6.5165 est plus récent que 1.8.6.5164.
Documentation? Eh bien, c'est difficile à dire. La tortue est documentée, mais je n'ai pas fait référence à la documentation officielle depuis si longtemps que je ne peux pas en juger. La lecture d'un simple guide d'introduction m'a suffi.
La fusion est autre chose que je ne peux pas comparer. J'ai dû le faire une fois dans Git quand quelqu'un d'autre a commis un changement dans un fichier sur lequel je travaillais, mais jamais dans SVN.
Lequel recommanderais-je? Eh bien dans les grandes équipes, git a ses avantages, principalement dans son cycle de développement non linéaire. Dans un autre projet, j'ai vu 4 programmeurs commencer dans des branches distinctes, puis fusionner tout le code de manière très étrange qui s'est en quelque sorte transformé en la branche principale finale. Github et msysgit avaient un outil de visualisation vraiment sympa pour l'ensemble du projet que j'ai vraiment aimé.
Pour les projets de développeur unique ou de petite équipe, SVN serait le meilleur car la plupart des fonctionnalités de Gits ne sont pas utilisées et vous n'obtenez que ses parties négatives. La simplicité est une si belle chose
La citation suivante de Q4TD résume assez bien pour moi:
"J'ai adoré Git jusqu'à ce que je l'essaie. Maintenant, j'aime Mercurial. "
- Tor Norbye, Le Java Posse Podcast
En outre, hgsubversion fait un très bon client Subversion pour Linux (où j'utilise habituellement la ligne de commande, contrairement à Windows où j'utilise habituellement TortoiseSVN). Le plus grand avantage: non .svn sous-dossier dans chaque dossier, juste un .hg au niveau supérieur.
Mise à jour: En réponse à la demande d'Alex dans les commentaires de "dire plus sur pourquoi git n'a pas fonctionné pour vous, et comment Mercurial a mieux fonctionné":
Je ne dirais pas que Git ne fonctionne pas pour moi, mais Murcurial fonctionne mieux IMO.
En un mot, c'est Mercurial:
et voici Git:
Et j'affirme que Mercurial fera tout ce que la plupart des développeurs en auront besoin, sans avoir à consulter le manuel pour savoir comment faire les choses de tous les jours.
Certes, je n'ai utilisé Git que de temps en temps, mais la communauté de programmation a gaga sur des langages comme Ruby et Python, en partie, pour leur concision et leur élégance, alors que Git se sent comme un chameau qui a été conçu par un comité de chameaux.
Bah, regarde maintenant ce que tu as fait? Il y a des diatribes partout. Avancez, rien à voir ... rien à voir ...
Mise à jour 2: Et un autre à propos Tweet Je viens de tomber sur:
"Git devient plus facile une fois que vous avez l'idée de base que les branches sont des endofoncteurs homéomorphes cartographiant les sous-variétés d'un espace de Hilbert."
Je n'ai pas un seul "meilleur" système de contrôle de version, mais plutôt un seul meilleur paradigme VCS.
J'ai utilisé plusieurs systèmes de contrôle de version centralisés différents et plusieurs systèmes de contrôle de version distribués différents. Et je peux dire sans hésitation que personne ne devrait jamais s'infliger un CVCS.
Je m'en fiche lequel DVCS que vous choisissez (mon préféré est Git), mais faites-vous plaisir et utilisez un DVCS. D'une part: vous serez beaucoup plus flexible. Les DVCS peuvent émuler trivialement un flux de travail CVCS (il suffit de ne jamais bifurquer le référentiel et de traiter vos référentiels locaux uniquement comme un chache au lieu d'un fork indépendant), tandis que l'inverse est impossible. Et même si, logiquement, faire cette émulation devrait entraîner des frais généraux (et en effet c'est le cas), je toujours le trouve plus facile à utiliser (sans parler de beaucoup plus performant en raison du local la mise en cache) que n'importe lequel des CVCS que j'ai utilisés.
Je ne peux pas dire que j'ai rencontré le meilleur logiciel de contrôle de version, mais je peux vous dire de rester à l'écart de VSS et MKS. Les deux sont des chiens à éviter à tout prix.
Je ne dirais pas le meilleur, mais un avec des fonctionnalités et des concepts très intéressants.
Fossil est un projet de contrôle de version distribué, de suivi des bogues et wiki construit sur la base de données SQLite en tant que référentiel.
Serveur Team Foundation
Parce que:
- C'est un bon VCS solide. (Je ne le considérerais pas comme le meilleur, mais il a de jolis extras.)
- Son suivi des tâches et des bogues intégré qui s'intègre dans Visual Studio m'aide à rester concentré et à savoir sur quoi je dois travailler en un seul endroit (appliquer automatiquement un enregistrement à un bogue ou à une tâche et le fermer est plutôt bien, bien que vous puissiez obtenir des plugins pour d'autres systèmes/Eclipse/etc pour ce faire.)
- Il intègre les tâches/le suivi des bogues/les projets directement dans Project Server, donc je n'ai que rarement à tenir à jour les plans de projet ou les feuilles de temps. Les mises à jour du projet dans Project Server filtrent automatiquement en tant que tâches dans TFS et dans Visual Studio pour moi de voir automatiquement.
J'ai utilisé une multitude de systèmes de contrôle de version dans ma longue histoire:
- RPPT Rouleaux de ruban de papier perforé). Dans une boîte à chaussures. Je ne plaisante pas.
- PVCS - (Polytron Version Control System). Le premier vrai VCS que j'ai utilisé.
- SCCS - il y a si longtemps, je ne me souviens d'aucune chose exceptionnellement bonne ou mauvaise à ce sujet.
- RCS - comme d'autres l'ont souligné, préfère aspirer des boules d'âne en sueur.
- CVS - ce n'était qu'une douleur lorsqu'il était utilisé avec plus de 2 programmeurs. meilleure caractéristique: rcs2cvs.
- VSS - cela fonctionne, sauf le mardi, lorsqu'il corrompt l'ensemble de votre référentiel.
- Perforce - coûte plus cher que ma voiture. Le VCS lui-même est acceptable, mais les gars de l'informatique qui contrôlent chaque aspect de son utilisation ne l'atterriront jamais sur ma liste "préférée".
- SVN - ramification et fusion est une chienne, mais en général, c'est mieux que n'importe lequel des précédents. Pas si bon avec beaucoup de petits changements en suspens en attente d'examen.
- Mercurial - le peu d'expérience que j'en ai, j'aime. Je pourrais l'essayer sur mon prochain projet.
- Git - n'a jamais eu l'occasion de l'utiliser.
Même si un couple était horrible, la plupart étaient "bien". Ils ne m'ont pas gêné. Tant qu'un outil --- (ne rend pas ma vie beaucoup plus difficile, ça ne me dérange pas vraiment.
La vraie chose est de comprendre les forces et les faiblesses de chacun. Comprendre l'environnement cible:
- distribué ou local
- petite équipe ou grande
- service vcs hébergé ou non
- intégration facile dans d'autres outils
Joel est également sorti avec une observation importante: apprendre l'outil et son vrai modèle d'utilisation. Il a eu beaucoup de mal à essayer de faire en sorte que Mercurial se comporte comme Subversion.
Un système plus récent que nous utilisons dans mon bureau est Plastic SCM (http://www.plasticscm.com/). Cela fonctionne très bien pour notre petite équipe et nous donne un excellent contrôle sur tous les aspects de la gestion des sources.
SCCS .
Ou, si vous ne vivez pas dans une grotte depuis 38 ans, CSSC .
Sérieusement, mon entreprise utilise TeamWare , qui est une sorte de pseudo DVCS basé sur SCCS.
Non, je ne plaisante pas.
Sun est passé à Mercurial de TeamWare il y a seulement quelques années. Vous devez maintenant comprendre pourquoi Java semblait se déplacer si lentement.
MPW: Eh bien, je ne peux pas vraiment lui donner un avis malgré mes efforts.
C'était à l'époque où j'apprenais la programmation au lycée, et le seul compilateur C++ vraiment gratuit à avoir était Macintosh Programming Workbench, que j'ai gardé sur un disque Zip et que j'ai intégré à Performa qui était disponible dans le laboratoire.
MPW est venu avec des dizaines d'outils (dont aucun n'a été retravaillé, c'était un téléchargement séparé), et l'un d'eux était un utilitaire de contrôle de version. Il a ouvert une petite fenêtre avec une seule ligne de texte et vous deviez y faire glisser vos projets ou fichiers. Il n'avait aucune documentation que j'ai jamais pu découvrir, inhabituel étant donné que tout le reste semblait avoir de bons documents, et donc je n'ai jamais vraiment compris comment l'utiliser.
Ce fut mon premier pinceau avec VC, et le dernier depuis longtemps. Maintenant, j'utilise git pour tout.
RCS - Système de contrôle des révisions
Le codage solo rendu si facile.
J'ai utilisé Visual SourceSafe et je le détestais, mais c'était mieux que rien, mais pas beaucoup. Au cours des deux dernières années, j'ai utilisé quelque chose appelé QCVS par Qumasoft.com écrit, détenu et pris en charge par Jim Voris le programmeur. Gui simple, prix bon marché, bon support.
Fait juste le travail.
Pas ClearCase, du moins pour un système Unix/Linux (peut-être qu'avec Windows, le programme d'installation est plus facile). Il m'a été plus facile d'apprendre un nouvel outil, Perforce, plutôt que de mettre à niveau notre serveur ClearCase.
J'utilise actuellement Perforce au travail et j'aime ça mais je n'ai aucune idée si c'est le meilleur. La configuration de l'environnement de ligne de commande et du serveur Perforce est un peu gênante, mais l'utilisation de Visual Client est assez facile. J'aime à penser que les utilisateurs ont un temps assez facile avec lui pour les tâches quotidiennes; c'est juste que la configuration initiale prend un peu de travail.