J'essaie de comprendre les avantages du système de contrôle de version distribué (DVCS).

J'ai trouvé Subversion Re-education et cet article de Martin Fowler très utiles.

Mercurial et d’autres DVCS promeuvent une nouvelle façon de travailler sur le code avec des changesets et des commits locaux. Il empêche la fusion de l'enfer et d'autres problèmes de collaboration

Cela ne nous concerne pas, car je pratique l'intégration continue et que travailler seul dans une agence privée n'est pas une option, à moins que nous ne fassions des expériences. Nous utilisons une branche pour chaque version majeure, dans laquelle nous corrigeons les bogues fusionnés à partir du coffre.

Mercurial vous permet d'avoir des lieutenants

Je comprends que cela peut être utile pour des projets très volumineux tels que Linux, mais je ne vois pas l'intérêt des petites équipes très collaboratives (5 à 7 personnes).

Mercurial est plus rapide, prend moins d’espace disque et une copie locale complète permet des opérations plus rapides de journalisation et de diff.

Cela ne m'inquiète pas non plus, car je n'ai pas remarqué de problèmes de vitesse ou d'espace avec SVN, même avec de très gros projets sur lesquels je travaille.

Je recherche vos expériences et / ou opinions personnelles d'anciens geeks de SVN. Surtout en ce qui concerne le concept de changesets et l' amélioration de la performance globale que vous avez mesurée.

UPDATE (12 janvier) : Je suis maintenant convaincu que cela vaut la peine d'essayer.

MISE À JOUR (12 juin) : J'ai embrassé Mercurial et cela m'a plu. Le goût de sa cerise locale s’engage. J'ai embrassé Mercurial juste pour l'essayer. J'espère que mon serveur SVN ne me dérange pas. Je me sentais tellement mal. C'était tellement bon. Ne veux pas dire que je suis amoureux ce soir .

FINAL UPDATE (29 juillet) : J’ai eu le privilège de relire le prochain livre d’ Eric Sink intitulé Version Control by Example . Il a fini de me convaincre. Je vais aller pour Mercurial.

Note: Voir "EDITER" pour la réponse à la question actuelle

Tout d’abord, lisez Subversion Re-education de Joel Spolsky. Je pense que la plupart de vos questions recevront une réponse ici.

Une autre recommandation, l’exposé de Linus Torvalds sur Git: http://www.youtube.com/watch?v=4XpnKHJAok8 . Cet autre pourrait également répondre à la plupart de vos questions, ce qui est très divertissant.

BTW, quelque chose que je trouve assez drôle: même Brian Fitzpatrick et Ben Collins-Sussman, deux des créateurs originaux de Subversion ont déclaré dans une conversation Google "désolé pour cela" en se référant au fait que la subversion soit inférieure au mercurial (et aux DVCS en général).

Maintenant, IMO et, en général, la dynamique d'équipe se développent plus naturellement avec n'importe quel DVCS, et l'un des avantages remarquables est que vous pouvez vous engager hors ligne, car cela implique les éléments suivants:

• Vous ne dépendez pas d'un serveur et d'une connexion, ce qui signifie des temps plus rapides.
• Ne pas être esclave de lieux où vous pouvez obtenir un accès Internet (ou un VPN) juste pour pouvoir vous engager.
• Tout le monde a une sauvegarde de tout (fichiers, historique), pas seulement du serveur. Cela signifie que n'importe qui peut devenir le serveur .
• Vous pouvez vous engager de manière compulsive si vous en avez besoin sans déranger le code des autres . Les commits sont locaux. Vous ne vous mettez pas les pieds sur les pieds quand vous vous engagez. Vous ne détruisez pas les constructions ou les environnements des autres en vous engageant.
• Les personnes sans "accès de validation" peuvent valider (car s'engager dans un DVCS n'implique pas le téléchargement de code), en abaissant la barrière pour les contributions, vous pouvez décider de retirer leurs modifications ou non en tant qu'intégrateur.
• Cela peut renforcer la communication naturelle puisqu'un DVCS rend cela essentiel ... dans la subversion, ce que vous avez à la place sont des courses engagées, qui forcent la communication, mais en gênant votre travail.
• Les contributeurs peuvent s'associer et gérer leur propre fusion, ce qui signifie finalement moins de travail pour les intégrateurs.
• Les contributeurs peuvent avoir leurs propres branches sans affecter les autres (tout en pouvant les partager si nécessaire).

