Que protocolo? svn://o http(s)://?

svn+ssh es el protocolo svn que se ejecuta dentro de un túnel SSH. El cliente utiliza SSH para iniciar sesión en el servidor remoto y ejecuta de forma remota el comando svn en ese túnel. En mi opinión, svn+ssh es la forma más fácil de usar un repositorio de subversion en un sistema distante, porque no tiene ningún servidor para lanzar en ese sistema, asumiendo que ya tiene un servidor SSH en ejecución.

También, svn+ssh se beneficia de la protección criptográfica de SSH. No utilice el protocolo raw svn sobre untrusted red.

El principal problema con svn+ssh es que requiere acceso de shell en la máquina remota. Es difícil ofrecer a alguien acceso al repositorio sin darle acceso a toda la cuenta de shell. Para eso, desea uno de los métodos basados en HTTP, es decir, http o https (preferiblemente https debido a la capa de cifrado y autenticación). Estos métodos son más complejos de configurar (necesita un servidor HTTP / HTTPS, por ejemplo, Apache), pero permiten que el administrador del repositorio y controlar con precisión los derechos de acceso al repositorio.

https:// y svn+ssh:// están encriptados y por lo tanto son más seguros para transmitir datos seguros (como su contraseña SVN).

Si es algo como Git, svn+ssh:// será más rápido que https:// y svn:// será más rápido que http://.

También si usa http:// (Apache + SVN), puede hacer que sus usuarios inicien sesión usando la autenticación de Windows con la adición del módulo mod_auth_sspi.

Vea aquí: http://blog.pengoworks.com/index.cfm/2007/11/1/Configuring-Windows-Authentication-with-Apache-22x-and-Subversion

Así que sus desarrolladores (windows) solo tienen que recordar un usuario / contraseña

http y https son manejados por el módulo de servidor web para soporte de Subversion, por lo que puede usar autenticación basada en HTTP (configurada a través de .htaccess) para limitar el acceso a su repositorio).

Se podría decir que svn:// o svn+ssh:// proporcionan mucho mejor rendimiento y velocidad que HTTP simple o HTTPS seguro al acceder a repositorios de Subversion, pero esto no es cierto hoy en día. Mientras que svn:// o svn+ssh:// son más rápidos que HTTP(S), la diferencia no es tan grande como lo fue con SVN 1.6 o versiones anteriores.

No hay problemas importantes de rendimiento con HTTP(S) y los clientes y servidores de Subversion 1.7+ actualizados.

Acceso HTTP(S) con Subversion 1.7 se hizo mucho más eficiente y especialmente en conexiones de red de alta latencia gracias a HTTPv2 (no confunda con HTTP / 2!). Subversion 1.8 cambió de libneon a libserf para acceso HTTP(S) y libserf proporciona un mejor rendimiento que libneon.

Si hay algún problema que cree que está relacionado con el rendimiento de HTTP(S) o Subversion trabajando sobre HTTP(S), debe investigar si hay algún servicio en su red que haga que HTTP(S) sea lento. El la causa raíz podría ser un antivirus, firewall activo o proxy. Sin mencionar una configuración de red mal configurada. ¡Y no se olvide de usar los clientes y servidores de Subversion actualizados!

Pensando en un ejemplo de configuración incorrecta de la red, parece que hay un problema bastante común que afecta a los equipos cliente que trabajan en redes desconectadas que no tienen acceso al sitio de Windows Update (http://ctldl.windowsupdate.com / ). Este es un problema crítico que afecta a una amplia gama de servicios del sistema, pero los usuarios finales lo notan e informan cuando usan clientes de Subversion a través de HTTPS. El problema parece que está relacionado con el rendimiento, pero no lo está. Lea este hilo de StackOverflow para más información: https://stackoverflow.com/a/38499619/761095 .