La documentation pour gérer le dépôt WP officiel est exclusivement consacrée à l'utilisation de la ligne de commande. Bien que je n'aie aucun parti pris contre cela, j'ai peu d'expérience avec VCS et deux (ou trois) différents que je devrai trouver et utiliser dans un avenir proche.
Donc pour l'instant je l'utilise avec des fonctionnalités d'intégration VCS dans les IDE (NetBeans, PHPStorm). Ce qui me laisse souvent perplexe sur les détails et les façons de faire les choses correctement.
Existe-t-il de bons articles / publications / guides sur l'utilisation du référentiel SVN officiel (ou au moins SVN en général) avec des IDE ou d'autres outils basés sur une interface graphique? Quelque chose qui se concentre sur les concepts et le flux de travail, plutôt que de taper des lignes obscures dans la console.
Réponses:
Je vais faire de cette réponse un article de blog car il est allé légèrement hors sujet GRIN. Sur http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ au chapitre 6, j'ai fait quelques explications pour SVN dans eclipse mais vous cherchez probablement autre chose.
L'histoire que j'ai faite ici concernait votre commentaire
"Donc, pour l'instant, je l'utilise avec des fonctionnalités d'intégration VCS dans les IDE (NetBeans, PHPStorm). Ce qui me laisse souvent perplexe sur les détails et les façons de faire les choses correctement." et "Quelque chose qui se concentre sur les concepts et le flux de travail, plutôt que de taper des lignes obscures dans la console."
J'ai entendu dire que, plus souvent, je voulais expliquer SVN dans un contexte plus large, par exemple en décrivant d'abord les "langages de programmation", puis expliquer PHP vous fait mieux comprendre PHP et, dans ce cas, la gestion de la configuration d'abord, puis la solution SVN.
Je vais simplement taper quelque chose ici et s'il est hors sujet ou non nécessaire, je le supprimerai:
------------ 8 <----------------
Si vous installez Eclipse PDP, j'ai écrit ceci: [ http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ ]
Si vous faites défiler vers le bas pour # 6, j'explique brièvement comment installer collabnet subclipse dans Eclipse (en gros, pointez simplement sur le serveur, sélectionnez tout et installez)
Dans Eclipse avec n'importe quel outil de gestion de version, les commandes de gestion de version sont toujours sous clic droit "TEAM". Comme vous pouvez basculer entre les projets, vous pouvez prendre en charge plusieurs outils de gestion de versions et la plupart des commandes sont familières aux outils via l'interface graphique.
Plugins
Comme vous le savez: pour un nouveau projet de plugin WordPress, vous obtenez un emplacement svn de WordPress.org (dans votre boîte aux lettres), ils utilisent le tronc pour votre dernier code et des copies de «balises» pour les versions stables. (Motif CM TRÈS basique). C'est ce que vous voyez à première vue.
Votre projet sera donc lié à TRUNK. et vous pouvez simplement vous y engager. C'est l'endroit où vous travaillez (mais pas d'où vous sortez) (sauf si vous spécifiez 'trunk' dans le fichier readme.txt comme emplacement pour votre code final).
De plus, vous pouvez inclure WordPress / wp-includes et / wp-admin dans votre projet Eclipse en tant que bibliothèques afin que vous puissiez rechercher des fonctions et voir les fonctions obsolètes. Ceux-ci ne sont pas accessibles en écriture et ne relèvent donc pas de la gestion des versions (!). C'est du côté client donc pas les "externes" qui sont réellement liés dans le projet de gestion de version.
Dès que vous avez une version stable, sélectionnez le truc et cliquez avec le bouton droit sur "équipe" et "créer une balise / branche", cela ouvre l'emplacement svn WordPress et vous pouvez sélectionner le répertoire des balises et taper un nouveau numéro et votre nouvelle version est en direct (ce qui peut être utile pour quelqu'un qui lit ceci). Notez que vous ne devez pas sélectionner la racine de votre projet mais tout le reste, sinon cela créera cette racine également sous vos balises / 2.3.4 qui n'est pas ce que vous voulez, vous voulez que tout ce qui se trouve sous la racine soit dans votre répertoire / tag.
Voir la publication pour quelques captures d'écran.
http://wp.leau.co/files/2011/02/image_thumb17.png
WordPress lui-même contributeur
Si vous êtes un contributeur, vous pouvez utiliser la même chose que ci-dessus, mais vous créez des "correctifs" à partir des modifications que vous avez apportées. "Patches" est un concept dans le monde CM, par exemple la subversion fournit ce RTC jazz ou. Avec le bouton droit de la souris "Appliquer le patch", vous pouvez appliquer un patch si vous avez un patch qui n'a pas encore été appliqué au tronc WordPress.
Certaines personnes s'engagent également directement dans le coffre.
WordPress lui-même "Lire"
Il suffit de créer un projet 'WordPress' qui contient une extraction de la version / LATEST dans le coffre (du code de subversion), encore une fois, via team> checkout.
Personnellement, je ne fais pas cela, mais j'utilise simplement une exportation du dernier code (avec force) pour simplement obtenir un répertoire avec la dernière version de WordPress (donc qui ne relève d'aucune gestion de version)
En général
Puisque vous avez une certaine expérience avec VCS et avec des questions concernant SVN: Fondamentalement, tous les outils de version concernent le concept de nommage des choses. Ou mieux dit avoir le meilleur espace de noms. Vous pouvez mapper la plupart des commandes de CVS, Git, RTC, ClearCase, SourceSafe etc ... au concept autour de cet espace de noms. Puisque vous avez une / peu d'expérience avec d'autres outils, un peu plus large:
Les nouvelles personnes se regardent souvent aveuglément sur certaines commandes ou sur un élément spécifique de la fonctionnalité, mais fournir la meilleure option pour placer tous les éléments nécessaires dans un espace de noms est l'élément central.
Donc, comme il s'agit essentiellement de la fonctionnalité de base de ces outils, le terme "gestion des versions" est incorrect. Il s'agit en fait d'un gestionnaire d'espace de noms.
Donc si vous avez
Vous pouvez créer un nom unique pour chaque "chose". Ce qui précède est une implémentation d'un espace de noms dont vous avez besoin dans un certain but en utilisant l'un des outils d'espace de noms.
Presque tous les concepts de ce monde peuvent être mappés à cela, donc la façon dont vous POUVEZ prendre en charge votre espace de noms / taxonomie personnalisé dépend des capacités de votre outil. Donc ... cela dépend vraiment des concepts et des choix que les concepteurs des centaines d'outils différents ont faits.
Dans un bon outil, vous pouvez cliquer et voir cette taxonomie complète dans un arbre ou zoomer dans cet arbre.
C'est le cœur: un outil qui peut vous aider à gérer la complexité (voir la complexité dans wikipedia: http://en.wikipedia.org/wiki/Complexity ) en vous donnant de bons outils pour gérer VOTRE taxonomie PERSONNALISÉE. La personne qui crée la taxonomie et pense à la mettre en place est le gestionnaire de configuration.
Imaginez simplement que quelqu'un vous demande de créer un ensemble de taxonomies personnalisées dans WordPress qui représentent TOUS les objets de son entreprise, y compris la possibilité d'en retirer l'état tel qu'il était à un moment donné. Vous pouvez faire beaucoup de choix de conception et tout le monde produira autre chose en fonction de certains choix. Certains contiendront plus de fonctionnalités, certains sont plus simples et les plus complexes ont tous pris des décisions différentes. Ce sont "ces outils". Je ne comprends donc jamais les discussions au niveau des outils sur la gestion des versions car c'est complètement bizarre.
En PHP de nos jours, vous pouvez créer des espaces de noms, créer une hiérarchie avec des répertoires, appliquer des conventions de dénomination aux objets et au sein de ces méthodes. Si vous prenez un fichier que vous avez placé dans une hiérarchie, allez un peu plus loin. Vous ajoutez un / derrière et placez un numéro de version derrière. Ce n'est même pas suffisant car vous voudriez que l'équipe A travaille sur la version 4 du fichier et que l'équipe B travaille sur cette version. Vous ajoutez donc un autre / et ajoutez l'ID de la branche. Voici comment vous créez l'espace de noms. Selon l'outil, vous pouvez devenir aussi fou que vous le souhaitez.
Mais cela signifie: si quelqu'un vient vous demander "où est le document Z", vous ne pouvez pas répondre. Parce que dans un système de gestion de version, le "document Z" n'existe pas. Et même quand il dit me donner "document Z version 5", vous ne pouvez pas le remettre car il pourrait signifier "document Z version 5" de la branche de l'équipe 1 ou "document Z version 5" de la branche de l'équipe 2. Il s'agit de nommer. «document Z version 5» est simplement une approche de dénomination incorrecte dans l'espace de noms défini.
Dans Subversion, vous ne pouvez le faire que de manière limitée, ce qui le rend simple à comprendre. Certains concepts correspondaient à cela:
"version"
Une version est une révision d'un certain élément. Ainsi, par exemple, wp-config.php version 5. Dans un outil comme ClearCase, vous pouvez également voir les versions individuelles des éléments et "valider" les fichiers individuels (mais aussi effectuer des validations atomiques ou changer de jeu ou autre).
Dans Subversion, les versions de gestion sont plus limitées:
travailler sur une version
Dans Subversion, le cas d'utilisation par défaut est que vous téléchargez simplement toutes les choses sur votre disque dur à partir d'une extraction de référentiel , travaillez sur les choses, puis validez et faites face à toutes les modifications apportées par d'autres personnes après quoi vous résolvez les conflits. Ces concepts que vous voyez dans l'interface graphique. SI vous voulez empêcher quelqu'un d'autre de modifier également votre exemple hello.doc, alors vous le VERROUILLER ce qui signifie: personne d'autre ne devrait pouvoir le changer.
Je n'aime vraiment pas cette idée :( à mon humble avis, c'est une très mauvaise pratique. Pour la comparaison et la compréhension: dans ClearCase, un contrôle est plus ou moins comparable à un verrou et un enregistrement est un commit (dans subversion, l'enregistrement est un alias pour commit) . Tel est le cas d'utilisation par défaut dans ClearCase où il prend en charge également des détournements qui est la même que celle d' une subversion caisse mais sur les fichiers sélectionnés à mon humble avis ce qui est beaucoup plus propre de plus , même lorsque vous faites le.. la caisse ClearCase il vous donne 3 options: autres les gens peuvent ne pas y travailler (par exemple avec des documents Word), d'autres personnes peuvent y travailler si vraiment nécessaire et "tout le monde peut y travailler" (par exemple avec des fichiers de code source) Donc ... c'est ce que signifie checkout, lock and commit dans SVN.
composants et baselining
Dans des outils comme RTC et ClearCase, vous pouvez regrouper des éléments en composants. Puissant car ces composants font partie de l'espace de noms et obtiennent leurs propres versions en les baseline. Ainsi, par exemple, le composant "WordPress" obtient la version de base 4.53. Ces lignes de base sont alors des objets en eux-mêmes qui peuvent ensuite également obtenir des métadonnées telles que "en test". Cependant SVN n'a rien de tout cela. Donc... :
Mots clés
Dans SVN (et ainsi de suite sur le site WordPress), vous voyez des répertoires avec des numéros dans un répertoire global appelé 'tags'. Une idée de contournement. Il vous suffit de saisir un certain référentiel et de le vider (basé sur un fichier) dans un répertoire tags / 3.2.4. C'est ça. Il n'a aucune relation dans l'espace de noms de gestion des versions, etc ... juste un simple répertoire .... SIGH ..... Impossible à mon humble avis de faire une gestion de configuration avec ce genre d'outil. Ce n'est donc pas un objet de métadonnées où vous pouvez créer un script et attribuer des propriétés et faire les choses les plus folles non ... c'est juste un répertoire ............. Dans RTC pour comparaison, vous pouvez faire un ' instantané 'd'une certaine ligne de base pour prendre également en charge ce cas d'utilisation. Dans ClearCase UCM, vous créez une nouvelle branche / flux d'une certaine ligne de base, puis vous la "visualisez".
branches
Pour autant que je sache, cela n'est pas utilisé dans l'environnement WordPress, mais je me trompe peut-être et il y a des équipes qui le font pour les versions de WordPress pour sauvegarder les modifications de port dans les anciennes versions. Je ne sais donc peut-être pas que quelqu'un d'autre le sait.
Ceci est utilisé pour l'arborescence de l'espace de noms. Pour que 2 équipes travaillent sur le même code, vous pouvez dire "en anglais" \ team 1 \ hello.doc et \ team 2 \ hello.doc. Les deux équipes vont ensuite travailler et après un certain temps, vous avez \ team 1 \ hello.doc \ version 51 et \ team 2 \ hello.doc \ version 23. (donc l'équipe 1 a fait 51 versions et l'équipe 2 en a fait 23 versions). Vous avez maintenant la possibilité de fusionner de l'équipe de branche 1 à l'équipe de branche 2 et vous obtiendrez des fusions dans l'équipe 2 mais à la fin l'équipe 2 aura tous les changements de l'équipe 1 (version 24) et les branches individuelles montreront toujours le travail pour chaque d'eux.
Dans RTC et ClearCase, ce n'est pas utilisé mais un objet plus avancé appelé "streams" (pour comparaison). D'un point de vue bas, vous pouvez les considérer comme les mêmes MAIS ....... quand vous êtes dans la vraie vie, vos branches contiendront BEAUCOUP de choses. Donc, dans le monde réel, vous devrez prendre des notes, des notes de version, de la documentation, etc. et 56 et vous pouvez les libérer séparément.
À mon humble avis, si vous souhaitez configurer les choses correctement, vous donnez à CHAQUE personne un ou plusieurs flux / branches personnels. Ils peuvent donc s'enregistrer / valider et extraire de là et cela ne dérange personne. seulement quand quelqu'un est prêt, ils "livrent" leurs trucs par exemple au flux d'équipe et le flux d'équipe livre au flux d'intégration etc ... Dans WP, les versions sont probablement des branches mais pour les personnes ordinaires: elles travaillent toutes dans la même branche. Un inconvénient car les "projets de test" sont alors dans c: \ temp et non sous gestion des versions et vous ne pouvez pas avoir un groupe de personnes travaillant temporairement sur la fonctionnalité X qui ne sera nécessaire que dans 5 versions.
le monde idéal et les compromis
si vous avez \ team1 \ hello.doc et que quelqu'un copie dans \ team2 \ ALSO hello.doc qu'il s'agit de BAaaaaad. Depuis maintenant, nous avons 2 éléments avec des ID différents où l'utilisateur pense qu'ils sont les mêmes mais le système les traite comme différents. C'est ce qu'on appelle des «jumeaux maléfiques» et vous ne devriez jamais faire cela dans un tel environnement. Toujours fusionner ou à la base des branches. Si vous comprenez des jumeaux maléfiques, vous comprenez les branches (pourquoi cela est mauvais: car lors d'une fusion, ils seront traités comme 2 entités différentes alors que vous voulez qu'ils soient traités comme les mêmes) (ou un type de comportement différent dans différents systèmes). Si un nouvel utilisateur fout quelque chose, c'est surtout ça. `` Je viens de supprimer hello.doc et de le recopier dans ' argh
CHANGEMENTS
SVN n'offre pas de support pour ce MAIS il existe des outils que vous pouvez intégrer avec lui pour prendre en charge une sorte de gestion intégrée du changement / ALM. Dans des outils comme ClearCase- variante UCM ou RTC vous ne pouvez pas changer 1 lettre sans qu'il y ait un défaut, RFC, ticket, etc ... En SVN quand vous vous engagezvous pouvez taper une description de votre commit atomique. Signification: vous devriez essayer d'avoir vos changements dans les morceaux "patchables" en d'autres termes: faites un commit atomique par défaut / changement pour avoir un peu ce comportement. (mais bien sûr, il n'est nulle part après tout lié ensemble dans une arborescence de noms comme dans la base de données ClearCase) (afin que vous puissiez automatiser les notes de publication ou aider le pauvre gars en tant que gestionnaire de déploiement à obtenir des tonnes de nouveaux ensembles de code, de modifications, de versions et d'essayer de le mélanger sans aucun outil réel pour lui donner un aperçu de ce que c'est réellement).
Étant donné que SVN ne prend pas en charge la gestion des changements, WordPress est configuré pour utiliser TRAC: http://core.trac.wordpress.org/ comme vous le savez parce que vous y vivez :)
Je pense que TRAC est là parce qu'un véritable outil comme ClearCase ou RTC qui a des changements intégrés en tant qu'objets (oui celui contre lequel vous programmez) est manquant. Vous disposez donc d'un outil dans lequel vous discutez et soumettez une "sorte de" ensemble de modifications (alors que ce concept manque également). Ce ne sont donc que les "patchs" juste un tas de fichiers sans aucune des métadonnées que vous attendez d'un bon système (donc je suis maintenant dans un état grincheux). Le nombre de TRAC est important car il s'agit de l'ID global dans l'arbre de nommage lié à certaines modifications.
Apporter des changements
C'est quelque chose à écrire dans un article de blog séparé. En bref: dans le monde idéal, vous voudriez sélectionner les modifications que vous souhaitez «livrer» (ou un autre concept) et ne vous inquiétez pas des fichiers, des répertoires (versions de). Vous venez de "livrer RFC 3 et 5". C'est ainsi que ClearCase UCM ou RTC fonctionne. Dans SVN / base clearcase, vous «validez» un tas de fichiers où nous espérons que vous avez pris la bonne décision. C'est une grande différence et une différence importante. (c'est pourquoi SVN est principalement utilisé conjointement avec par exemple jira / clearquest / etc ... pour atteindre ce comportement). Patcher .... ne fournit pas, c'est plus d'un flux à un autre comme un 'patch' uhm.
Externes
Dans d'autres outils, cela est différent dans SVN, c'est plus simple: si vous avez du code provenant d'une partie qui n'est pas la vôtre, vous pouvez le traiter comme une version externe gérée et ... pour revenir au concept de base: vous voulez dire que une partie ne relève pas de la responsabilité de l'espace de nommage, car il s'agit de nommer. MAIS même s'il est externe il relève de votre responsabilité.
Dans l'interface graphique, il n'y a pas de workflow dans la "souris droite" habituelle mais il est défini dans la structure du projet. Cela fait donc partie de votre définition.
Ce concept, s'il est utilisé, est défini dans le CMP IEEE comme requis pour définir (voir ci-dessous)
Intégration et fusion
Comme dit. Le paradigme derrière SVN est d'obtenir des choses localement, de faire votre travail, puis de vous engager et d'avoir le s ***. Dans l'interface graphique, vous obtenez exactement le même outillage que la plupart des autres. Ici, vous devez vraiment comprendre la fusion tripartite, la fusion bidirectionnelle et la différence entre les conflits qui peuvent être résolus automatiquement et les conflits qui ne peuvent pas être résolus automatiquement. Ce dernier se décline alors en 2 classes: celles où l'outil peut vous proposer quel serait le bon résultat final et celles où il ne sait pas quelle serait la fin. Vous avez posé des questions sur l'interface graphique, mais sur la ligne de commande, vous obtenez des fichiers d'informations sur ce que vous devez corriger / fusionner avant de valider.
Beaucoup plus pour un article de blog. (par exemple, le développement Open Source versus le développement d'entreprise et créer des meisters et des gestionnaires d'intégration car vous devez vraiment faire des choix différents ici).
Dernier point mais non le moindre, le CMP
Ce que vous demandez, c'est un plan de gestion de la configuration pour WordPress. Ceci est un document IEEE. Signification: quels que soient les millions de plans de gestion de configuration que vous trouvez sur Google, ils sont tous valides par rapport à l'IEEE spécifié (plusieurs versions) du CMP.
Tout comme (par exemple HTTP) les RFC, il y a le CMP IEEE.
Ce plan contient des sections définies telles que "comment traiter les éléments externes" et "à quoi ressemble l'espace de noms, comment nous récupérons les éléments et comment nous reproduisons les éléments", les rôles, les responsabilités, etc.
À partir de ce CMP, vous pouvez ensuite créer des instructions de travail. Quiconque veut savoir quelles sont les règles peut alors lire le CMP.
Dans un contexte open source, le rôle de «gestionnaire de configuration» est souvent manquant. Vous manquez donc également le plan de gestion de la configuration.
Différent d'un RFC public (par exemple URI ou HTTP) Vous devez payer pour le document standard IEEE mais ... si vous Google vous le trouverez ici et là.
Rue de livraison
Dans une rue de livraison, vous auriez une équipe qui réfléchit à de nouvelles idées commerciales. Vous avez un département de maintenance obtenant un gazillion de bogues de production dans leur système. Vous auriez plusieurs équipes travaillant sur le même code. et dans chaque sous-rue, vous auriez une équipe d'exigences définissant les exigences. Une équipe d'architecture divisée en une équipe fonctionnelle et une équipe opérationnelle (les cas d'utilisation vont à l'équipe fonctionnelle et les non fonctionnels à l'équipe opérationnelle). Vous auriez souvent différentes versions parallèles en direct dans un environnement de test unitaire, des environnements d'acceptation, des environnements de charge et de contrainte, des environnements de test fonctionnels, des environnements de test de pré-production et des environnements de production.
Dans chacun d'eux se trouvent des versions qui sont toutes reliées les unes aux autres.
une version sur un environnement de test spécifique est liée à un ensemble de versions liées à un RFC spécifique et celle-ci est liée à une version spécifique d'une exigence. L'exigence est ensuite liée à une version spécifique d'un ensemble de tests. TOUS relèvent de la gestion des versions.
Dans WP avec SVN / TRAC, je n'ai pas encore trouvé la base de données des exigences et la base de données de version des exigences. (afin que vous puissiez effectuer des analyses d'impact et voir quel code change si vous modifiez 1 exigence) (et que dans une nouvelle version, vous pouvez imprimer quelles exigences ont changé). J'ai vu des éléments individuels dans TRAC où des liens sont créés vers d'autres éléments individuels dans TRAC dans les commentaires. Je n'ai pas non plus vu de traçabilité entre les articles TRAC et le code autrement que dans les commentaires. Cela signifie donc que les gens font beaucoup dans leur tête et cela dépend beaucoup d'une communauté active ou de développeurs principaux, car ils ont une grande partie de cela dans leur cerveau.
Mais cela va loin du sujet sourire
OSLC pour ALM
Juste une note de plus pour cette histoire: ne serait-il pas bien qu'il y ait un seul ensemble de normes pour tous ces outils de gestion du cycle de vie des applications (ALM)? Quelqu'un y a pensé et il existe maintenant des normes pour que tous les concepts soient placés à un niveau d'abstraction plus élevé, puis mis en œuvre dans les outils. Google: OSLC pour ALM. (pour que tous les outils puissent se parler et pour l'utilisateur: que vous les compreniez tous en comprenant la couche d'abstraction).
CALME
Un pas de plus si vous avez le temps: le monde se dirige maintenant vers C / ALM, une nouvelle génération de produits où les processus et l'outillage sont une chose intégrée afin que vous n'ayez plus à vous demander quel est le processus. Le premier produit de cette génération est le RTC. Donc, si vous comprenez bien SVN ou comprenez ClearCase ou Jira ou Trac ou ANT ou Agile ou RUP ou iRUP ou tout autre processus, gestion de version, gestion des changements, gestion de construction, vous aurez besoin de tout cela pour comprendre RTC car tout cela est combiné en une seule chose, car ils sont tous liés ensemble et cela sur lui-même s'interface via OSLC afin que n'importe lequel de ces anciens outils puisse se "brancher".
Mais maintenant je suis vraiment hors sujet.
la source
Je n'utilise pas (largement recommandé) TortoiseSVN pour le moment, mais il s'avère qu'il a un manuel très complet, disponible en ligne et téléchargeable en plusieurs langues .
Dans ses propres mots:
À peu près ce que je cherchais, en le lisant maintenant.
la source
Si vous utilisez Windows, vous pouvez essayer TortoiseSVN (http://tortoisesvn.tigris.org/). Il ne s'intègre pas à l'IDE mais il s'intègre à l'Explorateur Windows afin que vous puissiez également cliquer avec le bouton droit sur l'archivage / l'extraction de votre code.
la source
Le meilleur GUI que j'ai vu est http://blog.ftwr.co.uk/archives/2005/11/03/windows-wordpress-toolbox/
Il y a un excellent tutoriel visuel ici basé sur mercurial http://hginit.com/
Cela dépend en grande partie de la qualité de l'intégration de svn et git de votre IDE, ce qui facilite les choses, par exemple Eclipse a beaucoup d'outils, mais quelque chose comme ultraedit (que j'utilisais auparavant) a un étrange interface et système de contrôle de version.
Le sujet souffre du syndrome de l'ennui, du moins pour moi, il est difficile d'apprendre les détails à cause de cela, j'ai trouvé que regarder des vidéos YouTube sur le sujet a vraiment aidé la courbe d'apprentissage x100.
la source