A propos de vos points:

• La fusion de l'enfer n'existe pas dans DVCSland; n'a pas besoin d'être manipulé. Voir le point suivant .
• Dans les DVCS, tout le monde représente une "branche", ce qui signifie qu'il y a des fusions à chaque fois que des modifications sont extraites. Les branches nommées sont une autre chose.
• Vous pouvez continuer à utiliser l'intégration continue si vous le souhaitez. Pas nécessaire à mon humble avis, pourquoi ajouter de la complexité?, Gardez simplement vos tests dans le cadre de votre culture / politique.
• Mercurial est plus rapide dans certains cas, git plus rapide dans d’autres. Pas vraiment aux DVCS en général, mais à leurs implémentations particulières, autant que je sache.
• Tout le monde aura toujours le projet complet, pas seulement vous. La chose distribuée a à voir avec ce que vous pouvez valider / mettre à jour localement, partager / prendre de l'extérieur de votre ordinateur s'appelle pousser / tirer.
• Encore une fois, lisez Subversion Re-education. Les DVCS sont plus faciles et plus naturels, mais ils sont différents, n'essayez pas de penser que cvs / svn === base de tout le versioning.

J'apportais de la documentation au projet Joomla pour aider à prêcher une migration vers les DVCS, et ici, j'ai réalisé quelques diagrammes pour illustrer la centralisation par rapport à la distribution.

Centralisé

Distribué en pratique générale

Distribué au maximum

Vous voyez dans le diagramme qu'il y a toujours un "référentiel centralisé", et il s'agit de l'un des arguments préférés des fans du contrôle de version centralisée: "vous êtes toujours en cours de centralisation", et non, vous ne l'êtes pas, car le référentiel "centralisé" n'est qu'un référentiel tous sont d’accord (p. ex. un dépôt officiel de github), mais cela peut changer à tout moment.

Il s’agit maintenant du flux de travail typique des projets Open Source (par exemple, un projet avec une collaboration massive) utilisant des DVCS:

Bitbucket.org est un peu l’équivalent de github pour mercurial. Sachez qu’ils ont un référentiel privé illimité avec un espace illimité. Si votre équipe est inférieure à cinq personnes, vous pouvez l’utiliser gratuitement.

La meilleure façon de vous convaincre d'utiliser un DVCS est d'essayer un DVCS. Chaque développeur DVCS expérimenté qui a utilisé svn / cvs vous dira que cela en vaut la peine et qu'il ne sait pas comment il a survécu.

EDIT : Pour répondre à votre deuxième édition, je peux simplement rappeler qu’avec un DVCS, votre flux de travail est différent, je vous déconseille de chercher des raisons de ne pas l’essayer à cause des meilleures pratiques , c’est comme lorsque les gens disent nécessaires car ils peuvent contourner des modèles de conception complexes avec ce qu’ils font toujours avec le paradigme XYZ; vous pouvez bénéficier de toute façon.

Essayez, vous verrez que travailler dans "une branche privée" est en fait une meilleure option. Une des raisons pour lesquelles je peux expliquer pourquoi la dernière est vraie est que vous perdez la peur de vous engager , ce qui vous permet de vous engager à tout moment et de travailler de manière plus naturelle.

En ce qui concerne "la fusion de l'enfer", vous dites "à moins que nous n'essayions", je dis "même si vous expérimentez + maintaing + en même temps que la version révisée v2.0 ". Comme je le disais plus tôt, la fusion de l'enfer n'existe pas, car:

• Chaque fois que vous validez une branche non nommée et que vos modifications rencontrent les modifications d'autres personnes, une fusion naturelle se produit.
• Étant donné que les DVCS collectent davantage de métadonnées pour chaque validation, moins de conflits se produisent lors de la fusion ... vous pouvez même appeler cela une "fusion intelligente".
• Lorsque vous vous heurtez à des conflits de fusion, voici ce que vous pouvez utiliser:

De plus, la taille du projet n'a pas d'importance. Lorsque je passais de la subversion, je voyais déjà les avantages tout en travaillant seul, tout se sentait bien. Les changesets (pas exactement une révision, mais un ensemble spécifique de modifications pour des fichiers spécifiques pour lesquels vous incluez un commit, isolé de l'état de la base de code) vous permettent de visualiser exactement ce que vous voulez dire en faisant ce que vous faisiez avec un groupe de fichiers spécifique. pas toute la base de code.

Concernant le fonctionnement des changesets et l’amélioration des performances. Je vais essayer de l'illustrer avec un exemple que j'aime donner: le commutateur de projet mootools de svn illustré dans leur graphe de réseau github .

Avant

Après

Ce que vous constatez, c’est que les développeurs sont capables de se concentrer sur leur propre travail tout en s’engageant. ) mais comme la fusion est plus intelligente ici, ils ne le font souvent jamais ... même en cas de conflit de fusion (ce qui est rare), vous ne passez que 5 minutes ou moins à le résoudre.

Je vous recommande de chercher quelqu'un qui sache utiliser mercurial / git et de lui dire de vous l'expliquer. En passant environ une demi-heure avec des amis à la ligne de commande tout en utilisant mercurial avec nos ordinateurs de bureau et nos comptes bitbucket, leur montrant comment fusionner, et même créant des conflits pour eux, afin de voir comment les résoudre dans des délais aussi ridicules que possible. eux le vrai pouvoir d'un DVCS.

Enfin, je vous recommanderais d’utiliser mercurial + bitbucket au lieu de git + github si vous travaillez avec des utilisateurs Windows. Mercurial est aussi un peu plus simple, mais git est plus puissant pour une gestion de référentiel plus complexe (par exemple, git rebase ).

Quelques lectures supplémentaires recommandées:

• Systèmes de contrôle de révision distribués: Git vs. Mercurial vs. SVN
• Git vs. Mercurial: Détendez-vous
• Distributed Version Control & Git [Partie 1] & Distributed Version Control & Git [Partie 2]
• Git / Mercurial vs Subversion: Combattez!
• DVCS vs Subversion Smackdown, tour 3
• Pourquoi j'aime Mercurial More Than Git ( partie 1 , partie 2 )
• Contribuer avec Git: réduire les frictions de la collaboration Open Source avec Git VCS
• "Comment les DVCS ont-ils fonctionné pour vous jusqu'à présent?" - poste sur le Joomla! Liste de diffusion Framework Development demandant des commentaires après l’adoption expérimentale de mercurial et git pour Joomla! Projet de plateforme
• Branchement DVCS (avec Mercurial) - Une introduction détaillée et illustrée à quoi ressemble le branchement dans un DVCS, ce qui est probablement la caractéristique la plus importante de ces systèmes

Vous dites notamment que si vous restez essentiellement dans une seule branche, vous n’avez pas besoin de contrôle de version distribué.

C’est vrai, mais n’est-ce pas une restriction inutilement forte de votre façon de travailler, et une restriction qui ne s’adapte pas bien à plusieurs endroits dans plusieurs fuseaux horaires? Où le serveur de sous-version central doit-il être situé et tout le monde doit-il rentrer chez lui si ce serveur est en panne pour une raison quelconque?

Les DVCS sont à Subversion, ce que Bittorrent est à ftp

(techniquement, pas légalement). Si vous y réfléchissez bien, vous comprendrez peut-être pourquoi il s'agit d'un si grand bond en avant?

Pour moi, notre passage à git, a immédiatement abouti à

• Nos sauvegardes étant plus faciles à faire (juste "git remote update" et vous avez terminé)
• Plus facile à commettre de petites étapes lorsque vous travaillez sans accès au référentiel central. Vous venez de travailler et de synchroniser lorsque vous revenez sur le réseau hébergeant le référentiel central.
• Hudson construit plus rapidement. Beaucoup, beaucoup plus rapide à utiliser que git pull que la mise à jour.

Alors, considérez pourquoi bittorrent est meilleur que ftp, et reconsidérez votre position :)

Remarque: il a été mentionné qu'il existe des cas d'utilisation où ftp est plus rapide et plus facile que bittorrent. Cela est vrai de la même manière que le fichier de sauvegarde géré par votre éditeur favori est plus rapide à utiliser qu'un système de contrôle de version.

La principale caractéristique des systèmes de contrôle de version distribués est la partie distribuée. Vous ne récupérez pas une "copie de travail" du référentiel, vous clonez une copie complète du référentiel. C'est énorme, car il fournit des avantages puissants:

