Quel protocole? svn: // ou http (s): //?
Il existe quatre protocoles communs pour l'accès réseau de SVN.
svn://repos
svn+ssh://repos
https://repos
http://repos
La page Wikipedia ne dit pas grand-chose sur les différences des quatre protocoles différents. J'ai toujours préféré svn://, car c'est le plus simple à mettre en place, mais quelle est la différence et lequel est "meilleur"?
http:// a un sérieux les frais généraux, en particulier lorsqu'il s'agit de milliers de petits fichiers. J'ai utilisé svn pour un site Web qui avait environ 50 000 icônes, toutes enregistrées dans SVN. Avec HTTP, il a fallu environ 20 minutes pour passer à la caisse. Une fois que je suis passé à svn://, cela a pris moins d'une minute. En effet, avec HTTP, il s'agit d'une nouvelle demande HTTP par fichier.
http:// a cependant le gros avantage suivant: il passe généralement par des pare-feu. Par exemple, maintenant que je suis passé à svn:// Je ne peux plus accéder à mon référentiel depuis mon université à cause de leur pare-feu.
En ce qui concerne la différence entre l'utilisation de SSL/TLS ou non, eh bien, c'est évident: les données sont cryptées; mais c'est plus difficile à mettre en place.
svn+ssh est le protocole svn exécuté dans un tunnel SSH. Le client utilise SSH pour se connecter au serveur distant et exécute à distance la commande svn dans ce tunnel. À mon avis, svn+ssh est le moyen le plus simple d'utiliser un référentiel Subversion sur un système distant, car vous n'avez aucun serveur à lancer sur ce système, en supposant que vous avez déjà un serveur SSH en cours d'exécution.
Également, svn+ssh bénéficie de la protection cryptographique de SSH. N'utilisez pas le protocole brut svn sur des réseaux non approuvés.
Le principal problème avec svn+ssh est qu'il nécessite un accès Shell sur la machine distante. Il est difficile d'offrir à quelqu'un l'accès au référentiel sans lui donner accès à l'ensemble du compte Shell. Pour cela, vous voulez l'une des méthodes basées sur HTTP, c'est-à-dire http ou https (de préférence https en raison de la couche de chiffrement et d'authentification). Ces méthodes sont plus complexes à configurer (vous avez besoin d'un serveur HTTP/HTTPS, par exemple Apache) mais permettent à l'administrateur du référentiel de contrôler soigneusement et précisément les droits d'accès au référentiel.
https:// et svn+ssh:// sont cryptés et sont donc plus sûrs pour la transmission de données sécurisées (comme votre mot de passe SVN).
Si c'est quelque chose comme Git, svn+ssh:// sera plus rapide que https:// et svn:// sera plus rapide que http://.
On pourrait dire que svn:// ou svn+ssh:// fournissent des performances et une vitesse bien meilleures que le HTTP standard ou le HTTPS sécurisé lors de l'accès aux référentiels Subversion, mais ce n'est plus le cas de nos jours. Tandis que svn:// ou svn+ssh:// sont plus rapides que HTTP (S), la différence n'est pas aussi grande qu'avec SVN 1.6 ou des versions plus anciennes.
Il n'y a aucun problème de performance majeur avec les clients et serveurs HTTP (S) et Subversion 1.7+ à jour. =
Accès HTTP (S) avec Subversion 1.7 est devenu beaucoup plus performant et surtout sur les connexions réseau à latence élevée grâce à HTTPv2 (ne pas confondre avec HTTP/2!). Subversion 1.8 est passé de libneon à libserf pour l'accès HTTP (S) et libserf offre de meilleures performances que libneon.
S'il y a un problème qui, selon vous, est lié aux performances de HTTP (S) ou de Subversion fonctionnant sur HTTP (S), vous devez rechercher s'il existe des services sur votre réseau qui ralentissent HTTP (S). La cause première peut être un antivirus, un pare-feu actif ou un proxy. Sans parler des paramètres réseau mal configurés. Et n'oubliez pas d'utiliser des clients et des serveurs Subversion à jour!
En pensant à un exemple de mauvaise configuration du réseau, il semble qu'il existe un problème assez courant qui affecte les ordinateurs clients travaillant sur des réseaux déconnectés qui n'ont pas accès au site Windows Update ( http://ctldl.windowsupdate.com/ ). Il s'agit d'un problème critique qui affecte un large éventail de services système, mais les utilisateurs finaux le remarquent et le signalent lorsqu'ils utilisent des clients Subversion sur HTTPS. Le problème semble être lié aux performances, mais ce n'est pas le cas. Lisez ce fil StackOverflow pour plus d'informations: https://stackoverflow.com/a/38499619/761095 .
De plus, si vous utilisez http: // (Apache + SVN), vous pouvez demander à vos utilisateurs de se connecter en utilisant l'authentification Windows avec l'ajout du module mod_auth_sspi.
Ainsi, vos développeurs (Windows) ne doivent se souvenir que d'un seul utilisateur/mot de passe
http et https sont gérés par le module de serveur Web pour la prise en charge de Subversion, vous pouvez donc utiliser l'authentification HTTP (configurée via .htaccess) pour limiter l'accès à votre référentiel).