Bonjour,
 
Pour une Debian de développement, je souhaite installer un système de gestion de versions à base de Subversion.
 
L'idée était de simplifier au maximum le cycle de test pour les développeurs: je souhaite qu'il suffise d'un simple "commit" depuis l'IDE de dév pour que les développeurs puissent tester leur application (par exemple à travers un navigateur pour du PHP).
 
Je me heurte à un problème. J'ai bien installé subversion et créé un dépot, il est accessible depuis les IDE des développeurs. Pourtant, ce dépot SVN ne me permet que de centraliser le code: une fois que ce code est sur le dépot SVN, comment puis-je faire pour que les dernières versions des fichiers apparaissent dans l'arborescence où ils doivent s'exécuter (arborescence située sur la même machine)? L'idée étant que le développeur n'ait pas à intervenir dans ce processus.
 
J'ai bien sûr pensé à un système de liens symboliques, mais le contenu du repository SVN est "illisible" sans client svn. On aurait aussi pu envisager une sorte de "montage svn"...
 
Merci de votre aide,
Silver.

ben selon le nombre de devs et la machine, tu peux envisager de faire un montage samba ou nfs sur l'arborescence de test, et que les devs travaillent et commitent directement dessus. sinon oui il te faudra un client svn sur la machine locale et lancer un svn checkout, ou mieux un svn export pour recuperer la derniere version.

J'ai du mal à interpréter ta réponse...
 
A l'heure actuelle, les clients travaillent en local et peuvent commiter à travers un client SVN. Ceci est déjà implémenté.
Mon problème se situe à partir du moment où le fichier a été updaté sur le dépot SVN: sans intervention de la part du développeur je souhaite que les fichiers qui viennent d'être commités soient mis à jour dans l'arborescence où ils sont exécutés à terme.
 
Il y a peut-être une piste avec post-commit.tmpl.. Je cherche dans ce sens.

reproduis dans ton arborescence de test la même chose que sur un IDE de Dév
 
à savoir que dans ton arbo de test, tu fais un checkout de ton dépôt SVN, puis dans le hook post-commit, tu lances un update sur cette arbo de test
 
ainsi, à chaque commit d'un dev, ton arbo de test aura la dernière version des fichiers ...

Merci de ta réponse fighting_falcon,
 
Je ne me suis pas repenché sur la question depuis hier, j'y reviens aujourd'hui.

Arborescence Preprod = Arborescence Prod
Ok, c'est bien le cas.
 

<!!!> Là je ne saisis pas trop ce qui provoque mon checkout... ?
 

Ah, il faut donc effectivement utiliser le post-commit, <!!!> je vais me renseigner la dessus!
 

...et on aura gagné!
 
 
Une dernière chose:  
On travaille sur plusieurs plateformes prod/preprod, avec pour chaque prod une préprod.
J'ai pensé qu'au point de vue simplicité d'utilisation pour les dev il serait plus simple d'avoir un dépot SVN par preprod. En fin de compte, est-ce qu'il me vaudrait pas mieux avoir un seul dépot SVN sur une machine dédiée? Mais dans ce cas, est-ce que la problématique citée au dessus (update automatique d'une arborescence lors d'un commit) n'est pas rendue plus difficile par le fait que le dépot ne sera plus situé sur la machine de préprod à lauqelle il correspond?
 
Merci d'avoir lu

toi, à la main sur la machine de test, mais tu n'as à le faire que la 1ère fois
 
 

ça ne me parait pas problématique ..
tant que chacune de tes machines de tests ont accès au dépôt SVN
ensuite, sur chaque machine de test, tu fais la 1ère fois, à la main, le checkout qui va bien (comme sur une machine de dev), et dans le hook de post-commit, tu lances une commande ssh qui va se connecter sur la machine de test qui va bien selon ce qui a été commité et qui lance un update sur la machine de test ...

Respect pour la réactivité... Merci.

En fait, je crois qu'il me faudrait un bon cours sur SVN, finalement la seule doc que je trouve c'est cette bible énorme, qui doit tout contenir mais qui reste assez difficile d'accès...

