Quels sont vos systèmes de contrôle de version préférés? [fermé]

Il s’agit plus d’une question de discussion que d’une tentative réelle de déterminer le «meilleur», puisque cela varie clairement en fonction des besoins de l’organisation. Je suis plus curieux des arguments en faveur de différents systèmes dans toutes 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é. Le paradigme DVCS dans son ensemble prend tout son sens. Je n'ai pas utilisé Git, mais je suppose qu'il est également admissible.

Git

Git est fantastique, et je le recommande tout particulièrement à quiconque travaille sur des projets open source: il est beaucoup plus facile d'apporter un petit changement ponctuel à un projet sur Git, surtout s'il est hébergé sur GitHub envoyer des correctifs avec SVN.

Un inconvénient majeur pour les utilisateurs de Windows: les outils Windows de Git, bien que parfaitement utilisables, ne sont pas à la hauteur. Lorsque j'ai été contraint d'utiliser Windows pendant un certain temps, j'ai testé l'interface Windows de Mercurial avec un outil d'intégration Hg-Git afin de pouvoir utiliser mes référentiels Git. Cette méthode a été beaucoup plus simple à utiliser.

Attention: Depuis ce billet, 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 en général, mais le contenu anti-git est toujours d'actualité

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 que git (en particulier msysgit) me laissait un mauvais goût dans la bouche.

Lorsque je faisais mon stage dans un petit magasin, on m'a initié à git sous Windows. J'ai immédiatement remarqué la quantité de travail nécessaire pour que cela fonctionne avec Github. Tout d'abord, je devais générer une clé privée ssh, coller la clé publique dans Github, puis faire apparaître une reconstitution historique 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 j’arrache tout le référentiel. J'admettrai que je n'ai jamais travaillé avec quoi que ce soit d'énorme, mais j'aurais peur de télécharger le référentiel de KDE dans Git si l'ensemble du référentiel et ses révisions sont sur mon disque dur.

Ensuite, il y avait 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 dommage lorsque vous aviez beaucoup de fichiers, il m'a fallu un certain temps pour trouver la commande manuelle pour tout mettre en scène), puis faites le commit, puis appuyez sur la touche principale. repo (pourquoi est-ce une opération séparée?!).

Vous avez également eu les données de validation pas (!) Très utiles. Oh regardez, c’est une partie de l’arbre 2167a4934d0a4a7db0de et de son parent d7042abb4821d3faf600. Est-ce que ça veut dire? Je devrais être capable de comprendre les choses assez rapidement sans avoir à consulter de la documentation étrange.

En parlant de documentation, du moins quand je l’utilisais, il me semblait que tout était au format de fichier man Linux, c’est déroutant et inutile pour moi. J'ai rarement pu trouver beaucoup d'aide dans la documentation et tout simplement eu recours à Google.

Et avec les commits, la seule chose qui ne me plaisait pas était le manque de numéros de version. Maintenant, je sais que cela est dû à la conception de git, mais tout logiciel nécessite un numéro de version. Je me souviens encore des commits de marqueur qui apparaissaient en disant "Version modifiée à 1.8.6" ou quelque chose de similaire, mais vous ne pouviez toujours pas créer de numéros de build. 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.

Étant donné que le logiciel est spécifique au logiciel, le programme de base sous Windows est msysgit, qui est une interface terrible. Il m'a bloqué à quelques reprises, avait une interface horrible et l'intégration CLI-GUI était au mieux douteuse. Les drogués de la ligne de commande autour de moi détestaient encore plus l'interface graphique.

Regardons maintenant SVN. Et depuis que je suis sur Windows et que j'ai un compte Google, en particulier TortoiseSVN et Google Code.

Premièrement, intégration complète du 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 comme une caisse, pas besoin de SSH (je ne me souviens pas si Github a besoin de SSH pour les pulls), et pas de repo complète + tous les commits passés assis sur votre disque dur.

S'engager est extrêmement facile, principalement parce qu'aucune SSH ou mise en scène n'est requise. Il vous suffit de cocher tous les fichiers souhaités à l’aide de l’option très utile Sélectionner tout qui n’était pas disponible dans la version msysgit, de saisir un message de validation et de cliquer sur commit. Google Code vous demande ensuite vos informations de connexion (stockées par la plupart des clients), et ce que 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 commandes, ce qui simplifie grandement les choses. Vous obtenez également des numéros de version utilisables qui indiquent réellement une modification, 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. Lire un simple guide d'introduction me suffisait.

