Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Pages: 1
Bonjour,
je me suis développé un projet zend, A, qui est un back office ( des modules d'administration de site) que je compte utiliser par la suite pour mes projets.
Donc pour commencer un nouveau projet, je compte dupliquer le projet A, et y ajouter d'autres sources par la suite.
J'aimerais que si par exemple j'ai trouvé un bug dans un projet enfant qui sois sur un fichier du module d'administration A, que je sois obligé d'aller ouvrir le projet A pour faire des modifs et donc par la suite que les modifs se propagent dans tous les projets enfants.
Et de la meme facon si jamais on essaye de modifier des fichiers qui proviennent du projet A, ben qu'on ne puisse pas. Pour éviter d'avoir pleins de versions différentes de fichiers partout.
Donc je me demande comment faire pour pouvoir gérer ca ?
A noter que j'utilise Zend Studio (Eclipse).
++
Hors ligne
Je dirais : gestionnaire de version tel que svn, git, ... avec les mécanisme de branches.
par ailleurs si tu as des fichiers qui ne bouge pas dans des dossier particulier rien n'empêche de faire des liens relatif sur ton serveur (si tout est sur le même serveur).
Hors ligne
Le mécanisme de branches ???
Hum je vais me renseigner.
Ta solution de liens relatifs m'interresse moins. il s'agit surtout d'une solution de développement que je recherche pas une solution de mise en production.
++
Hors ligne
alors la solution du gestionnaire de versions et son mécanisme de branches est intéressant
Hors ligne
en fait avant j'utilisais SVN. Enfin il tournais sur un serveur distant www.unfuddle.com. Mais en fait j'avais tout le temps problèmes de corruptions de données. N'empeche ca me fais flipper de base mon developpement sur un mécanisme qui certaines fois plantais parce que j'avais supprimé un fichier, etc. ou pour une raison inconnue.
J'utilisais SVN avec Zend Studio.
Si jamais ca plante le systeme avec les branches je perds tou le mécanisme et toute la logique !
Un peu effrayant quand même
Hors ligne
Hum... avec SVN ça arrive d'avoir des problèmes avec sa copie locale quand on fait des bidouilles dedans (déplacer des répertoires à la main, suppression de .svn ou copie de codes qui viennent d'une autre copie locale, utilisation de plusieurs clients SVN de versions différentes...).
Donc là ça peut être assez galère, mais en général tu peux t'en sortir (au moins en virant le répertoire à problème et en le récupérant depuis le repository avec un svn update...).
Par contre je n'ai jamais eu de corruption du repository. A ce niveau, SVN est d'une fiabilité absolument remarquable. Pourtant j'ai des branches, des hooks, des droits d'accès, j'utilise à peu près tout dans SVN et j'ai environ 6000 révisions dans mon svn...
A+, Philippe
Hors ligne
perso les lib les modules réutilisables sont des projets à part entière et indépendants.
un projet d'appli commence par inclure les projet de lib et des modules nécessaires.
ainsi une modif sur les projet de lib ou de modules descends dans les projet d'applis.
un correctif dans une lib lors du dev d'une appli remonte à son projet.
si le dev de l'appli n'est pas membre du projet de lib il remonte un diff (patch) à un développer du projet et ça redescends ensuite pour tous.
généralement lorsque une versions est stabilisée dans une lib ou un module on créé une branche. c'est celle-ci qui sera incluse dans les projet d'appli. mais elle reste lié à un SVN ce n'est pas un export pour permettre de remonter des anno et des correctifs.
le gestionnaire du projet de lib se charge alors de reporter si besoin les correctifs (mineurs des versions stables) dans le trunk.
le anno majeure sont traitées dans le truck pas d'évol des versions stable (pas de modif du pourtour fonctionnel ni des API)
A+JYT
Hors ligne
Pages: 1