Bonjour à tous
 
  j'ai deux besoin svn. Bien que le premier soit résolut je vous l'expose tout de même afin de ne pas le confondre avec mon deuxieme soucis.
 
J'ai 4 machines :
un poste client sous win ou linux .
Un serveur de développement
Un serveur de prod
Un serveur de source avec SVN d'installé.
 
Mon premier besoin est de consulté en WEB depuis mon poste client le serveur de source. Là aucun problème, ce ne sont pas les outils qui manque (avec comparasion de fichier, historique des modfis, etc ...)
 
Mon deuxieme soucis est, avec un outil en web, de pouvoir depuis mon poste client piloter des commandes SVN (commit) du serveur de dev vers le serveur de source. De la même manière depuis mon poste client, piloter des commandes SVN (update) du serveur de prod en provenance du serveur se source.
 
Et la je sèche.
 
Il existe bien des class php svn fournit par PECL ou bien projet sur googlecode, mais de là à trouver l'outil tout pret qui permet de commiter mes fichiers de dev vers le serveur de source en clic clic depuis une page web, j'ai pas trouvé.
 
 
des idées ?
 
 
Merci

IMO, c'est une première mauvaise idée: un commit, ça se fait pendant qu'on développe, il n'y a strictement aucune raison de le faire via une interface web.

Et là on trouve une mauvaise idée, et une discutable.
 
La première, c'est d'utiliser un checkout svn sur le site de prod (requis pour pouvoir faire un update), c'est un risque de sécurité potentiel
La seconde, c'est que tu veux automatiser tes déploiements. C'est une très bonne idée et il y a des outils pour ça (capistrano, fabric, …)
La 3e, qui est la discutable, c'est de vouloir à tout prix faire ça via une interface web. Pourquoi?

merci pour ta réponse rapide et constructive (ca change des troll)
 

 
on se comprend pas totalement sur ce point.
Mon-PC <--- (outils web) --->  Serveur de dev <--- (commande svn) ---> Serveur de source
Sur mon poste client il n'y a aucune source, tout les développements se font par SFTP vers mes serveurs de dev. Qd je souhaite commiter mes developpement du serveur de dev vers le serveur de source je suis toujours en phase de développement.
 

Je suis sensible à la sécurité et je vais me pencher sur le sujet, mais je souhaiterais tout de même continuer la réflexion sur mon problème
 

 
Non aucun besoin de ce coté.
 

 
Si pour moi la ligne de commande en noir et blanc j'adore, pour l'equipe de développeur web que je gère c'est pas le même plaisir. Le but de pouvoir gerer les commit / update en web, est avant tout un besoin "user-friendly"
 
 

mais pourquoi , dans un soucis d'ergonomie, ne pas utiliser tortoisesvn  ou un des ses clones?

Pardon

Tu veux dire que tu télécharges un fichier sur ton poste local via sftp, que tu l'édites et que tu l'uploades, encore par SFTP?

Bah si, c'est précisément ce que tu demandes.

On fait pas des mises en prod avec tortoise

entre tortoise et du dev perso en php , je choisi vite

C'est quoi ce choix débile

 
Oui tous nos dev sont comme cela, et fonctionne extrèmement bien. Ce ne sont des fichiers web, donc assez petit.
Le téléchargement + upload est totalement transparent. Par sftp on a l'arborscence des serveurs comme si c'etait en local.
Gros avantage :  Tous les développeurs peuvent travailler sur tout les projets depuis n'importe quelle ordianteur et depuis n'importe quel lieu de la même manière. Le poste de travail et le lieu n'ont que peut d'importance.
Mais ce n'est pas le sujet de mon post.
 
Concernant le déploiement on aura jamais plus d'une machine en prod pour un même projet source, donc je parle pas vraiment de déploiement.
 

Tortoise s'utilise si on a les les sources en local. Alors qu'on ne le as pas.
 
Autre raison pour lequels on a pas les sources en local (en plus des avantages déjà cité), si les pages web sont assez légère les base de donnes sont gargantuesque : entre 30 et 50 Go de données par projet.
 
est ce que vous comprenez mieux la raison de ce choix de développement décentralisé, ainsi que mon besoin d'un outil en web pour commité mes sources (le checkout / update sera peut etre fait différement)
 

Ça doit marcher extrèmement bien quand deux personnes travaillent sur le même projet et ont simultanément besoin du même ficheir oui

Sans vouloir être méchant (mais en voulant critiquer), c'est complètement stupide.

Ils n'auraient pas plus d'importance si vous bossiez correctement, avec les devs qui utilisent SVN.

Un projet qui est passé en prod, c'est du déploiement. Que ça soit déployé sur une micro-vm sur une machine pourrie logée dans ton abri de jardin ou sur une ferme de serveurs dans un datacenter chez Google.