• Vous pouvez profiter des avantages du contrôle de version, même lorsque vous n’avez pas accès à Internet tel que ... Celui-ci est malheureusement surutilisé et surexprimé comme une raison pour laquelle DVCS est génial - ce n’est tout simplement pas un argument de vente fort nous nous trouvons en train de coder sans accès à Internet à peu près aussi souvent qu'il commence à pleuvoir des grenouilles.

• La vraie raison d'avoir un référentiel local est tueur, c'est que vous avez un contrôle total sur votre historique de validation avant qu'il ne soit transféré vers le référentiel maître .

Jamais corrigé un bug et fini avec quelque chose comme:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

Etc. Une telle histoire est désordonnée - il n'y avait en réalité qu'un correctif, mais maintenant, l'implémentation est répartie entre de nombreux commits contenant des artefacts indésirables, tels que l'ajout et la suppression d'instructions de débogage. Avec un système comme SVN, l’alternative est de ne pas s’engager (!!!) tant que tout n’est pas en marche pour que l’historique reste vierge. Même dans ce cas, des erreurs se glissent et la loi de Murphy attend de vous brutaliser lorsque des travaux importants ne sont pas protégés par le contrôle de version.

Avoir un clone local du référentiel, que vous possédez , corrige cela car vous pouvez ré-écrire l'historique en continuant à rouler les corrections "it it" et "oops" dans le commit "correctif de bogue". À la fin de la journée, un commit propre est envoyé au référentiel maître qui ressemble à:

r321 Fixed annoying bug.

C'est comme ça que ça devrait être.

La possibilité de réécrire l'histoire est encore plus puissante lorsqu'elle est combinée avec le modèle de ramification. Un développeur peut effectuer un travail entièrement isolé au sein d'une branche, puis, lorsqu'il est temps d'introduire cette branche dans le coffre, vous avez toutes sortes d'options intéressantes:

• Faire une fusion de vanille simple . Apporte tout dans les verrues et tout.

• Faites un rebase . Vous permet de trier l'historique de la branche, de réorganiser l'ordre des validations, de supprimer les validations, de rejoindre les validations ensemble, de réécrire les messages de validation, voire même de les modifier ou d'en ajouter de nouveaux! Un système de contrôle de version distribué prend en charge de manière approfondie la révision du code.

Une fois que j'ai compris comment les référentiels locaux me permettaient de modifier mon histoire pour préserver la santé mentale de mes collègues programmeurs et de mon avenir, j'ai raccroché SVN pour de bon. Mon client Subversion est maintenant git svn.

Permettre aux développeurs et aux gestionnaires d’exercer un contrôle éditorial sur l’historique des validations permet de créer un meilleur historique des projets et d’avoir un historique sans faille qui contribue réellement à ma productivité en tant que programmeur. Si toutes ces discussions sur la "réécriture de l'historique" vous effraient, ne vous inquiétez pas, c'est à quoi servent les référentiels centraux, publics ou principaux. L'histoire peut (et devrait!) Être réécrite jusqu'à ce que quelqu'un la ramène dans une branche d'un référentiel que d'autres personnes extraient. À ce stade, l'histoire doit être traitée comme si elle était gravée sur une tablette de pierre.

La réponse de dukofgamings est probablement aussi bonne que possible, mais je veux aborder la question sous un angle différent.

Supposons que ce que vous dites soit absolument vrai et qu’en appliquant les bonnes pratiques, vous évitiez les problèmes que DVCS devait résoudre. Cela signifie-t-il qu'un DVCS ne vous offrirait aucun avantage? Les gens puent à suivre les meilleures pratiques. Les gens vont se gâcher. Alors, pourquoi voudriez-vous éviter le logiciel conçu pour résoudre un ensemble de problèmes, choisissant plutôt de compter sur les gens pour faire quelque chose que vous pouvez prédire à l'avance qu'ils ne vont pas faire?

Oui, cela fait mal lorsque vous devez fusionner de grands commits dans la subversion. Mais c’est aussi une excellente expérience d’apprentissage, qui vous oblige à faire tout ce qui est possible pour éviter la fusion des conflits. En d'autres termes, vous apprenez à vous enregistrer souvent . Une intégration précoce est une très bonne chose pour tout projet co-localisé. Tant que tout le monde le fait, la subversion ne devrait pas poser trop de problèmes.

