Piste :

Différences ¶

Ci-dessous, les différences entre deux révisions de la page.

--- fr:tutoriels:utiliser-composer [2015/03/09 09:07] – [Développer une application et des modules séparément] laurent
+++ fr:tutoriels:utiliser-composer [2015/03/09 11:42] – laurent
@@ Ligne 159: / Ligne 159: @@
 ===== Développer une application et des modules séparément =====
-Il arrive que l'on développe une application qui utilise des modules externes (utilisés par d'autres projets) que l'on a soit-même développé ou auxquels on contribue. Et que l'on veuille dans le même temps améliorer le code de ces modules externes. Cependant, les installer avec Composer impose que l'on commit les modifications dans leurs dépôts respectifs. Cela veut dire qu'il va certainement falloir commiter à de nombreuses reprises lors du debuggage et la mise au point. De quoi "pourrir" l'historique du dépôt des modules. Et de nombreux "Composer update" en ligne de commande...
+Il arrive que l'on développe une application qui utilise des modules externes (utilisés par d'autres projets) que l'on a soit-même développé ou auxquels on contribue. Et que l'on veuille dans le même temps améliorer le code de ces modules externes.
+On aurait donc une application dans un dépôt git, et les autres modules dans d'autres dépôt git. L'application aurait son composer.json référençant les paquets de ces modules, et donc au final un répertoire @@vendor/@@ contenant les fichiers de ces modules.
+Cependant, installer ces modules avec Composer impose que l'on commit les modifications dans leurs dépôts respectifs. Cela veut dire qu'il va certainement falloir commiter à de nombreuses reprises lors du debuggage et la mise au point. De quoi "pourrir" l'historique du dépôt des modules. Et de nombreux "Composer update" en ligne de commande...
 On peut bien sûr limiter ces commits en écrivant des tests unitaires dans les dépôts des modules, mais cela n'est pas toujours suffisant : on ne peut pas tester l'intégration du module dans une application... sans application.
@@ Ligne 175: / Ligne 179: @@
-TODO: verifier le comportement de composer avec des changements dans le dépôt local de vendor/monmodule/:
+TODO: verifier le comportement de composer avec des changements dans le dépôt local de vendor/monmodule/. Ici les tests ont été fait alors que Composer a fait un checkout de origin/master.
+   * changer de remote (sans modification) + composer update.
+     * exemple: on est sur master -> origin/master et on fait un  git checkout -b cp-master --track composer/master
+     * Résultat : RAS
    * changement dans la branche tracké via "composer"
-     * modif puis composer update/install. Résultat : ?
+     * modif puis composer update/install sans nouvelle version. Résultat : RAS
-     * modif puis commiter puis  composer update/install. Résultat : ?
+     * modif puis commiter puis  composer update/install sans nouvelle version. Résultat : RAS
-     * modif puis commiter puis pusher puis composer update/install. Résultat : ?
+     * modif puis commiter puis pusher puis composer update/install sans nouvelle version. Résultat : on ne peut pas pousser car l'url du remote est celle en lecture seule. Il faut passer sur la branche de origin correspondante, fusionner, et pousser (ou alors modifier l'url push du remote "composer"). Sinon RAS.
    * changement dans la branche tracké via "origin"
-     * modif puis composer update/install. Résultat : ?
+     * modif puis composer update/install sans nouvelle version. Résultat : ?
-     * modif puis commiter puis  composer update/install. Résultat : ?
+     * modif puis commiter puis  composer update/install sans nouvelle version. Résultat : ?
-     * modif puis commiter puis pusher puis composer update/install. Résultat : ?
+     * modif puis commiter puis pusher puis composer update/install sans nouvelle version. Résultat : ?
+     * modif puis composer update/install avec nouvelle version dispo. Résultat : ?
+     * modif puis commiter puis  composer update/install avec nouvelle version dispo. Résultat : ?
+     * modif puis commiter puis pusher puis composer update/install avec nouvelle version dispo. Résultat : ?
    * passage à une version stable dans le composer.json, sans modification des sources du module. Résultat : ?
    * passage à une version stable dans le composer.json, avec modification des sources du module non commitées. Résultat : ?
    * passage d'une version stable à instable. Résultat : ?
+   * changement distant + composer update alors que l'on est sur origin master ou composer master. Résultat : mise à jour du remote composer mais pas du remote origin. Par contre mise à jour de la branche locale origin master mais pas la branche locale composer master.
+   * changement distant + changement local + composer update alors qu'on est sur le remote composer. Résultat : ?
+   * changement distant + changement local + composer update alors qu'on est sur le remote origin. Résultat : ?

fr/tutoriels/utiliser-composer.txt · Dernière modification : 2015/03/09 16:04 de laurent