Salut tout le monde,
Je viens d'installer sur mon serveur (mutualisé OVH) le gestionnaire de version Subversion, et ce dans le but d'un travail collaboratif sur un projet de Webdev.
J'ai donc créé un dépôt sur mon serveur et importé tous mes fichiers. J'ai ensuite procédé à deux copies, l'une sur le serveur (qui est en faite le site en live, comprenez le dossier accessible en ligne (/www)) et une autre copie sur ma machine. Je fais donc de multiples tests (checkout, update, add, commit, etc...) et tout fonctionne pour le mieux.
Maintenant, j'aimerai automatiser un peu le tout. J'aimerai que lorsque je fais un "commit" sur ma machine, le serveur lance un "update" pour la copie qui se trouve sur le serveur (dossier /www). Cela me permettrait de mettre à jour directement mon site, en faisant simplement des "commit".
Car là actuellement, dès que je fais un commit sur ma machine, il faut que j'aille faire un "update" sur le dossier /www. Pas très pratique donc.
J'ai donc fouillé depuis ce matin le web, et on m'a conduit naturellement vers les Hooks, et notamment le Hook post-commit. Il faudrait donc que j'écrive un script Hook, afin de lancer automatiquement des "update" après un "commit". Mais c'est là que ça coince...
En effet, je bloque depuis maintenant plus de 3H sur la façon dont écrire ce script. Je n'ai aucune idée malgré de nombreuses recherche, sur la façon dont je pourrai m'y prendre...
J'ai trouvé sur la doc. officielle ceci : http://subversion.ti...ite-auto-update
Mais j'ai un peu de mal à comprendre la méthode.
Je vous remercie d'avance !
0
Subversion : hook post-commit
Débuté par Sogeking68857, 11 décembre 2009 à 16:36
10 réponses à ce sujet
#2
-
- SUPINFO
- 86 messages
Posté 11 décembre 2009 à 22:16
C'est pas compliqué 
Normalement, dans ton répertoire svn sur le serveur tu as un dossier hooks.
Dedans tu créais un fichier qui va s'appeler post-commit.
Et à l'intérieur tu mets ton script. Pour faire un update du bash ira très bien :
Normalement, dans ton répertoire svn sur le serveur tu as un dossier hooks.
Dedans tu créais un fichier qui va s'appeler post-commit.
Et à l'intérieur tu mets ton script. Pour faire un update du bash ira très bien :
#!/bin/bash svn update /chemin/vers/site/
#3
-
- SUPINFO ★
- 484 messages
Posté 11 décembre 2009 à 22:28
Merci, merci beaucoup !
Effectivement, je cherchais beaucoup plus compliqué qu'un simple script bash !
Effectivement, je cherchais beaucoup plus compliqué qu'un simple script bash !
#4
-
- Membre
- 4 messages
Posté 08 avril 2010 à 10:51
Bonjour,
Je suis tombé sur ce topic par hasard en faisant des recherches sur le même problème, et si vous le permettez j'aimerai que vous m'aidiez à résoudre un petit problème
J'ai bel et bien configuré mon SVN sous OVH (avec clé privée, PuTTy.. etc) et la connexion avec Tortoise SVN fonctionne parfaitement.
J'ai crée dans mon dossier de travail un fichier "test.txt", puis j'ai fais un "commit" avec Tortoise SVN.. le fichier à bien été envoyé au serveur et apparaît en tant que valide dans mon explorateur Windows :
Seulement quand je vais sur mon FTP avec Filezilla, je ne vois nulle part ce fameux fichier.
D'où ma question, y aurait t-il une manipulation que j'aurai oublié ?
Merci pour votre aide
jeff
Je suis tombé sur ce topic par hasard en faisant des recherches sur le même problème, et si vous le permettez j'aimerai que vous m'aidiez à résoudre un petit problème
J'ai bel et bien configuré mon SVN sous OVH (avec clé privée, PuTTy.. etc) et la connexion avec Tortoise SVN fonctionne parfaitement.
J'ai crée dans mon dossier de travail un fichier "test.txt", puis j'ai fais un "commit" avec Tortoise SVN.. le fichier à bien été envoyé au serveur et apparaît en tant que valide dans mon explorateur Windows :
Seulement quand je vais sur mon FTP avec Filezilla, je ne vois nulle part ce fameux fichier.
D'où ma question, y aurait t-il une manipulation que j'aurai oublié ?
Merci pour votre aide
jeff
#5
-
- SUPINFO ★
- 484 messages
Posté 09 avril 2010 à 07:50
jeff52, le 08 avril 2010 à 10:51, dit :
Bonjour,
Je suis tombé sur ce topic par hasard en faisant des recherches sur le même problème, et si vous le permettez j'aimerai que vous m'aidiez à résoudre un petit problème
J'ai bel et bien configuré mon SVN sous OVH (avec clé privée, PuTTy.. etc) et la connexion avec Tortoise SVN fonctionne parfaitement.
J'ai crée dans mon dossier de travail un fichier "test.txt", puis j'ai fais un "commit" avec Tortoise SVN.. le fichier à bien été envoyé au serveur et apparaît en tant que valide dans mon explorateur Windows :
Seulement quand je vais sur mon FTP avec Filezilla, je ne vois nulle part ce fameux fichier.
D'où ma question, y aurait t-il une manipulation que j'aurai oublié ?
Merci pour votre aide
jeff
Je suis tombé sur ce topic par hasard en faisant des recherches sur le même problème, et si vous le permettez j'aimerai que vous m'aidiez à résoudre un petit problème
J'ai bel et bien configuré mon SVN sous OVH (avec clé privée, PuTTy.. etc) et la connexion avec Tortoise SVN fonctionne parfaitement.
J'ai crée dans mon dossier de travail un fichier "test.txt", puis j'ai fais un "commit" avec Tortoise SVN.. le fichier à bien été envoyé au serveur et apparaît en tant que valide dans mon explorateur Windows :
Seulement quand je vais sur mon FTP avec Filezilla, je ne vois nulle part ce fameux fichier.
D'où ma question, y aurait t-il une manipulation que j'aurai oublié ?
Merci pour votre aide
jeff
Pour moi il n'y a rien d'anormal
L'architecture d'un répertoire SVN est différente d'un répertoire usuel. Ne cherche pas tes fichiers là dessus ;-)
Si tu veux vérifier que ton fichier est bien sur ton serveur, fais un svn checkout sur un autre dossier ou sur un autre ordinateur.
Bon courrage ;-)
#6
-
- Membre
- 4 messages
Posté 09 avril 2010 à 09:31
Ok d'accord.
Mais du coup je comprend plus.. le but est de travailler à plusieurs sur la version en ligne du site.
A la fin, les fichiers qui sont sur le serveur il faut bien pouvoir les voir dans l'arborescence du ftp (et même si possible dans le dossier /www/) non ?
Mais du coup je comprend plus.. le but est de travailler à plusieurs sur la version en ligne du site.
A la fin, les fichiers qui sont sur le serveur il faut bien pouvoir les voir dans l'arborescence du ftp (et même si possible dans le dossier /www/) non ?
#7
-
- SUPINFO ★
- 484 messages
Posté 09 avril 2010 à 13:54
jeff52, le 09 avril 2010 à 09:31, dit :
Ok d'accord.
Mais du coup je comprend plus.. le but est de travailler à plusieurs sur la version en ligne du site.
A la fin, les fichiers qui sont sur le serveur il faut bien pouvoir les voir dans l'arborescence du ftp (et même si possible dans le dossier /www/) non ?
Mais du coup je comprend plus.. le but est de travailler à plusieurs sur la version en ligne du site.
A la fin, les fichiers qui sont sur le serveur il faut bien pouvoir les voir dans l'arborescence du ftp (et même si possible dans le dossier /www/) non ?
Il ne faut pas que ton dossier subversion et ton dossier www soient les même !
C'est d'ailleurs pour cela que j'avais besoin de créer un hook post-commit, pour mettre à jour automatiquement mon dossier www une fois que mon dossier subversion était commité.
C'est clair ou pas
?
#8
-
- Membre
- 4 messages
Posté 09 avril 2010 à 15:38
Sogeking68857, le 09 avril 2010 à 13:54, dit :
Il ne faut pas que ton dossier subversion et ton dossier www soient les même !
C'est d'ailleurs pour cela que j'avais besoin de créer un hook post-commit, pour mettre à jour automatiquement mon dossier www une fois que mon dossier subversion était commité.
C'est clair ou pas ?
C'est d'ailleurs pour cela que j'avais besoin de créer un hook post-commit, pour mettre à jour automatiquement mon dossier www une fois que mon dossier subversion était commité.
C'est clair ou pas
?Ah d'accord! Donc pour que mes fichiers du /www/ soient automatiquement mis à jour, je dois faire comme indiqué plus haut, à savoir créer un fichier "post-commit" avec du bash dedans ?
#9
-
- SUPINFO ★
- 484 messages
Posté 09 avril 2010 à 23:05
jeff52, le 09 avril 2010 à 15:38, dit :
Ah d'accord! Donc pour que mes fichiers du /www/ soient automatiquement mis à jour, je dois faire comme indiqué plus haut, à savoir créer un fichier "post-commit" avec du bash dedans ?
Tout à fait. Relis les deux premiers posts, c'est exactement ça ;-)
#10
-
- Membre
- 4 messages
Posté 10 avril 2010 à 14:35
Purée c'est dingue, j'ai fais comme indiqué plus haut mais rien à faire ça fonctionne pas!
J'ai fais une petite vidéo de comment je procède, c'est beaucoup plus simple qu'un long discourt et si ça se trouve, tu verra tout de suite où est le problème
http://www.jeff52.fr...ost-commit.html
J'ai fais une petite vidéo de comment je procède, c'est beaucoup plus simple qu'un long discourt et si ça se trouve, tu verra tout de suite où est le problème
http://www.jeff52.fr...ost-commit.html
#11
-
- SUPINFO ★★
- 106 messages
Posté 12 juillet 2010 à 08:20
oulala.
déjà cette technique permet de pouvoir déployer des sites web rapidement si ils contient du code commun (un framework commun, un répertoire commun de code etc...) ou tout simplement si plusieurs webmasters s'occupent de la mise en prod.
c'est tout!
le couple : programmation à vue + on update a gogo sur le prod en direct à chaque modif, c'est n'importe quoi (ou alors sur un site test).
mais les tests rapide autant le faire en localhost avant, c'est carrément plus rapide, puis tu commit le tout à la fin sur le prod.(pratique si tu code un bout de ton site comme une rubrique)
ou alors commite/update entre vous et le serveur de prod fait un update manuel pour balancer d'un coup le code.
bref,
pour faire un svn update sur un site web, il y a déjà d'autres paramètre à prendre en compte, à savoir les droits !
ton post-comit dois effectivement faire le update mais avec les droits du user qui utilise le compte ftp du site !!! et non root
il y a aussi le fait qu'il faut définitivement ne plus toucher au FTP quand on utilise ce cas de figure! sinon les fichiers se mettront en conflit de version dès que tu veux modif à la mano.
et il faut prévoir des portes de sortie comme pouvoir utilser les svn clean ou unlock depuis le serveur avec les bon droits (donc aller régulierement sur putty ou création de script maison en PHP)
et reboucher la sécurité car "ce n'est pas fait pour", donc sécure les dossiers caché .svn etc...
j'utilise cette technique depuis quelques temps pour mes dizaines de sites web avec le meme framework maison et j'en suis très content.
par contre, aucun tuto sur le net. donc tu navigue à l'aveugle sur ce coup la...
bonne chance pour les courageux
déjà cette technique permet de pouvoir déployer des sites web rapidement si ils contient du code commun (un framework commun, un répertoire commun de code etc...) ou tout simplement si plusieurs webmasters s'occupent de la mise en prod.
c'est tout!
le couple : programmation à vue + on update a gogo sur le prod en direct à chaque modif, c'est n'importe quoi (ou alors sur un site test).
mais les tests rapide autant le faire en localhost avant, c'est carrément plus rapide, puis tu commit le tout à la fin sur le prod.(pratique si tu code un bout de ton site comme une rubrique)
ou alors commite/update entre vous et le serveur de prod fait un update manuel pour balancer d'un coup le code.
bref,
pour faire un svn update sur un site web, il y a déjà d'autres paramètre à prendre en compte, à savoir les droits !
ton post-comit dois effectivement faire le update mais avec les droits du user qui utilise le compte ftp du site !!! et non root
il y a aussi le fait qu'il faut définitivement ne plus toucher au FTP quand on utilise ce cas de figure! sinon les fichiers se mettront en conflit de version dès que tu veux modif à la mano.
et il faut prévoir des portes de sortie comme pouvoir utilser les svn clean ou unlock depuis le serveur avec les bon droits (donc aller régulierement sur putty ou création de script maison en PHP)
et reboucher la sécurité car "ce n'est pas fait pour", donc sécure les dossiers caché .svn etc...
j'utilise cette technique depuis quelques temps pour mes dizaines de sites web avec le meme framework maison et j'en suis très content.
par contre, aucun tuto sur le net. donc tu navigue à l'aveugle sur ce coup la...
bonne chance pour les courageux