Git, par exemple, a été conçu pour le travail distribué et encourage les utilisateurs à travailler sur leurs propres projets et à créer leurs propres fourches pour une fusion (éventuelle) ultérieure. Il n’était pas spécifiquement conçu pour une intégration continue dans une "petite équipe hautement collaborative", comme le demande le PO. C'est plutôt le contraire, à bien y penser. Vous n'aurez aucune utilité pour ses fonctionnalités distribuées sophistiquées si tout ce que vous faites est assis dans la même pièce et travaillant ensemble sur le même code.

Donc, pour une équipe co-localisée utilisant des infrastructures critiques, je ne pense vraiment pas que cela importe beaucoup si vous utilisez un système distribué ou non. Cela se résume à une question de goût et d'expérience.

Parce que vous devriez continuellement contester vos propres connaissances. Vous aimez la subversion, et je peux comprendre car je l’utilise depuis de nombreuses années et j’en suis très heureux, mais cela ne veut pas dire que c’est toujours l’outil qui vous conviendrait le mieux.

Je crois que lorsque j'ai commencé à l'utiliser, c'était le meilleur choix à l'époque. Mais au fil du temps, d’autres outils sont apparus et je préfère maintenant git, même pour mes projets personnels.

Et la subversion a quelques défauts. Par exemple, si vous renommez un répertoire sur un disque, celui-ci n'est pas renommé dans le référentiel. Le déplacement de fichier n'est pas pris en charge, ce qui oblige un fichier à déplacer une opération de copie / suppression, rendant difficile la fusion des modifications lorsque les fichiers ont été déplacés / renommés. Et le suivi des fusions n'est pas vraiment intégré au système, mais implémenté sous forme de solution de contournement.

Git résout ces problèmes (y compris en détectant automatiquement si un fichier a été déplacé, vous n'avez même pas besoin de lui dire que c'est un fait).

D'autre part, git ne vous permet pas de vous connecter à des niveaux de répertoires individuels, contrairement à Subversion.

Donc, ma réponse est que vous devriez rechercher des solutions de rechange, voir si cela répond mieux à vos besoins que ce que vous connaissez, puis décider.

En ce qui concerne les performances, Git ou tout autre DVCS présente un avantage considérable par rapport à SVN lorsque vous devez passer d’une branche à l’autre ou passer d’une révision à l’autre. Comme tout est stocké localement, les choses sont beaucoup plus rapides que pour SVN.

Cela seul pourrait me faire basculer!

Si vous vous en tenez à l'idée qu '"en appliquant les meilleures pratiques, vous n'avez pas besoin d'un DVCS", pourquoi ne pas considérer que le flux de travail SVN est un flux de travail, avec un ensemble de meilleures pratiques, et que le flux de travail GIT / Hg est un flux de travail différent, avec un ensemble différent de meilleures pratiques.

git bisect (et toutes ses implications sur votre référentiel principal)

Dans Git, un principe très important est que vous pouvez trouver des bugs en utilisant git bisect. Pour ce faire, vous prenez la dernière version que vous avez exécutée qui fonctionnait normalement et la première version que vous avez exécutée dont l'échec était connu, et vous effectuez (avec l'aide de Git) une recherche binaire pour déterminer quelle validation a été causée par le bogue. Pour ce faire, votre historique de révision doit être relativement exempt d’autres bogues susceptibles d’interférer avec votre recherche de bogues (croyez-le ou non, cela fonctionne plutôt bien dans la pratique, et les développeurs du noyau Linux le font tout le temps).

Pour atteindre cette git bisectcapacité, vous développez une nouvelle fonctionnalité sur sa propre branche de fonctionnalités , vous la rebasonnez et nettoyez l’historique (de sorte que vous ne disposiez pas de révisions inopérantes dans votre historique, mais uniquement de nombreuses modifications que vous apportez à part entière. résoudre le problème), puis lorsque la fonctionnalité est terminée, vous le fusionnez dans la branche principale avec l’historique de travail.

