Forum Programmation.autre Protocole Subversion ? RFC? client web..

Posté par  (site web personnel) .
Étiquettes : aucune
0
5
fév.
2005
Hello,

Je cherche à faire/trouver un viewer web pour subversion en PHP.

Le problème, c'est qu'il n'y a pas de "bindings" pour PHP alors que c'est le cas pour python ou perl...

Le seul client qui existe en PHP (websvn), fait seulement appel au client svn en ligne de commande
(donc il faut que svn soit installé sur le serveur et que la conf de PHP autorise l'execution de programmes avec la commande exec() ou system() ce qui n'est pas le cas sur les serveurs mutualisé par exemple)

Il faudrait donc utiliser un socket par exemple pour communiquer avec subversion.
(cela permettrait meme d'avoir un viewer web en php separé du repository svn car on utiliserait http/webdav pour communiquer)
Hors je n'ai trouvé nul part une référence pour le protocole subversion?
Comment communiquer avec lui, etc...
En gros : comment faire un client subversion...

Savez-vous où la trouver? j'ai rien vu sur le site de svn...
Merci.
  • # subversion...

    Posté par  (site web personnel) . Évalué à 1.

    ViewCVS (http://viewcvs.sourceforge.net/(...)) supporte également Subversion dans ses versions récentes.
    Tu as aussi Trac (http://www.edgewall.com/trac/(...)) qui est un gestionnaire de projet mais qui a une partie pour visionner un repositery Subversion (assez joli à mon goût, mais très basic au niveau des fonctionnalités; il manque notamment des possibilités pour faire des diffs arbitraire).

    Mais ceux là également ne fonctionnent que sur un repositery local, donc en accès via 'file:///', ce qui peut poser pas mal de problèmes; je ne connais pas d'interface web qui le permette.

    Pour l'accès à du subversion, il y a une API php qui existe, par les créateurs de subversion : http://spe.tigris.org/(...)
    Par contre, je sais pas trop si c'est utilisable en l'état actuel ...

    Pour les protocoles, il en existe plusieurs; accès direct au repositery ou via "svnserve" ou via http.
    "svnserve" utilise un protocole dédié. L'accès http utilise une extension normalisée pour avoir du versionning sur WebDAV, donc tu devrais trouver ton bonheur dans les RFCs. Pour plus de détails, le Subversion book : http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-8-sect-1.2(...)

    A mon humble avis, il vaut mieux faire un binding vers l'API subversion, c'est plus propre & plus extensible (support des différents protocoles par exemple). Sauf si tu veux qqchose qui marche uniquement avec du php, sans extension, et sans la présence d'un client subversion, auquel cas il devient effectivement nécessaire de réimplementer le procotole en php.
    • [^] # Re: subversion...

      Posté par  (site web personnel) . Évalué à 1.

      Merci de ta réponse

      ViewCVS => perl
      Trac => python

      donc, ts les deux bénéficie de bindings subversion...
      de plus, très peu d'hébergeur ont python d'installé !
      PHP règne en maitre dans le monde de l'hébergement mutualisé
      d'ou mon but d'avoir du full-PHP !

      SPE, pkoi pas, mais le "hic", c'est que ça ne sera pas inclus dans PHP....
      ce que je voudrais, c'est arriver à proposer un script PHP qui nécéssiste QUE php pour fonctionner... et le PHP de base !!!

      "Sauf si tu veux qqchose qui marche uniquement avec du php, sans extension, et sans la présence d'un client subversion, auquel cas il devient effectivement nécessaire de réimplementer le procotole en php." => OUI, c ça que je veux...
      faire kelkechose qui marche n'importe où du moment que PHP est simplement installé...

      La seule solution est de coder en PHP...
      hors, sur la doc de subversion, je vois pas trop d'explication sur comment faire...
      • [^] # Re: subversion...

        Posté par  (site web personnel) . Évalué à 1.

        Toujours dans le même bouquin, tu trouveras des détails sur le comment et pourquoi du protocole dans l'appendix C : http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ap-c.(...)
        Donc subversion sur http utilise le protocole de la RFC 3253 (http://www.faqs.org/rfcs/rfc3253.html(...) , versionning sur webdav), qui précise tout ce dont il nécessaire pour implémenter un client (miam, vive les normes, bon courage).

        (pour une vision à plus terme, travailler avec SPE peut être intéressant, puisque s'il marche bien, il pourrait être intégré à php ou au moins être dispo chez des hébergeurs... mais bon c'est sûr que pour le moment, ben faut faire avec l'existant ...)
        • [^] # Re: subversion...

          Posté par  (site web personnel) . Évalué à 1.

          SPE... visiblement il y a rien de neuf depuis 1 an...
          je vois pas trop comment intégrer ça à vrai dire...
          t'as testé ?
          c le bordel dans "Document & files", le seul truc que j'ai vu, c ça http://spe.tigris.org/files/documents/1161/12542/php-svn-0.10.1.tar(...) qui est en status "drafts"
          admettons que ça se compile et que l'extension marche dans PHP, le problème reste le même : mon script ne marchera pas sur 99,9% des machines, car si je fournis un script PHP qui necessite recompilation obligatoire de PHP... c pas gagné ;)


          la RFC webdav... houla...
          et comment faire si il y a svnserve de l'autre coté ?
          ces 2 manières d'accéder à subversion sont vraiment totalement différente ?
          (donc il faudrait coder 2 moyens différents pour le viewer, un pr les http(s) et l'autre pr les svn:// )

          Il y a pas qqn qui a developpé un client SVN (tortoise, rapidsvn, ou je ne sais qui) qui aurait gentillement expliqué comment il s'y serait pris ?
          enfin, ils ont surement du tous utiliser une API ou des bindings, du coup, ils ne sont pas posé de questions...

          je commence à croire que faire un viewer svn en PHP relève de l'impossible...
          alors que c'est si simple en CVS... juste un petit socket() etc.. et ça tourne... le protocole reste très simple (pour du pserver)
          Est-ce que les gars de subversion auraient la gentillesse de faire une petite classe PHP ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.