client SVN depuis un navigateur

Si tu trouves la solution, cela m'intéresse également !

Nous n'avons pas encore de serveur SVN et développons via SSH ... peux pratique pour les logiciels "svn" classiques

Merci Akarys, c'est aussi ce que j'utilise quand la "working copy" est locale (ou sur du Samba par exemple).
Le hic là c'est justement qu'elle ne peut pas l'être, et que mettre du Samba via Internet ce n'est pas génial. Je ne connais pas bien Windows, mais visiblement il ne gère aucun système de fichier réseau "crypté" en natif... et je ne vais pas mettre en place un VPN pour chaque développeur.

@ mirage :

- plus de fonctionnalités ? oui et non. Perso je l'utilise uniquement en mono-utilisateur et SVN ne m'apporterait pas grand chose.
- CVS & SVN stockent tous les 2 les "diff". Pour la transmission des sources lors d'un update ou commit, tu vois honnêtement la différence entre transférer en ADSL (voire en local !) un fichier de 5 ko ou un de 200 octets ? Pas moi.
- "renommer/déplacer des dossiers avec conservation de l'historique" est aussi possible sous CVS. Il faut simplement le faire sur le /cvsroot.
- c'est peut-être moins vrai maintenant, mais pendant très longtemps CVS était dispo de base sur la plupart des environnement (même en mutualisé !) alors que SVN ...

Le plus important :
- ça va faire 20 ans que j'utilise CVS. Tu ne vas quand même pas me faire changer mes habitudes maintenant ?

Satisfait de mes réponses ?
Akarys

PS: http://www.pushok.com/soft_svn_vscvs.php

Git les mecs, Git !

La meilleure solution reste un VPN (hardware ou software) avec une clé qui peut-être unique ou différenciée pour tous les développeurs, voir même un échange de certificats SSL avec une clé publique et une clé privée. Puis après on laisse le serveur SVN donner les différentes autorisations (repository, dossiers, fichiers) aux utilisateurs possédant chacun un identifiant et un mot de passe associé.
Nous avons de notre côté un routeur qui peut, en théorie, gérer jusqu'à 50 tunnels VPN, ce qui nous permet de nous connecter au réseau interne par Internet et donc d'accèder à SVN ou encore à d'autres applications locales.

Samba via un client VPN ça fonctionne plutôt bien pour des documents textes, par exemple, car légés (après cela dépend aussi de ta capacité réseau). Mais ne compte pas récupérer des fichiers en volume ou volumineux pour des projets avec ce système.
Pour les projets web ou même en matière graphique, il vaut mieux utiliser SVN qui permettra aussi de retrouver une version plus ancienne en cas de problème ou pour gérer différentes branches suite aux évolutions d'un projet.

Je ne suis pas certain de te suivre, mais quel est l'intérêt de ton SVN si tu le mets sur une partition samba ?

Le SVN n'a nullement besoin de ton Samba puisqu'il possède une copie de tous les fichiers dans sa base de données... Tu peux ainsi récupérer le projet en entier ou les dernières modifications apportées sur ton ordinateur et "commiter" (enregistrer) lorsque tu apportes du neuf (fonctionnel en général), de plus il gère les conflits, si deux développeurs bossent sur un même fichier au même moment !

Même avec l'ADSL ton serveur SVN fonctionnera correctement, puisque les développeurs font juste un "update" (mettre à jour les fichiers locaux en recevant les différentiels) du projet sur leur machine. Ces derniers ont un serveur apache ou autre en local et peuvent donc travailler des sites Internet par exemple. Si le besoin d'une base de données est requis : soit la mettre en local, soit rester connecté en VPN pour faire des requêtes sur un serveur local...

J'aurais sûrement du expliquer dès le début ce que je cherchais à faire.
Donc les scripts sont très spécifiques et ne peuvent être testés que sur une machine de développement commune à tous les développeurs.

1) Pour autant, il faut que cela reste simple pour les développeurs : pas plus compliqué qu'un site "classique". Donc ils cliquent sur "Enregistrer" dans leur IDE de développement, puis sur "Actualiser" dans leur Firefox et ils ont directement leur page à l'écran.
Chaque développeur a évidement son propre dossier de travail.

2) Malgré tout ça n'empêche pas d'utiliser SVN, bien au contraire. Après s'être assuré que son code fonctionne, le développeur le livre, récupère les modifs des autres, annule des modifs, etc. Bref, utilisation classique d'un soft de versionnage non ?

3) A partir de là on a aussi un environnement de test, qui est un créé à coup de "svn update" etc. Mais cette fois dans un environnement quasiment identique à la prod.
On peut donc revérifier avant livraison en prod que tout fonctionne au poil.

4) Et finalement on peut synchroniser la prod depuis l'export de test.

=====

Jusque là je ne pense pas demander quoi que ce soit de "tordu". On utilise tous les jours un environnement très proche de ça au boulot, excepté le fait que la machine de développement est en local.

Mais donc ici j'ai ma "working copy" SVN qui est distante, et c'est justement là dessus que je bloque pour les postes Windows (avec du Linux/BSD/Mac, ce serait réglé depuis longtemps avec un montage en NFSv4 et n'importe quel outil svn par dessus).

Les solutions que je vois pour ma part :
- utiliser un montage réseau crypté afin d'avoir la "working copy" en local et ainsi utiliser n'importe quel client SVN. C'est effectivement là que Samba couplé au SVN entrerait en jeu, vu qu'il n'y a pas de version gratuite de client NFSv4 ou "SSHFS" pour Windows.
- trouver un soft SVN qui gère le fait que cette working copy ne soit pas locale, et y accède par exemple via SCP.
- trouver un soft coté Apache qui gèrerait ça directement coté serveur ; ça existe déjà pour IIS mais j'ai pas trouvé. A développer moi même ?
- forcer les développeurs à se connecter en SSH sur le serveur pour utiliser la version cli de SVN
- faire en sorte que les développeurs ouvre à distance une session X pour faire tourner une version nunux de SVN Ca me semble lourdingue, d'autant plus que perso je n'aime aucun des clients SVN sous X.

Après, j'ai peut être loupé un truc hein. Mais pour le moment j'aurais tendance à m'orienter vers le développement du soft Apache... ce qui me gène c'est que je ne développerais jamais toutes les fonctions d'un client SVN classique.

Je n'ai pas testé Zend Studio (qui est payant d'ailleurs), mais c'est justement ce que je ne trouve pas logique : la plupart des "clients SVN" gèrent le fait que le repository ne soit accessible que via SSH, dans le cas d'un IDE ils savent enregistrer via SSH, mais gérer la working copy via SSH ça non... alors que ce n'est même pas une question de protocole du coup. :S

J'essayerais de voir avec le plugin Eclipse à tout hasard.

Merci Telaxo, je vais peut être effectivement m'orienter là dessus.

Ca me semble être la solution la plus simple et rapide à mettre en place. Moyennant les frais de licence.