En outre, pour que cela fonctionne, vous devez définir avec précision la version de la branche principale à partir de laquelle vous démarrez votre branche. Vous ne pouvez pas simplement partir de l’état actuel de la masterbranche car il peut y avoir des bogues non liés. Le conseil de la communauté du noyau est donc de commencer à travailler à partir de la dernière version stable du noyau (pour les grandes fonctionnalités) ou de commencer à travailler. de la dernière version candidate étiquetée.

Vous pouvez également sauvegarder votre progression intermédiaire en envoyant la branche de fonctionnalités à un serveur entre-temps. Vous pouvez également la transmettre à un serveur pour la partager avec une autre personne et obtenir des commentaires avant la fin de la fonctionnalité, avant de devoir transformez le code en une fonctionnalité permanente de la base de code que tout le monde * de votre projet doit traiter.

La page de manuel gitworkflows constitue une bonne introduction aux flux de travail pour lesquels Git est conçu. De plus, pourquoi Git est meilleur que X traite des workflows git.

Grands projets distribués

Pourquoi avons-nous besoin de lieutenants dans une équipe hautement collaborative dotée de bonnes pratiques et de bonnes habitudes de conception?

Parce que dans des projets comme Linux, il y a tellement de personnes impliquées qui sont réparties géographiquement, qu'il est difficile d'être aussi collaborateur qu'une petite équipe partageant une salle de conférence. (Je suppose que pour le développement d'un produit volumineux tel que Microsoft Windows, même si tous les utilisateurs se trouvent dans le même bâtiment, l'équipe est tout simplement trop nombreuse pour maintenir le niveau de collaboration qui permet à un VCS centralisé de fonctionner sans lieutanants.)

Pourquoi ne pas les utiliser en tandem? Sur mon projet actuel, nous sommes obligés d'utiliser CVS. Cependant, nous conservons également les référentiels git locaux afin de développer les fonctionnalités. C’est le meilleur des deux mondes, car vous pouvez essayer diverses solutions tout en conservant les versions de vos travaux sur votre propre ordinateur. Cela vous permet de revenir aux versions précédentes de votre fonctionnalité ou d'essayer plusieurs approches sans vous poser de problèmes lorsque vous gâchez votre code. Avoir un référentiel central vous donne alors les avantages d'avoir un référentiel centralisé.

Je n'ai pas d'expérience personnelle avec DVCS, mais d'après ce que je tire des réponses ici et de certains documents liés, la différence la plus fondamentale entre DVCS et CVCS est le modèle de travail utilisé.

DVCS

Le modèle de travail de DVCS est que vous effectuez un développement isolé . Vous développez votre nouvelle fonctionnalité / correction de bug indépendamment de toutes les autres modifications jusqu'au moment où vous décidez de la diffuser au reste de l'équipe. Jusqu'à ce moment-là, vous pouvez effectuer les enregistrements de votre choix, car personne d'autre ne s'en préoccupera.

CVCS

Le modèle de travail de CVCS (en particulier Subversion) est que vous effectuez un développement collaboratif . Vous développez votre nouvelle fonctionnalité / correction de bogues en collaboration directe avec tous les autres membres de l'équipe et toutes les modifications sont immédiatement disponibles pour tous.

Autres différences

Les autres différences entre svnet git/ hg, telles que les révisions par rapport aux ensembles de modifications, sont accessoires. Il est très possible de créer un DVCS basé sur des révisions (comme Subversion les a) ou un CVCS basé sur des changesets (comme Git / Mercurial les ont).

Je ne recommanderai aucun outil en particulier, car cela dépend principalement du modèle de travail avec lequel vous (et votre équipe) êtes le plus à l'aise.
Personnellement, je n'ai aucun problème à travailler avec un CVCS.

• Je n'ai aucune crainte de vérifier les données, car je n'ai aucun problème à en faire un état incomplet, mais compilable.
• Lorsque j’ai connu Merge-Hell, c’était dans des situations où cela s’était produit à la fois svnet git/ hg. Par exemple, la version 2 de certains logiciels était maintenue par une équipe différente, utilisant un autre VCS, pendant que nous développions la version 3. De temps en temps, des corrections de bogues devaient être importées du VCS V2 vers le VCS V3, ce qui signifiait essentiellement une très grande vérification sur le VCS V3 (avec tous les correctifs dans un seul ensemble de modifications). Je sais que ce n’était pas idéal, mais la direction a décidé d’utiliser différents systèmes VCS.