svn récursif (hooks) ?

Le
mpg
Bonjour,

Ce n'est pas à proprement parler une question relative à Unix, mais je ne
suis pas sûr de connaître un groupe francophone plus approprié.

Je commence à avoir de plus en plus de hooks pour mon dépot svn personnel.
D'habitude, j'aime bien maintenir les scripts que j'utilise sous svn. La
question se pose donc pour les scripts exécutés par les hooks

Est-ce ça vous paraît raisonnable de maintenir ces scripts eux-même dans le
dépôt, et qu'un script post-commit en fasse un checkout à chaque fois, avec
des liens symboliques du répertoire hooks du dépôt vers ce checkout ? Ou
bien est-ce un moyen probable de tout casser ?

Ou bien est-ce plus propre d'avoir un deuxième dépôt, dédié aux hooks du
premier ? Ou toute autre solution ?

Merci d'avance pour vos conseils,
Manuel.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Vincent Lefevre
Le #17799261
Dans l'article mpg
Je commence à avoir de plus en plus de hooks pour mon dépot svn personnel.
D'habitude, j'aime bien maintenir les scripts que j'utilise sous svn. La
question se pose donc pour les scripts exécutés par les hooks...



Idem.

Est-ce ça vous paraît raisonnable de maintenir ces scripts eux-même
dans le dépôt,



C'est ce que je fais.

et qu'un script post-commit en fasse un checkout à chaque fois, avec
des liens symboliques du répertoire hooks du dépôt vers ce checkout ?



Comme je modifie les scripts rarement, je le fais à la main.

Ou bien est-ce un moyen probable de tout casser ?



S'il n'y a pas de bug dans tes scripts de mise à jour, il ne devrait
pas y avoir de problème. Mais fais bien attention...

Si tu casses seulement le répertoire hooks, tu peux toujours réparer
en virant les scripts à la main, en faisant un checkout et en
réinstallant des scripts corrects. Mais si tu casses le répertoire
db en te trompant dans un chemin, c'est plus grave. :)

Ou bien est-ce plus propre d'avoir un deuxième dépôt, dédié aux
hooks du premier ? Ou toute autre solution ?



Je ne pense pas qu'un deuxième dépôt change quoique ce soit.

Attention tout de même avec les mises à jours automatiques: si
quelqu'un pirate une de tes machines où il y a un répertoire de
travail, il pourra plus facilement prendre le contrôle du dépôt
(s'il en a vraiment envie, car c'est tout de même assez spécifique).

--
Vincent Lefèvre 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
mpg
Le #17805431
Le (on) lundi 10 novembre 2008 13:08, Vincent Lefevre a écrit (wrote) :

Est-ce ça vous paraît raisonnable de maintenir ces scripts eux-même
dans le dépôt,



C'est ce que je fais.



Ok.

et qu'un script post-commit en fasse un checkout à chaque fois, avec
des liens symboliques du répertoire hooks du dépôt vers ce checkout ?



Comme je modifie les scripts rarement, je le fais à la main.



Vu.

Attention tout de même avec les mises à jours automatiques:



Oui, je vais sans doute les faire à la main finalement.

si
quelqu'un pirate une de tes machines où il y a un répertoire de
travail, il pourra plus facilement prendre le contrôle du dépôt
(s'il en a vraiment envie, car c'est tout de même assez spécifique).



Vu que la seule méthode d'accès au dépôt est svn+ssh, je pense que ça ne
devrait pas être un problème spécifique (je veux dire, soit l'attaquant
a "craqué" ma clé ssh, et je suis dans la m*rde de toutes façons, soit il
ne peut pas commiter dans le dépôt donc pas de problèmes non plus).

Manuel.
mpg
Le #17805421
Le (on) mardi 11 novembre 2008 01:22, mpg a écrit (wrote) :

Ok.



Et j'ai failli oublier : merci pour ta réponse.

Manuel.
Vincent Lefevre
Le #17839101
Dans l'article mpg
Vu que la seule méthode d'accès au dépôt est svn+ssh, je pense que ça ne
devrait pas être un problème spécifique (je veux dire, soit l'attaquant
a "craqué" ma clé ssh, et je suis dans la m*rde de toutes façons, soit il
ne peut pas commiter dans le dépôt donc pas de problèmes non plus).



Tu peux très bien avoir une clé SSH spécifique à ton serveur Subversion
(c'est ce que j'ai fait: le serveur a son propre utilisateur "svn",
son propre .ssh/authorized_keys, avec une clé par machine où j'ai un
répertoire de travail).

--
Vincent Lefèvre 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Publicité
Poster une réponse
Anonyme