La fusion est quelque chose d'autre que je ne peux pas comparer. Je devais le faire une fois dans Git lorsqu'un tiers modifiait un fichier sur lequel je travaillais, mais jamais dans SVN.

Lequel pourrais-je recommander? Bien dans les grandes équipes, git a ses avantages, principalement dans son cycle de développement non linéaire. Dans un autre projet, 4 programmeurs ont démarré dans des branches distinctes, puis ont fusionné tout le code de manière très étrange qui s'est en quelque sorte transformée en branche principale finale. Github et msysgit avaient un très bel outil de visualisation pour l’ensemble du projet que j’ai vraiment aimé.

Pour les projets à 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 obtenez uniquement ses aspects négatifs. La simplicité est une belle chose

La citation suivante de Q4TD résume assez bien pour moi:

«J'ai aimé Git jusqu'à ce que je l'aie essayé. Maintenant j'aime Mercurial. "

        - Tor Norbye, le podcast Java Posse

En outre, hgsubversion est un assez bon client de subversion pour Linux (où j’utilise habituellement la ligne de commande, contrairement à Windows où j’utilise habituellement TortoiseSVN). Le plus gros avantage: pas de .svnsous-dossier dans chaque dossier, mais juste .hgau plus haut niveau.

Mise à jour: En réponse à la demande d'Alex dans les commentaires, "en dire plus sur les raisons pour lesquelles git n'a pas fonctionné pour vous et sur la façon dont Mercurial a fonctionné mieux":

Je ne dirais pas que Git ne fonctionne pas pour moi, mais Murcurial fonctionne mieux à l'OMI.

En un mot, voici Mercurial:

et c'est Git:

Et j'affirme que Mercurial fera tout ce que la plupart des développeurs auront besoin de faire, sans avoir à consulter le manuel pour savoir comment faire les choses de tous les jours.

Certes, je n'ai utilisé que Git à l'occasion, mais la communauté des programmeurs s'est mise à gaga sur des langages tels que Ruby et Python, en partie pour leur concision et leur élégance, alors que Git ressemble à un chameau conçu par un comité de chameaux.

Bah, maintenant regarde ce que tu as fait? Il y a des diatribes partout. Avance, rien à voir ... rien à voir ...

Mise à jour 2: Et un autre tweet à propos que je viens de rencontrer:

"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 meilleur paradigme de VCS.

J'ai utilisé plusieurs systèmes de contrôle de version centralisés et différents systèmes de contrôle de version distribués. Et je peux dire sans hésiter que personne ne devrait jamais s’infliger un CVCS.

Je ne me soucie pas que DVCS vous choisissez (mon préféré particulier est Git), mais s'il vous plaît ne vous une faveur et d' utiliser un DVCS. D'une part: vous serez beaucoup plus flexible. Les DVCS peuvent émuler de manière triviale un flux de travail CVCS (il suffit de ne jamais diviser le référentiel, et de traiter vos référentiels locaux uniquement comme une tâche à la place d'un fork indépendant), alors que l'inverse est impossible. Et tout logiquement, faire cette émulation devrait porter certains frais généraux (et en effet il ne), je reste plus facile à utiliser (sans parler de beaucoup plus en raison de la performante mise en cache locale) que l' un des CVCSs que je l' ai utilisé.

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 de MKS. Les deux sont des chiens qui devraient être évités à tout prix.

Je ne dirais pas le meilleur, mais un avec des caractéristiques et des concepts très intéressants.

Fossil est un contrôle de version distribué, un suivi des bogues et un projet wiki reposant sur une base de données SQLite en tant que référentiel.

Team Foundation Server

Car:

1. C'est un bon VCS solide . (Je ne le considérerais certainement pas comme le meilleur, mais il comporte de beaux extras.)
2. Son suivi intégré des tâches et des bogues qui s’intègre dans Visual Studio m’aide à rester concentré et à savoir ce que j’ai besoin de travailler au même endroit (appliquer automatiquement un enregistrement à un bogue ou à une tâche et la fermer est assez bien, mais vous pouvez le faire. obtenir des plugins pour d’autres systèmes / eclipse / etc pour le faire.)
3. Il intègre les tâches / le suivi des bogues / les projets directement dans Project Server. Il est donc rare que je tienne à jour les plans de projets 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 que je puisse les voir automatiquement.

