Zend FR

Ca doit étre lent qaudn meme non ? De plus FTP de ce que j'ai lu ssh est plus sécurisé.
Il n'a pas un logiciel qui enverrait seulement les fichiers qui ont été modifié ?

De manière génerale je voulais savoir, comment faire pour maintenir un site à long terme. Par exemple je rajoute des fonctions ou autres modules, je serai amener à modfier certains fichiers et donc ca en deviendra difficile de savoir quel fichier j'ai modifié.

Sinon un server SVN conviendrai ou pas ? Je suis seul à coder donc je me pose la question de son utilité, avantages et inconveniants.

Merci ++

TiTerm ->
Je crois qu'il n'est plus maintenu ce plug in, je l'ai essayé mai sj'ai rien compris.

Sinon j'ai trouvé ca, je suis en train de le tester. Je vais m'en contenté.:
http://www.eclipse.org/dsdp/tm/

Merci ++

Le plugin sert juste à envoyé mes fichiers, il n'est pas encore au stade de SVN, mai sje suis pose que plus tard il va tendre sur le meme principe que SVN. Pour l'instant j'envoi mes fichiers comme un simple client FTP, avec une connexion SSH, donc sécurisé normalement.

Je ne travail pas directement sur le server de production, donc ca reste correcte ca non ?
Merci ++

Dernière modification par alien7 (24-09-2007 21:04:17)

TiTerm a écrit:

Nous travaillons essentiellement en local, mais lors du commit via subversion, j'ai mis en place un hook post commit qui fait automatiquement un checkout (un update en fait)  des sources sur le serveur de dev distant. De cette façon, on a toujours une version du serveur distant a jours. Mais cette méthode ne permettrai pas de travailler réellement sur le serveur distant.

Bonjour,

J'ai mis en place mon svn, je me connecte à distance et fais mes commits, mais pour mettre à jour mes pages sur mon serveur web, je passe encore par un export + transfert ftp..

Si j'ai bien suivi ton hook post commit automatise la tâche export + transfert ou tout au moins évite de la faire ? Pourrais-tu m'expliquer comment ça marche ?

Merci d'avance

Charly

Bon c'est un problème de permissions en fait. Je fais un commit avec un user charly qui n'a pas les droits d'executer le post-commit, alors qu'en root ça passe.

Il faut que je change les droits sur charly.

Merci pour cette réponse très complète comme d'habitude dans tous tes posts !

Charly

Ca a l'air pas mal aussi.
Mais du coup ya 2 opérations à faire, le commit + la synchro (filtrée sur les .svn ?) ou tu fais tout en une seule fois ?

Dernière modification par charlysquare (13-11-2007 11:11:08)

1/ Tu fais un checkout du trunk ou de la branch qui t'interesse dans ton /var/www.

2/ Dans la partie serveur svn, tu as un répertoire hook, dedans, il y a un template pour le post-commit.
Tu te base sur le template et tu créé un script de post-commit qui sera automatiquement executé par le serveur svn après chaque commit. Dans ce script, tu fais simplement un  "svn update /var/www"
Ton rep /var/www sera automatiquement mis a jour avec la derniere version de la branche/trunk que tu as initialement  "checkouter".

Je viens de tester ça avec Eclipse et le plugin subclipse pour me "brancher" sur le svn du zf. Voilà ce que j'ai fais:

Le checkout, c'est (quand tu traduis) une vérification. Si c'est la première fois, tous les fichiers vont être récupérer. C'est donc de ton PC que tu lance cette manip, mais c'est en fait une requête au serveur svn.
Le Trunk s'ajoute donc lorsque tu a récupérer les fichiers (sous Eclipse, ça m'a créer un nouveau projet tout simplement).
A chaque fois que tu feras un checkout par la suite, ça verifira quels fichiers ont été modifiés et les mettra à jour.

Après pour l'histoire des commits je peux pas encore t'aider, je suis pas encore contributeur au zf

Mr.MoOx a écrit:

Je viens de tester ça avec Eclipse et le plugin subclipse pour me "brancher" sur le svn du zf. Voilà ce que j'ai fais:

Le checkout, c'est (quand tu traduis) une vérification. Si c'est la première fois, tous les fichiers vont être récupérer. C'est donc de ton PC que tu lance cette manip, mais c'est en fait une requête au serveur svn.
Le Trunk s'ajoute donc lorsque tu a récupérer les fichiers (sous Eclipse, ça m'a créer un nouveau projet tout simplement).

