[Corrigé] Plus d'OpenLayers dans le git ?

[yip]

ol2.12.12dc/openLayers.js n'existe plus dans le git.
Je sais pas comment j'ai fait.
Pour etre bien sur de ne pas ne pas transmettre mes triffouillages d'OL à l'arbre, j'ai fait un git checkout ol2.12../OpenLayers.js
en esperant que ca reprenne bien la version d'origine, et là, apparemment, plus d'OL dans le Git !
le git checkout a modifié le Master ! je pensais qu'il faisait exactement l'inverse.

On fait comment ? un git add ?

[Dominique]

Zut, c'est moi. J'ai pris le pli de faire des modfis sans en avertir les autres !

Comme le GIT CLONE donne des droits insuffisants aux fichiers générés (ol2.12.dc/Openlayers.js en faisant partie), j'ai choisi de ne pas les inclure
Pour générer la lib, il faut aller dans gestion / Compression de la librairie OpenLayers
Ceci dit, ça ne règle pas le problème car les répertoires ol2.12.dc et ol2.12.dc/build n'ont pas non plus, nativement, les droits ! (les mettre à 777)
Pb de GIT à investiguer

Autre pb, moins grave: l'encodage des fichiers n'est pas transmis par GIT

[sly]

le git checkout a modifié le Master ! je pensais qu'il faisait exactement l'inverse.

Je peux me tromper, mais il me semble que la commande checkout ne sert que pour passer d'une branche à l'autre, pas pour désigner un commit sur un seul fichier ou dossier.

Si ton but était de transmettre, sur github, tes changements uniquement sur une zone restreinte et ben..... je sais pas faire !

Mais ça m'intéresse si quelqu'un trouve ;-)

[sly]

Ceci dit, ça ne règle pas le problème car les répertoires ol2.12.dc et ol2.12.dc/build n'ont pas non plus, nativement, les droits ! (les mettre à 777)
Pb de GIT à investiguer

Il n'y a pas l'air d'avoir de solutions simples :
http://stackoverflow.com/questions/3207 ... s-with-git

Autre pb, moins grave: l'encodage des fichiers n'est pas transmis par GIT

C'est pas son boulot, lui, il compare des fichiers entre eux, et il en fait des diffs, et il se fiche de savoir comment c'est encodé. Si problème d'encodage il y a, c'est que l'un d'entre nous à ouvert le fichier encodé en UTF-8 et l'a sauvegardé dans un autre format.

At the core level, git is character encoding agnostic.

The pathnames recorded in the index and in the tree objects are treated as uninterpreted sequences of non-NUL bytes. What readdir(2) returns are what are recorded and compared with the data git keeps track of, which in turn are expected to be what lstat(2) and creat(2) accepts. There is no such thing as pathname encoding translation.

[Dominique]

C'est pas son boulot, lui, il compare des fichiers entre eux, et il en fait des diffs, et il se fiche de savoir comment c'est encodé. Si problème d'encodage il y a, c'est que l'un d'entre nous à ouvert le fichier encodé en UTF-8 et l'a sauvegardé dans un autre format.

C'est juste. Il s'agit de 2 fichiers que j'ai récemment passés en UTF-8 et remontés en commit
Les autres sont bien en UTF-8.
D'ailleurs, quand on se sert dans le GitHub Openlayers, on a bien les fichiers langues en UTF-8
Donc le pb, c'est qu'on ne peut pas changer par versionning l'encodage d'un fichier (à moins de le supprimer / rétablir)

Reste le pb des permissions 755 et du owner qui n'est pas le même quand on fait un GIT PULL en SSH et quand c'est apache qui fait un write

D'ailleurs, ça rejoint une demande de ma part (allergie aux incantations et flemme du clavier):
Serait il possible d'avoir (dans la partie gestion) un lien ou icône à cliquer pour lancer le GIT PULL sur le serveur courant ?
Si c'est le process apache qui lance tout, les pb de owner & permissions sont réglés

[sly]

:calimero: :calimero: :calimero: Zut, c'est moi. J'ai pris le pli de faire des modfis sans en avertir les autres ! :oops:

Comme je ne compte pas bidouiller du OpenLayers dans l'immédiat, pour faire marcher ma version j'ai fais ça :

Code : Tout sélectionner

cd www.refuges.info
cp /home/sites/refuges/www.refuges.info/ol2.12.dc/OpenLayers.js ol2.12.dc/

Toutefois, cette technique ne mettra pas ma lib OL à jour si quelqu'un la change.

Ce qui pourrait reposer la question : est-ce qu'on a bien choisi la bonne solution d'avoir une lib "custom" plutôt que la "officielle" sur laquelle les objets sont tellement bien qu'ils font des extends à tout va et donc on a pas besoin de toucher au coeur OL pour rajouter le GML+SLD custom, ainsi le code spécifique wri est dans les dossiers classiques genre /include et la lib OL on y touche pas, elle est dans /ol-officielle

