[subversion] un projet php avec mysql

[Zamentur]

Bonjour à tous,
Donc j'utilise depuis déjà quelques temps subversion, ce logiciel est parfait, sauf que j'ai un léger manque vis à vis de la gestion des bases de donnée.

Le problème est que quand je fait un commit je désire envoyer aussi les éventuel modif de la bdd.
Et que quand on fait un update la dernière bdd soit automatiquement installé.

Ainsi j'avais trouvé une astuce qui était de lier symboliquement le répertoire wamp/lib/mysql/data/monprojet/ à un dossier de la copie de travail dans le trunk (la plus part du temps)

Ainsi mes donnée et structure de table faisait aussi partie du dépot et je n'avais pas à faire de mysqldump ou autre méthode pour réinstaller la bdd.

Seulement cette méthode ne fonctionne pas pour les tables InnoDb notamment à cause du fait que les données sont contenue dans un unique fichier pour toutes les tables et bdd à savoir ibdata1 dans /var/lib/mysql...

Le hic étant que comme les données sont mélangé je ne peux pas me permettre d'appliquer cette méthode car j'utilise plusieurs bdd sur différent projet!

D'où mon questionnement sur la façon dont vous procédez?

(et puis il faut le dire ma méthode est un peu bourrine et assez risqué surtout si un des développeur vient à utiliser une version de mysql trop différentes!)

Merci pour vos réactions!

[Mycroft]

D'où mon questionnement sur la façon dont vous procédez?

(et puis il faut le dire ma méthode est un peu bourrine et assez risqué surtout si un des développeur vient à utiliser une version de mysql trop différentes!)

Merci pour vos réactions!

J'ai pas tellement compris ta méthode et tes limitations (tu peux pas rajouter ibdata1 dans ton projet?) donc je peux pas te conseiller, mais je peux te dire ce que je fais.

J'utilise pas svn mais git, mais ça revient au même.

J'ai créé un "pre-commit hook" (c'est à dire une action qui est executé automatique avant chaque appel de la fonction commit) qui dump (par mysqldump) la base donnée et ajoute le fichier à mon commit.

De cette façon à chaque fois que je commite, je commite aussi une base de donnée alignée qui fonctionne avec mon code.

C'est un peu lourd mais ça permet de faire fonctionner n'importe quelle révision. Et je réfléchis pas si ma bdd est bien alignée avec mon code, c'est transparent.

Un mini-tuto pour svn:
http://wordaligned.org/articles/a-subver...ommit-hook

A l'inverse je sais pas si un "post-update hook" existe, qui te permettrait de regénérer la base.

Après rien ne t'empêche de créer un petit script perso qui fait:
1. svn update
2. chargement de ton fichier backup.db dans la database.

Pour l'instant j'ai jamais eu à revenir en arrière sur une révision, mais le jour où je devrais le faire, c'est clair que je devrais faire une intervention manuelle pour réaligner la bdd.

(Je viens de vérifier c'est possible de définir un "post-checkout hook" pour git, donc potentiellement je pourrais/devrais rajouter mysql -uUser -pPASSWORD database < backup.sql dedans )

[Zamentur]

ok donc toi tu penses que je devrais faire un dump avec un hook.
C'est effectivement ce qui serait le plus propre.

Mais par contre j'ai jamais fait de hook coté client (copie de travail) à chaque fois j'ai fait çà coté serveur, donc comme tu le fait remarqué faut que ce soit faisable avec svn, je vais essayer de chercher de ce coté.
NB: en fait j'ai plusieurs projets sous subversion dont 2 jeux, un des 2 c'est une équipe qui est derrière donc faut pas qu'ils aient à réinstaller la bdd à chaque fois.(moi je l'es héberge juste)

Sinon, sur mes projets solo c'est vrai que je fais rarement des retour en arrière

[Mycroft]

Je viens seulement de comprendre que les hooks svn sont côté serveur et pas client. Donc ma solution ne fonctionne pas pour toi. On en revient à faire un script particulier, un svnbis, qui dump la db et fait le commit.

A moins d'avoir le même serveur pour la DB et svn, et de faire le mysqldump côté serveur, mais ça me paraît pas super propre...et je suis pas sûr que tu puisses récupérer ce fichier dumper pour le mettre dans ton commit... Cette deuxième solution paraît être bien pourrie .

Je me demande comment les autres gens qui utilisent svn font...

Je suis perplexe.

Edit : Apparament tortoise-svn a prévu le coup, mais tout le monde utilise pas tortoise : http://tortoisesvn.tigris.org/tsvn_1.5_r...side-hooks

[Anthor]

Comment je fais ?
J'utilise SVN pour ce qu'il est fait.

A part la structure de la base le reste n'a rien a y foutre... J'ai un backup pour faire cela la nuit...

[Zamentur]

La structure de la base et des donnée de test/ de réglages? Enfin sinon à part un rôle de sauvegarde je ne voie pas l'intérêt!


Et puis pour moi subversion c'est le moyen pour développer en équipe à distance non?
Du moins çà marche très bien en dehors de ce petit manque au niveau de la bdd.

[Anthor]

La structure de la base n'est pas censé changé à chaque commit ^^

[Mycroft]

La structure de la base n'est pas censé changé à chaque commit ^^

Ca dépend de la méthode de développement : je préfère partir d'une base minimaliste ( tables Users / News / Characters par exemple) et ajouter des modules/fonctionnalités au fur et à mesure et les tables qui vont avec.

Donc dans la phase où je suis je change de structure de table relativement souvent (ajout de nouvelles tables et d'index essentiellement). Et c'est pratique d'avoir des points de restauration du code avec la table associée.

Même si sur le fond je suis d'accord c'est a priori pas fait pour ça, mais ça me paraît important de garder une table aligné avec le code. Et le plus simple c'est encore de tout garder sous la même révision.

[naholyr]

Une fois n'est pas coutume : oxman++.

En tous cas, j'insisterai surtout sur le fait que le code n'est pas censé être aligné avec des DONNEES mais avec une STRUCTURE de base de données. Quand (et seulement quand) tu changes la structure de la base (et donc forcément les données de base et/ou de test qui vont avec) tu vas mettre ça dans tes fichiers structure.sql et data.sql, qui va partir avec le commit...

Donc tu n'as pas à sauvegarder la base entière : ça grossit artificiellement ton dépot, et en plus tu perds toute possibilité d'analyser les différences de structure d'une révision à l'autre. Alors qu'avec une méthode basée sur un fichier SQL de structure versionné, tu peux en regardant son historique voir les modifications (SQL se marie très bien avec diff).


Et effectivement tu peux jeter un oeil aux migrations de Rails, et t'en inspirer pour mettre en place un système similaire.


P.S : si ta structure change presque à chaque commit, c'est que tu ne commit pas assez souvent. SVN n'a de réel intérêt que si l'historique est réellement exploitable pour faire des retours en arrière et autre merge, et ça n'est possible que si on fait des commits petits et nombreux.

[Mycroft]

Je conserve la structure ET les données. Ca me permet de rapidement repeupler ma base, plutôt que d'avoir à générer des exemples à chaque fois.

Je comprends votre point de vue, mais tant que je suis en phase de développement ça me gène pas de sauvegarder une base d'exemple.

C'est certain que la méthode de migration de Rails est plus intelligente, le seul inconvénient c'est qu'il faut apprendre ruby/rails.

Si je veux voir les différences entre deux versions, je peux me contenter de faire des diff entre mes schéma ou mes données. C'est moins lisible de lire directement du MySQL mais c'est suffisant pour ce que je fais.