grum a écrit:

j'avais bien relu les topics cités par P@t, mais je n'arrivais pas à comprendre comment ne prendre que les fichiers qui m'interessait. Je n'avais pas percuté qu'il était possible de dire sur quelles versions travailler.

J'ai fait la ligne de commande que tu as indiqué et effectivement, j'ai bien juste les fichiers qui m'intéressent sur ma copie locale de la branche 2.0.
Mais çà ne m'explique pas tout.

Les derniers commits sont les suivants :
2813 /trunk =>  grum
2812 /trunk => zOrglub
2811 /branche 2.0 => zOrglub
2810 /trunk => grum
2809 /branche 2.0 => rub
2808 /trunk => rub

Je suppose que mon merge n'a pas embarqué d'autres fichiers que les miens car la màj de la 2812 est identique à celle de la 2811.

Mais si il y avait eu un commit sur la trunk uniquement (une 2812 et 2811 différentes par exemples), au moment de faire le merge, je la récupère forcément ? et c'est donc à moi de faire un revert sur les fichiers qui n'avaient pas à être embarqués dans la 2.0 ?
En gros, si je comprends bien, chacun s'occupe de livrer à la fois sur la trunk et la sur la branche 2.0 (lorsque nécessaire) uniquement les fichiers qu'il a modifié, laissant la responsabilité du merge des autres fichiers 'embarqués' à celui qui les as modifié ?

et pourquoi partir de la 2809 ? vu qu'il y a une 2811 et une 2812, je ne pouvais pas tout simplement partir de la 2813 (dernier commit que j'ai fait sur la trunk) ?

z0rglub a bien résumé.

Dans mon exemple, je suis partie de la 2809, car c'est la version juste avant ton commit, j'ai appliqué un spectre plus large pour l'exemple.
Mais génalement, on fait le merge dans la foulée.

Dans l'exemple, les autres commits n'ont pas d'effet car déjà merger.

Et pourquoi partir de la 2809 car en partant de la 2813, c'est juste les yes qui sont passé en true, je pense que le merge aurait généré des conflits.

Je ne suis pas sûr d'avoir tout compris à vos tracas, mais voilà ma technique.

1. je fais ma modification sur la branche 2.0, je commite, ça créé la revision 2811 disons (au hasard)
2. je vais dans mon répertoire "trunk", je fais un update, puis:

svn merge -c2811 svn+ssh://plg@svn.gna.org/svn/phpwebgallery/branches/2.0
svn commit

Mon log de commit :

merge -c2811 from branch 2.0 to trunk

based on forum discussion, a comment is added to explain why c13y_upgrade 
plugin is activated at this precise moment.

Je dis que ce commit correspond à un merge, de quelle revision et de quelle branche vers quelle branche (VDigital ne le fait pas, c'est vrai qu'on peut retrouver ces infos, mais pour faciliter la lecture des logs de commits, je voudrais qu'on s'applique à procéder ainsi). Puis je copie/colle exactement le log de commit de la revision mergée. Toujours dans un soucis de facilité de lecture du log de commit.

Note pour rub : "merge -r2810:2811" est strictement équivalent à "merge -c2811", sauf que c'est plus lisible.

grum a écrit:

j'ai fait un nouveau commit sur la trunk, mais pour la branche 2.0 je bouine. je comprends pas comment çà fonctionne et comme j'ai un peu peur de faire des conneries, pour l'instant je fais pas. je regarderais çà demain à tête reposée...

Reprends les liens de P@t en ligne de commandes, il faut 30 secondes.
Et si tu fais une connerie, il est simple de se remettre dans l'état d'avant.

Tu as fait un commit 2810 et 2813, on va donc faire un merge de version 2809 à 2813.

En ligne de commande cmd, je lance

pushd branch-2_0
svn merge -r 2809:2813 svn+ssh://rub@svn.gna.org/svn/phpwebgallery/trunk
popd

(tu peux remplacer les pushd et popd par des cd et cd-)
et j'ai comme résultat:

U    include\menubar.inc.php
U    template\yoga\menubar_menu.tpl

Je vérifie les merges avec les outils de comparaison du commit.
Si pas de conflit (rare en ce moment car version presque identique, tu commites).

Moi, pas contre, je "revert"...

Je crois que j'ai finit par prendre l'habitude de gérer mes boolean en chaine de caractères (PHP => mauvaises habitudes) et généralement je positionne à 'y' ou 'n'. çà me simplifie beaucoup la tache pour beaucoup de choses en fait.

Mais là pas de soucis, je peux passer en booléen.

grum a écrit:

menubar_menu.tpl
{if isset($block->data.qsearch) and  $block->data.qsearch=="yes"}

et

menubar.inc.php(ligne 218)
$block->data['qsearch']='yes';

votre avis ?

pour quoi mettre 'yes' et pas directement true, false ?

j'ai commité sur la trunk.
je suppose qu'il faut que je le fasse aussi sur la branche 2.0.

la modif est assez simple pour que je la reporte "à la main", mais je pense que ce genre de chose doit pouvoir se faire par un merge ?

Les éléments des sections "spéciales" et "menu" sont stockés dans les données $block->data, à l'exception de l'élément "menu/recherche rapide".
Il est facile via un plugin de modifier le contenu de $block->data et donc de jouer sur les éléments de menu à ajouter/supprimer de ces sections. Excepté pour la recherche rapide. J'aimerais rajouter une condition sur l'affichage du bloc

menubar_menu.tpl
{if isset($block->data.qsearch) and  $block->data.qsearch=="yes"}

et

menubar.inc.php(ligne 218)
$block->data['qsearch']='yes';

votre avis ?

vimages a écrit:

Bonjour,
en cliquant sur le lien du plugin Advanced Menu Manager, la page s'ouvre mais s'y trouve ce message :

Code:

Fatal error: Call to a member function registered() on a non-object in D:\serveur\ACO_test1\plugins\AMenuManager\amm_aip.class.inc.php on line 958

merci.
éric.

oui c'est normal, il faut que je revois une bonne partie du code de ce plugin, les méthodes que j'avais initialement mises en place et la façon dont j'avais pensé le truc ont été revus entièrement, et le plugin n'est du coup plus du tout adapté. Faut que je prenne le temps de comprendre comment çà fonctionne maintenant (à base de triggers j'ai l'impression). Mais avant de creuser plus en avant, j'ai l'impression qu'avec la mise en place de la configuration du menu directement dans piwigo, ce plugin devient un peu inutile en fait.