Bah oui mais mon projet initial se trouve dejà sur eclipse, donc pour le mettre sur le server svn je dois bien faire un commit de tous mes fichiers non ?
Pour le dossier trunk je pense que je dosi aussi le crée manuellement sur le server svn ?
TOi tu as un dossier trunk car il est deja crée sur le server svn.

Je vais essayer d'éclaircir certains points.

D'abord, un peu de vocabulaire pour que l'on parle de la meme chose.

Faire un checkout, c'est extraire les sources d'une branche avec les infos de version. Cela extrait les sources mais cela créé aussi des répertoires cachés contenant les informations propres au gestionnaire de version (ici subversion) sur chaque fichier et répertoire extrait. Le checkout ne modifie pas le repository.

Faire un extract, c'est extraire les sources sans données propre a subversion. L'extract ne modifie pas le repository.

Dans un répertoire où on a fait un checkout, on peut faire à tout moment et sans plus rien préciser un
svn update. Cela va mettre a jours uniquement les fichiers dans le repertoire courant dont des version serait plus récente dans le serveur subversion (la branche sur laquelle on a fait un checkout est mémorisé lors du checkout, inutile de la repréciser). Un update ne modifie pas le repository.

Un commit : C'est valider les changement que l'on a effectué sur les sources. Les sources sont envoyés vers le repository et une nouvelle version leur est attribués.  On ne peut faire un commit dans un répertoire ou on a effectué au préalable un checkout. Le commit modifie le repository.

Le trunk: C'est le tronc commun. En générale, la version en cours de dev.
Les branches: Ce sont des copies du trunk effectué a un instant T. par exemple, tu fais une releases v2. Tu créé une branche V2. Cela te permet de pouvoir faire la maintenance sur la V2 meme si le trunk évolue de son coté. En gen, lors d'une release, on fait ce qu'on appelle un tag. c'est une photos des sources tel qu'ils sont neccéssaire pour reconstruire la release. Le tag ne doit pas évolué. Il est simplement la pour pouvoir dire: Voila la liste des sources qui permet de construire la V2.  Si tu fois faire une correction, tu copies le tag dans une branche de maintenance. Tu effectues tes corrections. Une fois que c'est Ok, tu releases donc une v2.1 et crée un tag v2.1 qui te servira a maintenir la release v2.1.
Si tu veux réintégrer les corrections effectué dans la v2.1 dans le trunk, il penser a merger le tag dans le trunk.

Concernant ton pb.
Si ce que tu souhaites, c'est travailler en local sur les sources qui sont gérés par le serveur subversion.

Tu te met dans le répertoire où tu souhaites avoir les sources (ton serveur web local), et tu effectue un checkout de la branche ou du trunk. Tu aura donc une copie locale des sources. Si ton tu as correctement configuré ton environnement (serveur web, vhost, etc...) tu dois etre capable de faire fonctionner ton serveur web local avec ces sources.

Tu peux donc commencer à faire tes dev. Un fois que cela fonctionne en local. Tu doit faire un commit. c'est à dire envoyer sur le serveur subversion les modifications que tu as faites. Une fois le commit effectué, toute personne qui fera un checkout ou un update de la même branche que toi disposera des dernière modification que tu viens d'apporter.

Dans ce cas de figure,tu n'as pas besoin d'utiliser les hooks.

Si ce que tu souhaites, c'est synchroniser automatiquement un serveur distant avec les derniers sources (donc après chaque commit). Il faut d'abord faire un checkout sur le serveur distant que tu souhaites maintenir a jour. Dans les hooks, créér un script nommée post-commit (post-commit.tmpl est un exemple), rendre le script exécutable (chmod +x), Dans ce script, tu devrais t'arranger pour executer sur le serveur et dans le répertoire où tu as fais le checkout un "svn update". Cet update sera donc automatiquement effectué après chaque commit, et tu aura donc toujours un serveur avec des sources a jour.

Pour les hooks, il faut faire attention au droits et  au path (il sont exécutés avec les droits et l'environnement du serveur subversion)

en fait, dans ton update,  il ne faut pas repréciser le serveur svn, mais par contre il faut soit etre dans le répertoire ou a eu lieu le checkout ou indiquer le path vers ce répertoire