Hay cuatro protocolos comunes para el acceso a la red de SVN.¿Qué protocolo? svn: // o http (s): //?
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"?
http:// tiene una sobrecarga de , especialmente cuando se trata de miles de archivos pequeños. Utilicé svn para un sitio web que tenía alrededor de 50,000 iconos, todo guardado en SVN. Con HTTP, tomó alrededor de 20 minutos para finalizar la compra. 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: por lo general pasa a través de cortafuegos. Por ejemplo, ahora que cambié al svn:// ya no puedo acceder a mi repositorio desde mi universidad debido a su firewall.
En cuanto 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.
https:// y svn+ssh:// están encriptados y por lo tanto son más seguros para la transmisión segura de datos (como la contraseña de subversion.
Si es algo como Git, svn+ssh:// será más rápido que https:// y svn:// será más rápido que http://.
No sé mucho sobre svn + ssh. ¿Qué tipo de soporte requiere eso en el servidor? ¿Debe tener una cuenta ssh que tenga un shell en el servidor? ¿Sin acceso anónimo? – Earlz
SVN + SSH es básicamente lo mismo que svn: //, solo que lo está realizando a través de un túnel SSH. Esta no es una opción que le gustaría seguir si el acceso anónimo es importante para usted. –
@earlz: Necesita algún tipo de cuenta con el acceso al repositorio del sistema de archivos y el permiso para ejecutar 'svn' (¿o tal vez algún otro binario?). – Thomas
http y https se manejan mediante un módulo de servidor web para soporte de Subversion, por lo que puede usar la autenticación basada en HTTP (configurada a través de .htaccess) para limitar el acceso a su repositorio).
Bueno, también puedes tener autenticación con svnserve. Simplemente se hace de una manera ligeramente diferente. –
Sí, y si tiene 100 repositorios para un mismo grupo de desarrolladores, debe transferir el archivo de configuración a cualquier repositorio.De esta manera, puede tener solo un archivo que le permita acceder, y cada cambio en él controlará el acceso a cualquier repositorio. – Vestel
Puede obtener el mismo efecto con svmserve + symlinks. Además, crear varios repositorios para el mismo grupo de desarrolladores no tiene sentido y no se recomienda desde el libro svn oficial. –
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 se beneficia de la protección criptográfica de SSH. No utilice el protocolo svn sin formato 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 al administrador del repositorio controlar con cuidado y precisión los derechos de acceso al repositorio.
Con svn + ssh, es fácil restringir el acceso a svn. –
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.
Así que sus (ventanas) desarrolladores sólo tienen que recordar un usuario/contraseña
Se podría decir que svn:// o svn+ssh:// proporcionan mucho mejor rendimiento y la velocidad de HTTP plano o asegurar HTTPS acceder a los 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 era con SVN 1.6 o versiones anteriores.
No hay no mayores problemas de rendimiento con HTTP (S) y Subversion 1.7+ clientes y servidores actualizados.
HTTP (S) de acceso con Subversion 1.7 became much more performant and especially on high-latency network connections thanks to HTTPv2(no confunda con HTTP/2!). Subversion 1.8 switched from libneon to libserf for HTTP(S) access 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 trabajando sobre 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!
Al pensar en un ejemplo de configuración errónea 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 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 StackOverflow para obtener más información: https://stackoverflow.com/a/38499619/761095.
Otra ventaja de los http (s): // es que cumple con el estándar WebDAV. Lo que significa que puede montar dichos repositorios en, por ejemplo, explorador u otros clientes WebDAV. Ver http://svnbook.red-bean.com/nightly/en/svn.webdav.html – Stefan
Svn se está alejando de la norma WebDAV partir de v1.7 debido a la enorme sobrecarga generada y la falta de clientes WebDAV. – whitey04
Votación abajo porque esta respuesta ya no es actual. SVN 1.7 y posteriores mejoran mucho el uso de HTTP (S) y la diferencia entre la velocidad de 'svnserve' y HTTP (S) sobre Apache no es tan grande. – bahrep