ps:évidement, je fais un peu de provoc, donc avoir la lib dans github me va aussi bien, charge à celui qui la "recompile" de pusher aussi la version compilé pour que les autres en profitent

[Dominique]

Ce qui pourrait reposer la question : est-ce qu'on a bien choisi la bonne solution d'avoir une lib "custom" plutôt que la "officielle" sur laquelle les objets sont tellement bien qu'ils font des extends à tout va et donc on a pas besoin de toucher au coeur OL pour rajouter le GML+SLD custom, ainsi le code spécifique wri est dans les dossiers classiques genre /include et la lib OL on y touche pas, elle est dans /ol-officielle

ps:évidement, je fais un peu de provoc, donc avoir la lib dans github me va aussi bien, charge à celui qui la "recompile" de pusher aussi la version compilé pour que les autres en profitent

C'est une bonne question: la bonne pratique serait d'avoir une surcouche constituée de classes dérivées des classes "officielles"
Par contre, ma lib actuelle est optimisée à 500k alors que l'officielle fait 900k (environ, il faut que je vérifie) et la surcouche ferait aussi plusierus centaines de K
J'ai donc - peut être - trop optimisé la performance (je ne vois pas l'utilité de charger toutes les classes OL chez tous les internautes si on n'en utilise que la moitié)

Donc: on fait performant ou informatiquement correct ?

***EDIT***
ça ne résout pas le pb de la compression de la lib: je dois avoir ~20 classes spécifiques. Je ne vais pas charger 20 .js

En fait, il est plus logique de générer la lib sur le serveur de test et de remonter le tout
(que le fichier soit modifié par un éditeur ou par un compresseur ne change pas le fait que c'est une production de fichier)
D'ailleurs, la lib officielle contient son propre générateur ... et la lib générée
Je vais donc faire amende honorable et remettre la lib dans le GIT

[sly]

Reste le pb des permissions 755 et du owner qui n'est pas le même quand on fait un GIT PULL en SSH et quand c'est apache qui fait un write

Selon le point de vue duquel on se place c'est un problème ou un avantage.

Avant que wri dispose de sa propre VM c'était fait comme ça : "le user qui lance les php est le même que celui qui fait du ftp/ssh" c'était une quasi nécessité en environnement mutualisé, sans quoi, par un php habile, on pouvait lire les dossiers de mes autres clients.

En VM dédiée, ce problème n'est plus, et je suis revenu au mécanisme : c'est un user différent du ftp qui lance les php (en l'occurrence, le user apache www-data), cette démarche apporte avantages et inconvénients :
- inconvénients : il faut gérer les droits pour donner à l'utilisateur www-data l'accès au dossier photos, mode d'emploi, photos forum, avatars forum et lib openlayers compilée par apache

Mais il y a des avantages :
- La performance d'execution php est bien meilleure dans ce mode
- la sécurité est renforcée : wri permet l'envoi de fichier (les photos) et l'écriture de fichiers (mode d'emploi) si un bug permettait à un pirate d'envoyer des codes php, ou d'écrire dans un fichier php existant, c'est le loup dans la bergerie, on aurait un gros problème. Avec ce mécanisme, le user apache www-data n'a pas les droits suffisants pour le faire, un bug dans notre code n'a alors que peu de chance de dégénérer, sauf si on permet d'uploader un fichier avec extension php et de l'executer dans le dossier en question, ce qui peut plus facilement se contrer.

D'ailleurs, ça rejoint une demande de ma part (allergie aux incantations et flemme du clavier):
Serait il possible d'avoir (dans la partie gestion) un lien ou icône à cliquer pour lancer le GIT PULL sur le serveur courant ?

Je préfère le faire pour toi, sur demande, que de coder un truc pareil. On va quand même pas coder un client git en php ?
La fonction d'après sera : gérer un conflit car yip à changé un fichier local, revenir quelques commit avant car un truc ne marche pas

[sly]

Donc: on fait performant ou informatiquement correct ?

Entre les deux ? ;-)

[Dominique]

Reprenons au début:
OL est livré sous forme "officielle" V2.12
Plus nombre de patchs dispos sur le trac
Quand on veut utiliser ces patchs, il faut:
- charger la livraison sur GitHub
- charger les patchs choisis
- régénérer la lib
- s'en servir

J'ai aussi (vu la licence) toute latitude pour générer moi même des patchs (en les remontant ou pas dans le trac OL)

Donc ma méthode actuelle est bien orthodoxe
Seulement, il faut que je livre la lib générée avec

[Dominique]

J'ai complètement relivré OL, avec les bons caractères et encodages