J'ai utilisé une multitude de systèmes de contrôle de version au cours de ma longue histoire:

• RPPT - (Rouleaux de ruban de papier perforé). Dans une boîte à chaussures. Je ne plaisante pas.
• PVCS - (Système de contrôle de version Polytron). Le premier vrai VCS que j'ai utilisé.
• SCCS - il y a si longtemps, je ne me souviens de rien d'exceptionnellement bon ou mauvais.
• RCS - comme d'autres l'ont fait remarquer, préférerait sucer des balles d'âne en sueur.
• CVS - c’était très pénible lorsqu’il était utilisé avec plus de 2 programmeurs. meilleure caractéristique: rcs2cvs.
• VSS - cela fonctionne, sauf le mardi, lorsqu'il corrompt tout votre référentiel.
• Perforce - coûte plus cher que ma voiture. Le VCS lui-même est acceptable, mais les informaticiens qui contrôlent tous les aspects de son utilisation ne le placeront jamais sur ma liste "préférée".
• SVN - ramifier et fusionner est une chienne, mais en général, il est meilleur que les précédents. Pas si bon avec beaucoup de changements minuscules en attente de révision.
• Mercurial - le peu d’expérience que j’ai avec, j’aime bien. Je pourrais l'essayer sur mon prochain projet.
• Git - n'a jamais eu l'occasion de l'utiliser.

Bien que quelques-uns aient été des horreurs, la plupart étaient "bien". Ils ne m'ont pas gêné. Tant qu'un outil ne me rend pas la vie beaucoup plus difficile , cela 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 a également formulé une observation importante: apprendre l'outil et son véritable modèle d'utilisation. Il lutta avec force pour faire en sorte que Mercurial se comporte comme Subversion.

Plastic SCM (http://www.plasticscm.com/) est un nouveau système que nous utilisons à mon bureau. Cela fonctionne très bien pour notre petite équipe et nous donne un très bon contrôle sur tous les aspects de la gestion de la source.

SCCS .

Ou, si vous ne vivez pas de grotte depuis 38 ans, CSSC .

Sérieusement, ma société utilise TeamWare , une sorte de pseudo-DVCS basé sur SCCS.

Non, je ne plaisante pas.

Sun est passé de TeamWare à Mercurial il y a seulement quelques années. Vous devez maintenant comprendre pourquoi Java semble bouger si lentement.

MPW: Eh bien, je ne peux pas vraiment donner mon avis malgré mes efforts.

C'était à l'époque où j'apprenais la programmation au lycée, et le seul compilateur C ++ vraiment gratuit à avoir été Macintosh Programming Workbench.

MPW est venu avec des dizaines d’outils (dont aucun n’était une retouche, c’était un téléchargement séparé), et l’un d’eux était un utilitaire de contrôle de version. Il s'est ouvert une petite fenêtre avec une seule ligne de texte, et vous deviez glisser et déposer vos projets ou fichiers dessus. Il n’y avait aucune documentation que j’ai jamais pu découvrir, ce qui est inhabituel compte tenu du fait que tout le reste semblait avoir d’excellents documents et que je n’ai donc jamais vraiment compris comment l’utiliser.

C'était mon premier contact avec VC et le dernier depuis longtemps. Maintenant, j'utilise git pour tout.

RCS - Système de contrôle de révision

Le codage en solo est si facile.

Pas ClearCase, du moins pour un système Unix / Linux (le programme d’installation est peut-être plus facile avec Windows). Il était plus facile pour moi d'apprendre un nouvel outil, Perforce, plutôt que de mettre à niveau notre serveur ClearCase.

J'utilise actuellement Perforce au travail et j'aime bien mais je ne sais pas si c'est le meilleur. La configuration de l'environnement de ligne de commande et du serveur Perforce est un peu compliquée, mais l'utilisation de Visual Client est relativement simple. J'aime penser que les utilisateurs ont un temps assez facile à utiliser pour les tâches quotidiennes. ce n'est que la configuration initiale prend du travail.

J'ai utilisé Visual SourceSafe et le détestais, mais c'était mieux que rien, mais pas beaucoup. Au cours des dernières années, nous avons utilisé quelque chose appelé QCVS de Qumasoft.com écrit, détenu et pris en charge par Jim Voris, le programmeur. Interface graphique simple, prix bas, bon support.

Fait juste le travail.