rendimiento del protocolo de Subversion

Question

Estoy empezando/familiarizado con Subversion y me preguntaba qué protocolo proporciona el mejor archivo de rendimiento: // o svn: //, al acceder a un repositorio de Subversion a través de la red? Si no usamos el protocolo svn: //, estaremos perdiendo alguna característica que no podamos mitigar usando el protocolo file: //? Todos estamos en el mismo dominio NT &, planeamos usar Windows Auth y usamos la seguridad NTFS/UNC.

TIA!

Answer 1

El libro SVN recomienda que no utilizan el protocolo file: // para múltiples usuarios

Choosing a Server Configuration:

No se deje seducir por la simple idea de tener todos sus usuarios acceda a un repositorio directamente a través de file: // URLs. Incluso si el repositorio está disponible para todos a través de una red compartida, esta es una mala idea. Elimina cualquier capa de protección entre los usuarios y el repositorio: los usuarios pueden dañar accidentalmente (o intencionalmente) la base de datos del repositorio, se vuelve difícil desconectar el repositorio para su inspección o actualización, y puede ocasionar problemas de permisos de archivos (vea la sección llamada "Soporte de Múltiples Métodos de Acceso al Repositorio"). Tenga en cuenta que esta es también una de las razones por las que advertimos contra el acceso a repositorios a través de svn + ssh: // URLs desde un punto de vista de seguridad, es efectivamente lo mismo que usuarios locales accediendo a través de file: //, y puede presentar todos los mismos problemas si el administrador no tiene cuidado

Answer 2

Si desea usar la autenticación de Windows, use el protocolo http (s), junto con apache. Es un poco más difícil de configurar, y no necesariamente más rápido, pero le permite usar métodos de autenticación de apache estándar para la autenticación. Incluyendo varios esquemas de autenticación basados ​​en Windows o kerberos.

BTW. Normalmente, la velocidad del protocolo no es un factor con la velocidad de svn. Svn almacena en caché la información en el disco, por lo que la mayoría de las acciones regulares se basan en la memoria caché local. A continuación, el factor de velocidad está en el repositorio y la banda de la red, no en el protocolo.

Answer 3

Como afirma Paul de Vrieze, el protocolo utilizado por SVN no afectará el rendimiento tanto como otros factores. Si se encuentra en una pequeña red de área local, entonces el protocolo SVN puede ser satisfactorio para usted. En todos los demás casos, parece ser mejor utilizar HTTPs: // con Apache. He estado en LAN donde el rendimiento de SVN: // es peor que HTTPS: // conexiones a Internet.

También encontrará que Apache es probablemente una solución más manejable también en términos de seguridad, o de visualización de repositorio SVN.

Answer 4

Un pago/actualización en svn: // es aproximadamente 4-12 veces más rápido que en http (s): //. El factor depende de la cantidad de archivos/carpetas y el tamaño del archivo. Apache es mucho más lento en muchos archivos pequeños porque cada archivo es un ciclo completo de solicitud-respuesta http. En Tortoise puede ver fácilmente la caída de velocidad:

Pagar un gran proyecto java Si transfiere un enorme .jar, la transferencia está subiendo, al obtener archivos Java fuente y crear la estructura del paquete, se caerá.

También es importante que svn checkout es más lento en el cliente de SVN exportación y Eclipse (Java) es mucho más lento que la tortuga/CMD.

Answer 5

Estoy de acuerdo con los demás que svn: // es mucho más rápido que http: //.Dicho esto, uso http: // en mis repositorios porque me gusta el archivo de control de acceso de mod_authz_svn y aún no me he actualizado a 1.5.

Como mi repositorio principal es enorme, mantenemos el svn: // ejecutándose como de solo lectura. Lo que sugiero a los usuarios es hacer su pago inicial como svn: // y luego usar svn relocate para convertirlo a http: // url para confirmar. Las actualizaciones en svn: // se ejecutan en un tiempo aceptable para nosotros.