Discussion :

[vallica]

Bonsoir à tous,

Voici ma problématique que beaucoup ont du déjà rencontré :

Disons que je bosse sur www.svnestmagique.com, sur mon serveur Linux, j'ai le repository mais aussi un var/www/svnestmagique.com qui fait régulierement des svn update de mon repository. C'est en fait un vhost de pré-prod.

Parallelement, les développeurs bossent sous windows et font des commit sur le serveur linux, qui sont ensuite visibles sur la pré-prod une fois le svn update lancé sur le serveur.

Le souci, c'est que lorsque l'on travail en local, on peut être amané à écrire ce genre de chose dans un fichier :

Path=D:\wamp\www\projet1\etc

et bien sur quand on commit, et que l'on fait un svn update sur la prépod, on doit repasser sur les fichiers pour changer le Path avec un chemin unix.

Ma question est donc, n'y aurait-il pas déjà quelque chose, une option de svn ou autre qui puisse gérer ce genre de problématique ?

J'avais pensé à une solution perso mais pas très pratique qui consisterait, pour un fichier donné à écrire ce genre de chose :

#[context:dev1]
Path=D:\path\du\dev1\en\local
#[context:preprod]
#Path=/var/www/toto

Donc le dev1 positionne sa variable Path, il indique le contexte sur la ligne le précedent, et donne également la valeur pour le context preprod mais il commente la directive.

Ensuite, il faut mettre en place un script bash ou php-cli qui recherche les lignes commencant par #[context:, puis qui soit commente la ligne suivante si le contexte est différent de prepod, soit la decommente si la valeur située après le : est preprod.

Qu'en pensez vous?

[djidane39]

le problème c'est que des fichiers de configuration personnel (spécifique à une machine) sont versionnés, ce qui ne devrai pas être le cas.
La solutions recommandées est de ne tout simplement pas versionner ce genre de fichiers!
Si ce genre de chemin se trouvent dans du code, il faut l'externaliser dans un fichier de conf, et ne pas le versionner...

[DranDane]

En effet. Voilà une des raisons pour lesquelles il faut éviter le hardcoding. C'est à dire ne pas coder directement ce genre de strings dans la source mais les placer dans des fichiers de configuration. Fichier de configuration qui ne sera effectivement pas versionné.

[vallica]

JE parle justement des fichiers conf, si dans un fichier conf tu as un path, tu va devoir le modifier sur tous tes contextes.

A moins de passer par un script bash et des sed, mais justement je voulais savoir si svn proposait quelque chose dans ce sens.

[DranDane]

Non SVN ne propose rien. Une solution c'est de ne pas versionner tes fichiers config ou de versionner tout tes fichiers config en les renomants en fonction de l'environnement. Mais c'est la débrouillardise pour ce genre de choses avec SVN (et tout autre versioning systems aussi je pense).

[vallica]

Apparement une solution serait la suivante :

pour le fichier /conf/setup.ini, lui créer un /conf/setup.ini-DIST.

dans setup.ini-DIST qui est une copie de setup.ini, on remplace les variables par des tags, donc aurait path=%PATH_FOR_NOTHING%

Ensuite, on se fait un fichier de mapping par environnement, qui contient des trucs du style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

%PATH_FOR_NOTHING%=/srv/toto/tata

et pour finir, on a un script shell à qui on dit d'aller chercher les -dist, de remplacer les variables à partir de ce que contient le fichier de mapping, et de remplacer le setup.ini par le setup.in-dist renommé bien sur.

Le truc c'est que je n'ai pas encore trouvé de script déjà tout fait, ou au moins une base de départ... ca doit être un script basé sur des grep, des find et des sed surement !

[Estats]

pour le fichier /conf/setup.ini, lui créer un /conf/setup.ini-DIST.

Salut,
tu peux faire simplement comme tu dis:
* 1 fichier de conf pour l'environnement dist setup.ini-DIST
* 1 fichier de conf pour l'environnement de dev SETUP.INI (en majuscules)
Ces 2 fichiers sont versionnés.
Sous windows, normalement insensible à la casse, le fichier SETUP.INI va être pris en considération, et sur ton serveur linux, tu peux faire un lien symbolique setup.ini qui pointe sur SETUP.INI_DIST (ln -s SETUP.INI setup.ini).
Ton environnement de dev va utiliser setup.ini qui est en fait SETUP.INI_DIST.
Sous linux setup.ini et SETUP.INI peuvent cohabiter l'un à côté de l'autre sans ambiguïté

a+

[vallica]

Merci, c'est effectivement une solution pour un environnement à un seul serveur Linux.

Par contre si tu as une machine de preprod (linux), une de recettage, une de dev, etc. ca ne suffit plus...