T'as pas cité le moindre avantage.

T'es pas obligé d'avoir les bases de données prod sur les postes de dev

Tu ne comprends clairment pas le sens du mot "décentralisé", parce que ce que tu nous expliques là ça n'a strictement rien de décentralisé. C'est même le contraire.

Non.

Masklinn ton premier post etait intéressant et constructif mais maintenant devoir ce justifier de ses choix technique pour faire avancé le débat est vraiment dommage. Enfin je vais essayé ...
dommage... de perdre du temps à ca

Oui tout a fait si les bases etait dans le réseau local.
Mais entre la machine cliente et la la machine de dev se trouve internet (et donc la base aussi est sur internet). Alors que les machines de prod, de dev, et de source, elle sont chez un hébergeur en réseau gigabit.
L'intérêt de ne rien avoir en local est multiple : virus windows, vol, machine en panne. Les postes locaux malade sont réinstallé en 30 minutes avec une galette, pas besoin de sauvegardé chaque poste on ne s'occupe que des serveurs. Pas de serveur sur site, donc pas de salle blanche climatisé et si la société s'agrandit pas de déménagement de serveur.  etc ... etc ... La société va aussi avoir des agences avec des développeurs dans plusieurs pays. Tout est donc centralisé chez un hébergeur : Dev, source, et prod.
 
Le top serait même d'avoir un editeur php en web un peu comme googledocs. (je vais faire des recherches à ce niveau)
 

On est au courant de cela et on a admit que fasse à notre manière de développé ce n'est pas un problème. Un projet est constitué d'un chef de projet et d'un ou deux développeurs travaillant sur des parties totalement différente.
 
Je rappel donc mon problème qui est tout de même le but de mon POST et sur lequel j'aimerai qu'on débate, comment depuis un machine quelconque effectuer un commit d'un serveur de dev vers un serveur de source avec un outil en web ?
 
Merci
 

Non au contraire, ça te force à te poser des questions sur la méthodologie de travail. Si vraiment t'as pas le temps ni l'envie, réponds pas et puis c'est tout
Mais à ta place, vu que ton environnement n'est pas ordinaire, je me poserais des questions sur sa viabilité et son intérêt

Oui mais du coup tu te retrouves avec un "single point of failure" : si ton serveur explose, tu perds tout. Quant aux virus, avec un bon antivirus...
 
Un autre problème, à mon sens, est que vous utilisez 2 moyens différents pour committer vos sources : 1) on patate nos modifs par FTP et 2) on committe via SVN depuis le serveur 1 vers le serveur 2. Ca demande 2 technos et, surtout, pose des problèmes en cas d'accès concurrent dans l'étape 1.
Pourquoi ne pas faire direct du SVN dans le premier cas ?

Ca contredit ce que tu dis avant : si ta société s'agrandit dans plusieurs pays, vous allez vite être confrontés aux problèmes cités plus haut
 
Cette discussion n'est pas anodine : si tu t'aperçois que tu ne trouves pas rapidement d'outil pour ton besoin et que tu rencontres des gens critiquant l'archi technique ou remettant en cause ton besoin, c'est certainement qu'il y a un problème de fond plus important que ce que tu crois.

Non mais perso les bases de dev elles sont directement sur ma machine, ou sur un esclave dont je suis le seul utilisateur quand c'est grand luxe.

Et alors?

Virus windows?
Vol? De quoi De hardware

Je sens l'échec.

Le seul fait que tu trouves avoir des postes locaux vérolés normal et que toute ta strat s'articule autour de ça me choque un micropoil.

On est d'accord là dessus

Bah débats tout seul, perso je suis plus impliqué dans cette discussion, pour autant que je sois concerné votre archi n'est pas utilisable pour faire du dev un tant soit peu sérieux.

