subversion - tag svn
¿Qué protocolo? svn:// o http(s)://? (6)
Además, si usa http: // (Apache + SVN), puede hacer que sus usuarios inicien sesión utilizando la Autenticación de Windows con la adición del módulo mod_auth_sspi.
Entonces tus desarrolladores (de Windows) solo tienen que recordar un usuario / contraseña
Hay cuatro protocolos comunes para el acceso a la red de SVN.
svn://repos
svn+ssh://repos
https://repos
http://repos
La página de Wikipedia no dice mucho sobre las diferencias de los cuatro protocolos diferentes. Siempre he preferido svn:// , porque es el más fácil de configurar, pero ¿cuál es la diferencia y cuál es "mejor"?
Se podría decir que svn:// o svn+ssh:// proporcionan un mejor rendimiento y velocidad que HTTP simple o HTTPS seguro cuando se accede a repositorios de Subversion, pero esto no es cierto hoy en día. Mientras svn:// o svn+ssh:// son más rápidos que HTTP (S), la diferencia no es tan grande como lo era con SVN 1.6 o versiones anteriores.
No hay problemas de rendimiento importantes con HTTP (S) y servidores y clientes actualizados de Subversion 1.7+.
El acceso HTTP (S) con Subversion 1.7 se convirtió en mucho más eficaz 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 el libserf HTTP (S) y libserf proporciona un mejor rendimiento que libneon .
Si hay algún problema que crea que está relacionado con el rendimiento de HTTP (S) o Subversion que funciona a través de HTTP (S), debe investigar si hay algún servicio en su red que haga que HTTP (S) sea lento. La causa raíz podría ser un antivirus, firewall activo o proxy. Sin mencionar una configuración de red mal configurada. ¡Y no olvide utilizar servidores y clientes actualizados de Subversion!
Pensando en un ejemplo de configuración incorrecta de la red, parece que hay un problema bastante común que afecta a las computadoras cliente que trabajan en redes desconectadas que no tienen acceso al sitio de actualización de Windows ( 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 al usar clientes de Subversion a través de HTTPS. El problema parece estar relacionado con el rendimiento, pero no es así. Lea este hilo de para obtener más información: https://.com/a/38499619/761095 .
http:// tiene una sobrecarga importante, especialmente cuando se trata de miles de pequeños archivos. Usé svn para un sitio web que tenía alrededor de 50,000 iconos, todos guardados en SVN. Con HTTP, tomó aproximadamente 20 minutos para finalizar la compra. Una vez que cambié a svn:// , tomó menos de un minuto. Esto se debe a que con HTTP es una nueva solicitud HTTP por archivo.
http:// sin embargo tiene la siguiente gran ventaja: generalmente pasa por firewalls. Por ejemplo, ahora que cambié a svn:// ya no puedo acceder a mi repositorio desde mi universidad debido a su firewall.
Respecto a la diferencia entre usar SSL / TLS o no, bueno, es obvio: los datos están encriptados; sin embargo, es más difícil de configurar.
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).
https:// y svn+ssh:// están encriptados y, por lo tanto, son más seguros para transmitir datos seguros (como su contraseña de SVN).
Si es algo así como Git, svn+ssh:// será más rápido que https:// y svn:// será más rápido que http:// .
svn+ssh es el protocolo svn que se ejecuta dentro de un túnel SSH. El cliente usa SSH para iniciar sesión en el servidor remoto y ejecuta remotamente 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 subversión en un sistema distante, porque no tiene ningún servidor para iniciar en ese sistema, suponiendo que ya tiene un servidor SSH ejecutándose.
Además, svn+ssh beneficia de la protección criptográfica de SSH. No use el protocolo svn procesar en redes no confiables.
El principal problema con svn+ssh es que requiere acceso de shell en la máquina remota. Es difícil ofrecer acceso a alguien 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 (se necesita un servidor HTTP / HTTPS, por ejemplo, Apache) pero permiten que el administrador del repositorio controle con cuidado y precisión los derechos de acceso al repositorio.