Pour le développement collaboratif d'un site web hébergé sur un serveur sur
lequel je n'ai pas d'autre accès que par (s)ftp (*), j'aimerais utiliser un
dépôt svn et un hook post-commit qui propagerait les modifications par
(s)ftp vers la machine hébergeant le site.
(*) en fait plusieurs sites sont concernés, un en sftp, un en ftp.
J'aimerais bien sûr faire la chose en Perl.
J'ai un peu gouglé et cpané, j'ai juste trouvé des scripts similaires en
python [1] ou en php [2], et un truc en Perl [3] qui doit pouvoir faire le
boulot mais est sans doute un peu trop lourd vu qu'il n'utilise pas les
infos svn, et surtout ne semble pas super adaptable pour le sftp.
Histoire de ne pas ré-inventer la roue, si quelqu'un connaît un truc tout
fait pour ça (j'y crois pas trop) ou en tout cas des modules sympas à
utiliser pour ce genre de tâche...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrice Karatchentzeff
mpg a écrit :
[...]
Pour le développement collaboratif d'un site web hébergé sur un serveur sur lequel je n'ai pas d'autre accès que par (s)ftp (*), j'aimerais utiliser un dépôt svn et un hook post-commit qui propagerait les modifications par (s)ftp vers la machine hébergeant le site.
À chaque commit, tu veux synchroniser ? Ça me parait des plus dangereux comme méthode... ou bien je n'ai pas compris ce que tu veux.
(*) en fait plusieurs sites sont concernés, un en sftp, un en ftp.
J'aimerais bien sûr faire la chose en Perl.
Je ne vois pas bien le rapport. Le hook concerné (post-commit) est un bête script shell : il te suffit de taper ta commande de syncho ftp (si possible sans interaction). Pas besoin de Perl là-dedans (vu que c'est du shell hyper basique)...
Ou alors, quelque chose m'échappe dans ta demande...
Pour le développement collaboratif d'un site web hébergé sur un serveur sur
lequel je n'ai pas d'autre accès que par (s)ftp (*), j'aimerais utiliser un
dépôt svn et un hook post-commit qui propagerait les modifications par
(s)ftp vers la machine hébergeant le site.
À chaque commit, tu veux synchroniser ? Ça me parait des plus
dangereux comme méthode... ou bien je n'ai pas compris ce que tu veux.
(*) en fait plusieurs sites sont concernés, un en sftp, un en ftp.
J'aimerais bien sûr faire la chose en Perl.
Je ne vois pas bien le rapport. Le hook concerné (post-commit) est un
bête script shell : il te suffit de taper ta commande de syncho ftp
(si possible sans interaction). Pas besoin de Perl là-dedans (vu que
c'est du shell hyper basique)...
Ou alors, quelque chose m'échappe dans ta demande...
Pour le développement collaboratif d'un site web hébergé sur un serveur sur lequel je n'ai pas d'autre accès que par (s)ftp (*), j'aimerais utiliser un dépôt svn et un hook post-commit qui propagerait les modifications par (s)ftp vers la machine hébergeant le site.
À chaque commit, tu veux synchroniser ? Ça me parait des plus dangereux comme méthode... ou bien je n'ai pas compris ce que tu veux.
(*) en fait plusieurs sites sont concernés, un en sftp, un en ftp.
J'aimerais bien sûr faire la chose en Perl.
Je ne vois pas bien le rapport. Le hook concerné (post-commit) est un bête script shell : il te suffit de taper ta commande de syncho ftp (si possible sans interaction). Pas besoin de Perl là-dedans (vu que c'est du shell hyper basique)...
Ou alors, quelque chose m'échappe dans ta demande...
Le (on) jeudi 06 novembre 2008 09:19, Patrice Karatchentzeff a écrit (wrote) :
À chaque commit, tu veux synchroniser ?
Euh, a priori oui, histoire de pouvoir voir les changements immédiatement sur le site.
Ça me parait des plus dangereux comme méthode... ou bien je n'ai pas compris ce que tu veux.
Peut-être est-ce moi qui n'ai pas vu le danger. Pourquoi penses-tu que c'est dangereux ?
Je ne vois en tout cas pas en quoi c'est plus dangereux que la méthode à l'ancienne où à chaque fois qu'un contributeur du site veut modifier une page, il la dl par ftp, la modifie localement, puis l'uploade en croisant les doigts pour que personne ne l'ai modifiée sur le ftp entre temps...
J'aimerais bien sûr faire la chose en Perl.
Je ne vois pas bien le rapport. Le hook concerné (post-commit) est un bête script shell : il te suffit de taper ta commande de syncho ftp
On est d'accord. Le truc est que je pensais que le commande de synchro ftp en question serait à écrire, parce que je ne connais pas de commande qui soit capable d'analyser le log de la dernière transaction svn pour en déduire les fichiers à uploader ou pas. L'idée est d'éviter de devoir tranférer toute l'arborescence à chaque fois , et comme je ne connais pas d'équivalent de rsync qui marche sur du (s)ftp...
Si j'ai manqué une manière très simple de procéder, merci d'avance de me le signaler !
Manuel.
Le (on) jeudi 06 novembre 2008 09:19, Patrice Karatchentzeff a écrit
(wrote) :
À chaque commit, tu veux synchroniser ?
Euh, a priori oui, histoire de pouvoir voir les changements immédiatement
sur le site.
Ça me parait des plus
dangereux comme méthode... ou bien je n'ai pas compris ce que tu veux.
Peut-être est-ce moi qui n'ai pas vu le danger. Pourquoi penses-tu que c'est
dangereux ?
Je ne vois en tout cas pas en quoi c'est plus dangereux que la méthode à
l'ancienne où à chaque fois qu'un contributeur du site veut modifier une
page, il la dl par ftp, la modifie localement, puis l'uploade en croisant
les doigts pour que personne ne l'ai modifiée sur le ftp entre temps...
J'aimerais bien sûr faire la chose en Perl.
Je ne vois pas bien le rapport. Le hook concerné (post-commit) est un
bête script shell : il te suffit de taper ta commande de syncho ftp
On est d'accord. Le truc est que je pensais que le commande de synchro ftp
en question serait à écrire, parce que je ne connais pas de commande qui
soit capable d'analyser le log de la dernière transaction svn pour en
déduire les fichiers à uploader ou pas. L'idée est d'éviter de devoir
tranférer toute l'arborescence à chaque fois , et comme je ne connais pas
d'équivalent de rsync qui marche sur du (s)ftp...
Si j'ai manqué une manière très simple de procéder, merci d'avance de me le
signaler !
Le (on) jeudi 06 novembre 2008 09:19, Patrice Karatchentzeff a écrit (wrote) :
À chaque commit, tu veux synchroniser ?
Euh, a priori oui, histoire de pouvoir voir les changements immédiatement sur le site.
Ça me parait des plus dangereux comme méthode... ou bien je n'ai pas compris ce que tu veux.
Peut-être est-ce moi qui n'ai pas vu le danger. Pourquoi penses-tu que c'est dangereux ?
Je ne vois en tout cas pas en quoi c'est plus dangereux que la méthode à l'ancienne où à chaque fois qu'un contributeur du site veut modifier une page, il la dl par ftp, la modifie localement, puis l'uploade en croisant les doigts pour que personne ne l'ai modifiée sur le ftp entre temps...
J'aimerais bien sûr faire la chose en Perl.
Je ne vois pas bien le rapport. Le hook concerné (post-commit) est un bête script shell : il te suffit de taper ta commande de syncho ftp
On est d'accord. Le truc est que je pensais que le commande de synchro ftp en question serait à écrire, parce que je ne connais pas de commande qui soit capable d'analyser le log de la dernière transaction svn pour en déduire les fichiers à uploader ou pas. L'idée est d'éviter de devoir tranférer toute l'arborescence à chaque fois , et comme je ne connais pas d'équivalent de rsync qui marche sur du (s)ftp...
Si j'ai manqué une manière très simple de procéder, merci d'avance de me le signaler !
Manuel.
Patrice Karatchentzeff
mpg a écrit :
Le (on) jeudi 06 novembre 2008 09:19, Patrice Karatchentzeff a écrit (wrote) :
> À chaque commit, tu veux synchroniser ?
Euh, a priori oui, histoire de pouvoir voir les changements immédiatement sur le site.
> Ça me parait des plus dangereux comme méthode... ou bien je n'ai > pas compris ce que tu veux. > Peut-être est-ce moi qui n'ai pas vu le danger. Pourquoi penses-tu que c'est dangereux ?
Si ton site est un site « en production », rien de moins que de casser ton site... quand on a tes besoin, on a un serveur intermédiaire sur lequel on fait la manip normalement... on appelle ça un serveur de développement.
C'est tout mais ça dépend du degré de service que tu cherches à obtenir de ton serveur : si cela te convient, rien ne t'empêche de faire cela...
[...]
> Je ne vois pas bien le rapport. Le hook concerné (post-commit) est > un bête script shell : il te suffit de taper ta commande de syncho > ftp
On est d'accord. Le truc est que je pensais que le commande de synchro ftp en question serait à écrire, parce que je ne connais pas de commande qui soit capable d'analyser le log de la dernière transaction svn pour en déduire les fichiers à uploader ou pas. L'idée est d'éviter de devoir tranférer toute l'arborescence à chaque fois , et comme je ne connais pas d'équivalent de rsync qui marche sur du (s)ftp...
lftp le fait bien (il a une option mirror). Mais il faut qu'il soit installé sur le serveur (si c'est une machine avec un OS genre linux ou BSD, c'est trivial à faire).
Le (on) jeudi 06 novembre 2008 09:19, Patrice Karatchentzeff a écrit
(wrote) :
> À chaque commit, tu veux synchroniser ?
Euh, a priori oui, histoire de pouvoir voir les changements
immédiatement sur le site.
> Ça me parait des plus dangereux comme méthode... ou bien je n'ai
> pas compris ce que tu veux.
>
Peut-être est-ce moi qui n'ai pas vu le danger. Pourquoi penses-tu
que c'est dangereux ?
Si ton site est un site « en production », rien de moins que de casser
ton site... quand on a tes besoin, on a un serveur intermédiaire sur
lequel on fait la manip normalement... on appelle ça un serveur de
développement.
C'est tout mais ça dépend du degré de service que tu cherches à
obtenir de ton serveur : si cela te convient, rien ne t'empêche de
faire cela...
[...]
> Je ne vois pas bien le rapport. Le hook concerné (post-commit) est
> un bête script shell : il te suffit de taper ta commande de syncho
> ftp
On est d'accord. Le truc est que je pensais que le commande de
synchro ftp en question serait à écrire, parce que je ne connais pas
de commande qui soit capable d'analyser le log de la dernière
transaction svn pour en déduire les fichiers à uploader ou pas.
L'idée est d'éviter de devoir tranférer toute l'arborescence à
chaque fois , et comme je ne connais pas d'équivalent de rsync qui
marche sur du (s)ftp...
lftp le fait bien (il a une option mirror). Mais il faut qu'il soit
installé sur le serveur (si c'est une machine avec un OS genre linux
ou BSD, c'est trivial à faire).
Le (on) jeudi 06 novembre 2008 09:19, Patrice Karatchentzeff a écrit (wrote) :
> À chaque commit, tu veux synchroniser ?
Euh, a priori oui, histoire de pouvoir voir les changements immédiatement sur le site.
> Ça me parait des plus dangereux comme méthode... ou bien je n'ai > pas compris ce que tu veux. > Peut-être est-ce moi qui n'ai pas vu le danger. Pourquoi penses-tu que c'est dangereux ?
Si ton site est un site « en production », rien de moins que de casser ton site... quand on a tes besoin, on a un serveur intermédiaire sur lequel on fait la manip normalement... on appelle ça un serveur de développement.
C'est tout mais ça dépend du degré de service que tu cherches à obtenir de ton serveur : si cela te convient, rien ne t'empêche de faire cela...
[...]
> Je ne vois pas bien le rapport. Le hook concerné (post-commit) est > un bête script shell : il te suffit de taper ta commande de syncho > ftp
On est d'accord. Le truc est que je pensais que le commande de synchro ftp en question serait à écrire, parce que je ne connais pas de commande qui soit capable d'analyser le log de la dernière transaction svn pour en déduire les fichiers à uploader ou pas. L'idée est d'éviter de devoir tranférer toute l'arborescence à chaque fois , et comme je ne connais pas d'équivalent de rsync qui marche sur du (s)ftp...
lftp le fait bien (il a une option mirror). Mais il faut qu'il soit installé sur le serveur (si c'est une machine avec un OS genre linux ou BSD, c'est trivial à faire).
Le (on) jeudi 06 novembre 2008 14:46, Patrice Karatchentzeff a écrit (wrote) :
Si ton site est un site « en production », rien de moins que de casser ton site... quand on a tes besoin, on a un serveur intermédiaire sur lequel on fait la manip normalement... on appelle ça un serveur de développement.
À la réflexion, tu as tout à fait raison. Au moins pour l'un des deux sites que j'envisageais de maintenir comme ça, que je ne peux pas me permettre de casser.
C'est tout mais ça dépend du degré de service que tu cherches à obtenir de ton serveur : si cela te convient, rien ne t'empêche de faire cela...
L'autre site est ma page perso à la fac, ça me gênerait moins de la casser, mais je vais prendre le temps de réfléchir. (Pour l'instant, enfin depuis pas longtemps, je la synchronise par rsync sur une copie de travail svn, le tout via un hook svn. Bientôt je n'aurais plus d'accès shell à la machine qui l'héberge, juste sftp.)
lftp le fait bien (il a une option mirror).
Ah cool, je savais pas.
Mais il faut qu'il soit installé sur le serveur (si c'est une machine avec un OS genre linux ou BSD, c'est trivial à faire).
Euh, à condition d'avoir la main sur la machine, non ? Ce qui n'est pas le cas ici (si ça l'étais je préférerais sans doute rsync+ssh à ftp).
Manuel.
Le (on) jeudi 06 novembre 2008 14:46, Patrice Karatchentzeff a écrit
(wrote) :
Si ton site est un site « en production », rien de moins que de casser
ton site... quand on a tes besoin, on a un serveur intermédiaire sur
lequel on fait la manip normalement... on appelle ça un serveur de
développement.
À la réflexion, tu as tout à fait raison. Au moins pour l'un des deux sites
que j'envisageais de maintenir comme ça, que je ne peux pas me permettre de
casser.
C'est tout mais ça dépend du degré de service que tu cherches à
obtenir de ton serveur : si cela te convient, rien ne t'empêche de
faire cela...
L'autre site est ma page perso à la fac, ça me gênerait moins de la casser,
mais je vais prendre le temps de réfléchir. (Pour l'instant, enfin depuis
pas longtemps, je la synchronise par rsync sur une copie de travail svn, le
tout via un hook svn. Bientôt je n'aurais plus d'accès shell à la machine
qui l'héberge, juste sftp.)
lftp le fait bien (il a une option mirror).
Ah cool, je savais pas.
Mais il faut qu'il soit
installé sur le serveur (si c'est une machine avec un OS genre linux
ou BSD, c'est trivial à faire).
Euh, à condition d'avoir la main sur la machine, non ? Ce qui n'est pas le
cas ici (si ça l'étais je préférerais sans doute rsync+ssh à ftp).
Le (on) jeudi 06 novembre 2008 14:46, Patrice Karatchentzeff a écrit (wrote) :
Si ton site est un site « en production », rien de moins que de casser ton site... quand on a tes besoin, on a un serveur intermédiaire sur lequel on fait la manip normalement... on appelle ça un serveur de développement.
À la réflexion, tu as tout à fait raison. Au moins pour l'un des deux sites que j'envisageais de maintenir comme ça, que je ne peux pas me permettre de casser.
C'est tout mais ça dépend du degré de service que tu cherches à obtenir de ton serveur : si cela te convient, rien ne t'empêche de faire cela...
L'autre site est ma page perso à la fac, ça me gênerait moins de la casser, mais je vais prendre le temps de réfléchir. (Pour l'instant, enfin depuis pas longtemps, je la synchronise par rsync sur une copie de travail svn, le tout via un hook svn. Bientôt je n'aurais plus d'accès shell à la machine qui l'héberge, juste sftp.)
lftp le fait bien (il a une option mirror).
Ah cool, je savais pas.
Mais il faut qu'il soit installé sur le serveur (si c'est une machine avec un OS genre linux ou BSD, c'est trivial à faire).
Euh, à condition d'avoir la main sur la machine, non ? Ce qui n'est pas le cas ici (si ça l'étais je préférerais sans doute rsync+ssh à ftp).