Bien avant ça, dès qu'il n'y a plus de net (beaucoup plus fréquent qu'un LAN qui tombe, ce qui arrive aussi) il n'y a plus de boulot possible, idem si le provider a le moindre problème, toute la boite est charrette

this.

 
bonne remarque. Ok pour répondre à toutes les questions.
 

 
Les serveurs sont en raid, + 7 jours de backup sur leur propre disque dur + 30 jours de backup par ftp sur un serveur distant. C'est je pense amplement suffisant. De plus les backup sont testé régulièrement.
 

 
Tu proposerait un truc comme ca ?  
Poste_local <-- (svn) --> serveur de dev <--- (svn) ---> serveur de source
 
oui pkoi pas.  
Avantage ca gère les modif concurente (qui sont quasi impossible mais on ne sait jamais)
Inconvénient ca demande un soft / plugin de plus sur le poste client (sachant qu'il y a des windows et des linux)
Inconvénient2 ca empeche de faire directement les modif sur le serveur de dev par vi par exemple et rend obligatoire l'utilisation d'un poste client (à moins d'extraire les sources sur le serveur de dev pour faire des commit du serveur de dev vers le serveur de dev lui-meme mais dans un autres rep :-/ )
Le fait d'avoir deux technos n'est pas plus genant que cela.
 
Je vais réfléchir à ca.
 
Mais concernant le commit  serveur de dev <--- (svn) ---> serveur de source  tu propose quoi ?
 

je pense pas car plus d'agence = plus de client = plus de projet différent. Et on reste toujours sur la logique pour 1 projet :  1 chef de projet avec 1 ou 2 developpeurs. (mais je suis d'accord que je en suis pas divin et que dans un jour ca pourrait changer, je garde donc à l'esprit ce problème)
 
de plus si outil en web pour modifier les pages, celui là est souvent capable de détecté quel fichier modifier par qui à chaque instant. Il peut gérer un système de verrouillage des fichiers en cours de modif également.
Et cela rend encore moins nécessaire l'installation de soft / plugin sur le poste local car un simple firefox suffirait à modifier les sources. Ca c'est du client leger :-)  Si en plus se soft pouvais effectuer les commit vers le serveur de source ca serait parfait.
 
 
 
 

Si ta connection internet tombe ou celle de ton provider est en caraffe, ça va pas trop aider non.

Tu vas nous dire qu'il n'y a pas besoin d'un soft pour faire du sftp? À ma connaissance, Windows n'a pas de client sftp built-in  

Je vois pas en quoi c'est un inconvénient. Bien au contraire, ça oblige à bosser un minimum correctement.

Bah ouais, réinventons svn en moins bien, après tout c'est pas parce qu'il existe qu'il faut l'utiliser

Non, l'archi "de base" : Poste local  <-- (svn) --> Repository de sources
Tu checkoutes, tu fais ta modif, tu committes et on continue. Le truc habituel, pourquoi compliquer ?

Les clients SVN, ça se trouve plutôt facilement quel que soit l'OS. Y en a même qui sont intégrés direct à l'IDE, indépendamment de l'OS (Subclipse, par exemple).

Alors :

• faire les modifs en direct, c'est sale. Ca ne versionne rien, bonne chance pour faire un rollback ou un déploiement C'est justement le but de passer par SVN .
• de toute façon, stu veux faire une modif en direct via vi/SSH, je vois pas en quoi SVN t'en empêcherait

cf plus haut, pas de serveur de dev. Y a un repository de sources, un système de déploiement puis vous déployez sur un serveur de dev (ou de pré-prod) pour tester le tout puis vous déployez en prod après validation.

• SVN
• SVN aussi, mais critiquable : pourquoi locker un fichier en cours de modif ? Si tu es en train de faire une grosse modif (dev) et que ton collègue veut faire un hot fix parce qu'il manque un truc vital en prod, il fait comment ? L'idée est de permettre les modifs concurrentes et de demander une gestion de merge manuel ensuite en cas de conflit de modifs.
• Ton firefox aussi, il faut l'installer L'argument du "il faut installer un soft" n'est pas recevable : dans tous les cas vous avez besoin d'outils pour bosser (IDE, Photoshop, client FTP, etc...), le client SVN en fait partie et c'est tout C'est pas comme si on te demandait d'installer un truc de malade non plus

Pas chez eux, puisque les commits sont faits depuis le serveur de dev. C'est juste que d'habitude ils codent en local puis balancent les fichiers en remote via SFTP, là ils codent directement en remote, ça fait pas une grosse différence
 

repurposer le serveur "de dev" en serveur d'integ/test
 
Et je tiens à ajouter que je ne vois pas pourquoi les gens se pignolent sur le "client léger", ça a déjà été tenté (je me souviens d'un gros push fin 199x début 200y) et ça a été abandonné parce que c'est merdique dans le cas général (c'est utile dans certains cas précis) et que les avantages étaient très loin de compenser les limitations. Quand on fait du dev, c'est ecore pire.

M'en parle pas Les "applis web" où tu fais tout et n'importe quoi, ça donnait au final des machins pourris avec un serveur ultra-lourdaud, "de l'intelligence mais pas trop" côté client qui fait que tu savais jamais qui faisait quoi, et des archis souvent impossibles à débugguer "Le travail collaboratif" ça s'appelait, avec des portlets et des widgets dans toutes les pages qui pesaient plusieurs Mo chacunes On rigolait pas tous les jours

 
Ya des outils de travail collaboratifs sympas maintenant (SubEthaEdit en desktop, le très très bon Etherpad en webberie), mais je doute de l'intérêt de faire tout son boulot dedans (après quand ça correspond à ton besoin c'est vraiment sympa, on avait joué avec un doc etherpad pour du feedback sur un papier de 0x90, ça avait bien marché, à tel point que NazzTazz s'est payé une license )