Même avec la doc, je comprends pas à quoi correspond le checkout. Est-ce que c'est l'étape qui me permet d'insérer mes scripts dans le dépot SVN la première fois? Ou est-ce que je suis si perdu que ça???

Enfin, dans la doc ils parlent de créer l'arborescence avec les /trunks, /tag, etc... Je dois aussi faire ça ou mon plugin Eclipse coté client s'en chargera?

OK, était sur la même idée... Seulement, ça sera plus raisonnable si je commence par essayer de bien comprendre SVN en local, et si j'ai le temps je tapoterai un script pour centraliser le code.

alors, cours rapide des commandes SVN :
 
1/ tu commences par définir comment tu vas ranger tes projets dans ton dépôts subversion, c'est là que tu crées (mais ce n'est qu'une recommandation, certes devenue au fil du temps un quasi standard, mais ça reste une recommandation) les répertoires trunk, branches et tags
=> tu créées toute une arbo en locale (mkdir toussa)
 
2/ tu importes toute ton arbo ainsi définie dans ton dépôt. On parle d'import
=> commande svn import
 
3/ si tu ne l'as pas fait en 2, tu importes également les sources (que tu as en locale) de tes projets
=> toujours commande import
 
4/ tu montes un poste de dev, qui devra travailler avec subversion
Il faut alors que tu récupères une copie de travail des projets qui sont dans ton dépôt. C'est ici qu'intervient le "checkout" pour récupérer en local une copie de ce qui se trouve dans le dépôt, et rendre cette copie utilisable par le client subversion
=> commande svn checkout
 
5/ ton dev fait son boulot de dev, il fait des modifs et trouve que c'est bien, il veut "livrer" (commit) ses modifs afin que toi, son boss, ou un testeur voit ce qu'il a fait ...
=> commande svn commit
 
6/ un autre dev (qui a au préalable comme au 4 fait un checkout) veut aussi voir les modifs faites par son ami, il faut qu'il mette à jour (update) son espace de travail afin de récupérer les modifs
=> commande svn update
 
7/ un 3ème dev veut récupérer les modifs du 1er (faites en 4), mais il a lui aussi travailler sur les mêmes fichiers (eh oui, subversion le permet). Il y a donc conflit, puisqu'il existe deux versions du même fichier ..
Ce 3ème dev, quand il va vouloir faire son commit va se faire jeter, parce que le serveur verra que le fichier qu'il a est plus récent (parce que déjà commité par le 1er dev) que celui que ton 3ème dev s'apprête à commiter ... Le client tortoise va alors proposer à ce 3ème dev de mettre à jour (update) son espace de travail et va automatiquement effectuer des "merge" (regroupement, synchro) sur les fichiers modifiés par le 1er et le 3ème dev, de sorte d'incorporer les deux modifs dans le fichier ... Soit ça se fait automatiquement parce que les modifs n'ont pas eu lieu sur la même partie du fichier, soit ce n'est pas possible automatiquement, le client subversion laisse donc le fichier incrimé marqué en "conflit" qu'il faudra résoudre humainement.
Une fois le conflit résolu, on pourra livrer le fichier
=> commandes svn update, svn merge, svn resolved
 
 
 
je pense avoir fait le tour des principales commandes de base ...

Respect, c'est tout à fait clair... Ca aide!
 
La seule chose pour laquelle je vois pas trop comment je vais m'y prendre, c'est que mes dev sont censés commiter à chaque modif, c'est ce commit qui leur permet de tester leur code (cf la raison de ce topic). Donc il va y avoir un nombre incalculable de commit...
En soi, c'est peut-être pas si grave, mais finalement pour un fichier donné, il sera très difficile d'exploiter l'historique pour revenir à une version dont les modifs sont significatives...

beaucoup de commits ...
dans ma boite on est 10 dev depuis 1 ans sur subversion, on est à quasi 7000 révisions ...
sachant qu'on a des compilations automatiques chaque nuit qui créent à elles seules 5 révisions ...
c'est pas énorme non plus

Un grand merci fighting_f​alcon pour ton aide, le système est mis en place!
 
Si ça peut servir à qqun: pour le hook post-commit en sh, j'ai utilisé ssh en local sans quoi subversion ne parvenait pas à effectuer le svn update sur la working copy.