ya qu'un fichier en JS, le XML de config, et un peu de doc.
ca vaut pas le coup de faire une branche. je mettrai ca dans un recoin de ressources/GIS/ pour archives, tout dans un petit tgz.
J'ai passé 2h a essayer de comprendre les branchages de GIT, rien compris.
laisse tomber, coupe la branche qui ne sera pas développée de toute façon.
c'est pas interessant de garder une branche abandonnée. on fait pas un fork ...
[réflexion] Diffusion par WFS/gml de nos points
-
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
J'ai vu, mais y'a aussi le ol 3.0 d'installé, le tinyows "qui va bien" et ça me permet de passer de l'une à l'autre très facilement sans que des changements plus récents m'obligent à changer plusieurs trucs.yip a écrit :ya qu'un fichier en JS, le XML de config, et un peu de doc.
En fait, je me suis déjà occupé, la branche existe et s'appelle "yip-tinows" et contient tout le nécessaire pour fonctionner.ca vaut pas le coup de faire une branche. je mettrai ca dans un recoin de ressources/GIS/ pour archives, tout dans un petit tgz.
github dispose d'ailleurs d'un graph pour faire du bling bling qui représente ça : https://github.com/sletuffe/www.refuges.info/network
(on clique dessus et on bouge vers la droite et ça indique les 3 branches existantes
1) avant tous les changements (pour au cas où récupérer des trucs nettoyés)
2) la branche yip-tinows qui fonctionne
3) la version "master" la dernière en date et la plus avancée.
En fait, une fois qu'on a repéré les 2 commandes utiles c'est vachement pratique pour passer très simplement de l'une à l'autre et laisser le "plan de travail actuel" bien propre et sans trucs qui ne servent plus et sans avoir à se demander si le nav3.php va ici ou là, que les vues correspondent, etc.J'ai passé 2h a essayer de comprendre les branchages de GIT, rien compris.
laisse tomber, coupe la branche qui ne sera pas développée de toute façon.
c'est pas interessant de garder une branche abandonnée. on fait pas un fork ...
Pour infos (à condition d'être à jour après un "git pull")
Avec :
git branch ça répond ça :
avant-pdo
* master
yip-tinyows
On voit laquelle est active et celle disponible
git checkout yip-tinyows
et tout le plan de travaille (dossier www.refuges.info) adopte l'état tel qu'il était au moment ou nav3/tinyows/ol 3 marchait, on peut même le faire évoluer sans perturber la branche "master"
et si on veut revenir à master :
git checkout master
et hop, tout le plan de travail revient à la version de prod
Évidement, tout le monde peut faire ça, et moyennant quelques commandes sioux on peut même faire passer des fichiers entre les branches si besoin.
Bref, moi, ça me va et si vous ne voulez pas vous en soucier restez comme vous êtes, restez juste dans la branche "master" (par défaut) et tout se passe comme si vous n'en utilisiez qu'une