Ubuntu-fr

Lapinbleu

SVN + TRAC + Apache -> Accessibilité en serveur de dév

Bonjour,

J'ai installé Subversion, Trac et Apache sur un serveur de développement. Trac fonctionne nickel et je peux naviguer dans les sources de fichiers, que ce soit via Trac ou via Eclipse.

L'url du dépôt est du type: http://svn.foo.bar

Or, j'aimerais pouvoir accéder aux fichiers à proprement parler afin de tester leur comportement via une url du type http://foo.bar
(par exemple, qu'Apache interprête index.php en tant que fichier scripté et non comme un fichier texte comme le fait Trac)

Je ne sais pas trop si celà est possible facilement, vu que Subversion stocke ses infos dans une BDD.

D'avance, merci et bonne journée.

JoelS

Re : SVN + TRAC + Apache -> Accessibilité en serveur de dév

Je ne sais pas trop si celà est possible facilement, vu que Subversion stocke ses infos dans une BDD.

Non c'est pas possible. Enfin c'est peut être possible, mais si ça l'est, c'est une mauvaise idée. Il vaut mieux que tu fasses un svn checkout + svn update du repository dans un répertoire géré par Apache.

Tu peut même automatiser les updates via les mécanismes de notification de Subversion.

Tu peut aussi aller plus loin en utilisant les branches + svnmerge + svn::notify par exemple, de façon automatisée ou semi-automatisée.

Lapinbleu

Re : SVN + TRAC + Apache -> Accessibilité en serveur de dév

Merci beaucoup...

Ca fonctionne manuellement... il va falloir que je trouve une façon d'automatiser ca... (sans oublier que je ne suis pas directement sur le serveur de dév apache)

Encore merci.

teke

Re : SVN + TRAC + Apache -> Accessibilité en serveur de dév

J'aimerai faire la même chose... je vais m'y pencher d'ici à un mois.

Je me souviens avoir lu (mais je ne sais plus où) qu'il est possible de faire un hook qui exporte automatiquement (ce qui est mieux qu'un co à mon avis) dans un dossier accessible à apache (ou sur sur une machine distante) dès qu'un ci est fait dans une branche spécifique.

J'ai à peine regardé de loin la chose, mais il me semble que le script de contrôle pour ne pas faire de ci dans les tags est une bonne voie de recherche...

JoelS

Re : SVN + TRAC + Apache -> Accessibilité en serveur de dév

Je me souviens avoir lu (mais je ne sais plus où) qu'il est possible de faire un hook qui exporte automatiquement (ce qui est mieux qu'un co à mon avis) dans un dossier accessible à apache (ou sur sur une machine distante) dès qu'un ci est fait dans une branche spécifique.

Oui, tu peux exécuter des scripts hook quand certaines opérations de SVN s'effectue. Par exemple tu as le POST-COMMIT-HOOK qui est exécuté après qu'un commit ait réussi dans n'importe quelle branche de ton projet. Regardes le livre en ligne sur Subversion, peut-être en anglais mais très bien fait et très pédagogue.

Par contre, je ne suis pas tout à fait d'accord avec ton a-priori que l'export est meilleur que le checkout + update. C'est vraiment très différent. Par exemple, dans l'export, tu n'as pas de Working Copy locale, et donc tu perds le rattachement de ce que tu as exporté à une release de ton projet. Si tu veut mettre à jour, ça devient vite problèmatique.

Pour les applis Web, il est facile de faire des update directement dans la zone HTML de ton serveur, et de configurer celui-ci pour ignorer les répertoires de travail .svn. Tu peut aussi faire des update dans une zone de transit et ne recopier via un script vers ton répertoire HTML que ce qui t'intéresses, éventuellement en modifiant au passage des droits ou autre chose, tout ça pouvant être lancé par le script de hook.

L'export est vraiment fait pour exporter. SVN va oublier tout de ce qu'il a exporté et c'est pas toujours (souvent ?) souhaitable.

teke

Re : SVN + TRAC + Apache -> Accessibilité en serveur de dév

Disons que je susi passé à l'export seul pour les sites en production pour deux raisons principales : 1) la place (les dossiers .svn peuvent enfler, ce qui peut être génant sur un serveur de production ou l'espace disque est souvent limité) ; 2) la simplicité (sécurité), car il faudrait alors rendre les dossiers .svn (via la conf d'apache ou .htaccess) inaccessible pour le public, mais il faut aussi ensuite gérer les conflits qu'il peut y avoir entre la version sur le serveur et celle du répertoire de travail habituel. De plus il va falloir signaler manuellement tout les fichiers auto-généré (ex. les fichiers de cache) afin qu'ils ne soient pas pris en compte par svn.

Maintenant s'il n'y a pas de contrainte de place et que l'on a l'habitude de travailler directement sur la version de production...

Cela dit... subversion permet tellement de chose qu'il est possible d'imaginer beaucoup de manière de travailler ! C'est entre autre ce qui m'a attiré dans cet outil.

Dernière modification par teke (Le 28/04/2007, à 09:05)