🌍
Français
LucMorizur a écrit:
Gotcha a écrit:
Tu n'es pas convaincu ?
Si si, vraiment ^^ !
Non, je pense que ta réponse est juste : si on va fouiller là, on sait faire la différence entre le "trunk" et le reste.
:-)
Tout simplement :-)
Ou alors on y va grâce à un lien directe.
Bref, ce n'est pas tous les jours que l'on a affaire à ce genre de situations ;-)
Gotcha a écrit:
Tu n'es pas convaincu ?
Si si, vraiment ^^ !
Non, je pense que ta réponse est juste : si on va fouiller là, on sait faire la différence entre le "trunk" et le reste.
:-)
Tu n'es pas convaincu ?
Gotcha a écrit:
Dis-toi que si on va récupérer un fichier sur SVN, c'est que c'est pour une bonne cause car le chemin est parsemé d'embuches ^_^
Soit on va avec un lien directe, soit on navigue.
Et si on navigue, on a dès le début un choix à faire entre une branche ou trunk :-)
La question ne se pose plus dans ce cas.
Mmm'bon... OK...
Dis-toi que si on va récupérer un fichier sur SVN, c'est que c'est pour une bonne cause car le chemin est parsemé d'embuches ^_^
Soit on va avec un lien directe, soit on navigue.
Et si on navigue, on a dès le début un choix à faire entre une branche ou trunk :-)
La question ne se pose plus dans ce cas.
Merci Gotcha pour ces explications :-) .
Gotcha a écrit:
(...) Comme expliqué plus haut, une merge n'est pas obligatoire. (...)
C'est justement ce dont je voulais parler :
Gotcha a écrit:
Du coup, pour s'assurer d'avoir la dernière version en date des fichiers, il faut regarder la barre d'adresse (URL) de son navigateur et supprimer le dernier point d'interrogation et tout ce qui suit.
(...)
Maintenant que tu vois ton fichier dans sa dernière version
Or, si une correction a été faite en "branch", mais pas suivie d'un "merge", le fichier trouvé selon la méthode ci-dessus ne possédera pas la correction.
Mais bon, cette prise de tête est peut-être prématurée, si cette partie du wiki n'est pas encore sur les rails.
:-)
Avant de répondre véritablement à ta question, ce que je sais c'est qu'il y a une distinction à faire entre "branche" et "trunk"
Une branche est l'équivalent d'une future release mineure.
Exemple : 2.0.7 2.0.8 2.0.9 2.0.10 etc.
Il n'y a donc pas de gros changement et surtout pas de modification dans la BDD.
Trunk par contre c'est pour voir plus loin, c'est à dire une release majeur.
Exemple : 2.0.0 2.1 etc.
Là les modifications sont plus importante.
Les deux divisions sont donc différente et les informations dans l'une ne sont pas obligatoirement reportées dans l'autre. Du moins, pour ce qui est des fonctionnalités nouvelles ou pour les modifications dans la BDD, on ne verra rien de tel dans une branche.
Bref, ce petit cours fait, passons à ta question.
LucMorizur a écrit:
Cela n'est-il pas vrai que s'il y a eu un "merge" de la correction d'un fichier dans le "trunk" ?
"Merger" signifie que l'on porte les même changements d'un coté à un autre coté. Il y a un système automatique dont se servent les grands manitous mais généralement on le fait à la main. C'est à dire que l'on reporte nos modification de trunk => branche ou l'inverse.
Comme expliqué plus haut, une merge n'est pas obligatoire.
Tu dois confondre avec une révision or là, peut importe où tu te trouve, du temps que tu modifies quelque chose et que tu "commit" (envois), SVN créer comme un point de repère et conserve l'historique de tes changements. Cet historique est une "révision".
A présent, si un fichier n'a reçu aucune révision, et bien... et bien il n'en a pas lol
Je ne vois pas où peut être le problème puisque qu'il est possible de récupérer le fichier dans son état le plus avancé. Si l'état n'a pas changé, tu récupérera le fichier comme à l'origine.
Pour bien comprendre, voici l'adresse pour observer tout ça par toi même :
http://piwigo.org/dev/browser
Tu trouveras donc les branches, trunk et plus encore.
:-)
Bonjour ;
pour faire suite à post:144903 :
Gotcha a écrit:
LucMorizur a écrit:
Belle explication !
A retenir !Je comptais bien m'en resservir pour plus tard ^^
Je poste donc une réponse ici car je subodore la création d'article(s) dans le wiki, sur la façon de récupérer les dernières corrections, pas encore disponibles par une release, ce qui est à mon avis très utile.
La question que j'avais à ce sujet, c'est : lorsque tu écris Gotcha, dans post:144893 :
Du coup, pour s'assurer d'avoir la dernière version en date des fichiers, il faut regarder la barre d'adresse (URL) de son navigateur et supprimer le dernier point d'interrogation et tout ce qui suit.
(...)
Maintenant que tu vois ton fichier dans sa dernière version, il ne te reste plus qu'à récupérer l'intégralité du contenu.
Cela n'est-il pas vrai que s'il y a eu un "merge" de la correction d'un fichier dans le "trunk" ?
Et sinon par ailleurs :
Gotcha a écrit:
Il faut que je trouve un moment pour refaire le point sur les différents outils dont se sert le projet Piwigo...
+1
Je te répondrai mais pas ici car en effet, ca nous fait dévier du sujet.
:-)
Gotcha a écrit:
Oui mais tu vois, c'est encore plus pratique de voir directement que la page que l'on visite dispose d'un flux. On évite ainsi de trop chercher dans le contenu de la page pour trouver un éventuelle flux ^^
Totalement HS, mais je vais te répondre quand même :
- je ne connaissais même pas cette possibilité de Firefox avant que tu ne me la signales, et ça ne m'a jamais empêchée de souscrire à un certain nombre de flux sur pas mal de sites différents
- qu'en est-il des autres navigateurs ? parce que la majorité des visiteurs n'utilise pas (encore) Firefox ...
- en tant que créateur/développeur, j'ai conçu et réalisé mon interface graphique ; elle me plaît telle qu'elle est, et j'ai reçu d'assez bons retours sur l'ergonomie du site => je n'ai pas l'intention d'y changer quoi que ce soit, comme ça, à la marge, sans peser le pour et le contre, et envisager toutes les conséquences sur l'ensemble de la navigation dans le site.
Je n'ai d'ailleurs pas bien saisi ce que mathiasm entendait par en-tête : s'agit-il du header au sens HTML ? ou de la partie "bannière" de la page affichée ?
tosca a écrit:
mathiasm a écrit:
tosca a écrit:
EDIT : un autre exemple : http://www.cevennes-plurielles.com/les- … ulter.html dans celui-là, je n'ai rien dans la barre d'adresse de Firefox, alors qu'il y a bien un flux d'abonnement dans la page !
Pour ta page HTML, il faut déclarer le flux RSS dans l'en-tête de la page.
Pourquoi donc ? Simplement pour avoir l'icône dans la barre d'adresse ?
Ca n'empêche pas de souscrire au flux ...
Oui mais tu vois, c'est encore plus pratique de voir directement que la page que l'on visite dispose d'un flux. On évite ainsi de trop chercher dans le contenu de la page pour trouver un éventuelle flux ^^
mathiasm a écrit:
tosca a écrit:
EDIT : un autre exemple : http://www.cevennes-plurielles.com/les- … ulter.html dans celui-là, je n'ai rien dans la barre d'adresse de Firefox, alors qu'il y a bien un flux d'abonnement dans la page !
Pour ta page HTML, il faut déclarer le flux RSS dans l'en-tête de la page.
Pourquoi donc ? Simplement pour avoir l'icône dans la barre d'adresse ?
Ca n'empêche pas de souscrire au flux ...
tosca a écrit:
EDIT : un autre exemple : http://www.cevennes-plurielles.com/les- … ulter.html dans celui-là, je n'ai rien dans la barre d'adresse de Firefox, alors qu'il y a bien un flux d'abonnement dans la page !
Pour ta page HTML, il faut déclarer le flux RSS dans l'en-tête de la page.
Gotcha a écrit:
Merci Tosca.
Le "hic" c'est de trouver dans quel fichier CSS se trouve cette instruction, car je ne sais pas si tu as vu, mais dokuwiki fait comment si il n'existait qu'une seule feuille de style.
Je dirais
fichier design.css
ligne 692
div.dokuwiki table.diff td {
font-family: monospace;
font-size: 100%;
}
Gotcha a écrit:
Un peu HS mais ça peut te servir : avec Firefox il existe une extension qui permet de modifier une page internet selon TES propres réglages.
L'objectif n'est pas d'améliorer pour moi seulement, mais pour tous les utilisateurs susceptibles d'être intéressés.