La elección de una subversión del servidor

Question

Después de elegir Apache Subversion para mis necesidades de control de versiones (y AnkhSVN/TortoiseSVN para mis clientes de Subversion primarias). Ahora estoy tratando de elegir el servidor SVN para proporcionar acceso remoto a los repositorios SVN. He mirado un par de ellos:

• CollabNet Subversion Edge
• VisualSVN Server

He instalado cada uno en una máquina virtual para probarlos, pero no han encontrado suficiente para diferenciar la mayoría de ellos lo suficiente como para elige cualquier específico. Ahora tengo algunas cosas que necesito decidir.

1. protocolo
2. proveedor
3. SSL

1. He leído que HTTP es mucho más lenta que el protocolo SVN. Aunque mis proyectos generalmente no son demasiado grandes (realmente solo la importación inicial es la parte que consume mucho tiempo), quiero obtener los beneficios de rendimiento de SVN, así como evitar que mis registros HTTP se inunden con las entradas SVN (que hasta ahora no han podido segregar en un archivo SEP seprate).

Sin embargo, me gusta la interfaz web que ofrece el uso de un módulo Apache o VisualSVN. Realmente no necesito proporcionar mis cosas a otros (o incluso a mí mismo fuera de mi sistema), por lo que no es crítico, pero ciertamente permite la capacidad de expansión.

2. Después de elegir un protocolo (suponiendo que tengo a elegir); Necesito ayuda para decidir qué proveedor usar. Originalmente utilicé el módulo Apache de la distro Tigris. Desde entonces eliminé eso (bueno, simplemente lo deshabilité), y actualmente estoy usando VisualSVN (que es HTTP y, por lo tanto, lento). He visto personas respaldar Sharp y Silk, pero parecen ser más pequeñas e independientes.
Collabnet, por otro lado, parece ser más elaborado de lo que necesito. Básicamente, a menos que pueda convencerme de uno de ellos, principalmente estoy tratando de elegir entre el Tigris oficial y el VisualSVN.

3. También he intentado meterme con SSL sin mucho éxito (no puedo pagar una CA real, así que estoy usando un certificado autofirmado en VisualSVN). Me encantaría usar SVN + SSH/HTTPS, pero si lo estoy usando en mi propio sistema, entonces no es necesario, y si lo uso externamente, entonces mi certificado autofirmado no ayudará.

Supongo que podría incluso usar un repositorio local; Yo pensaría que sería el más rápido. Sin embargo, preferiría una solución más formal en caso de que me expanda. (Yo consideraba simplemente utilizando el cliente TortiseSVN para hacer el trabajo del servidor local.)

Así que en resumen, necesito algunos consejos sobre qué servidor (s ?) Para su uso.Lo que sería genial es si pudiera conseguir que VisualSVN proporcionara una interfaz HTTP para uso web, pero también sirviera en un protocolo SVN para usar en los clientes, preferiblemente con la opción de SSL en cada uno. ¿Es eso posible? ¿Sería demasiado trabajo (realmente quiero volver a trabajar en mis proyectos en lugar de todo este meta trabajo).

Muchas gracias.

Editar

pensé que debería dar un poco de información sobre mis circunstancias para aclarar las cosas.

• (Ahora) del sistema individual, (P4 mayor, Ventanas, 1 GB de SDRAM)
• (Ahora) elaborador (ME)
• (Ahora) proyectos relativamente pequeños (< 2MB)
• proyectos Innumerables (> 100 aplicaciones individuales, juegos, bibliotecas, sitios web, etc.)
• Externos necesarios (específicamente mi propia biblioteca, así como el encabezado de terceros, Boost, etc.)
• ? hmm, ¿qué otra cosa ...

Answer 1

Editar: Después de leer las respuestas aquí, hay una cosa que pensé que debería mencionar. Si prueba un servidor, los repositorios a los que le pida que sirvan no serán diferentes de los repositorios a los que les pida que sirvan otro tipo de servidor.

En otras palabras, si decide probar un servidor ahora, puede cambiar a otro tipo de servidor más adelante, sin perder sus repositorios. Por supuesto, las copias de trabajo y cualquier referencia externa absoluta que hayas realizado en tus proyectos, tendrán que cambiar, pero puedes mantener tus repositorios con historial y todo.

---

He instalado VisualSVN Server cuando se anunció, y estaba bastante contento con él, por un tiempo.

Sin embargo, los problemas de velocidad me hicieron cambiar al servidor svnserve principal que se envía como parte del paquete de la línea de comandos de Subversion.

El problema principal, es que estoy trabajando con .NET, y elegí agregar varias referencias externas de Subversion a mis proyectos.

Primero, y más importante, cada proyecto que hago en la biblioteca de mi clase está firmado por mi clave. En segundo lugar, se agregaron bibliotecas externas de terceros, como SQLite y NUnit como referencias externas.

Cada proyecto tenía sus propias referencias externas. Hice esto para poder hacer un nuevo proyecto de aplicación, y luego hacer nuevas referencias externas a las partes de la biblioteca de mi clase que necesitaba, y para que esas referencias estén completas. Si mi solución de biblioteca de clase en .NET tuviera una referencia externa para el archivo de clave de firma, y ​​ese archivo no estuviera disponible como parte de un solo proyecto, sino que estuviera ubicado en el disco fuera de todos los proyectos, pero local para mi solución, eso no funcionó

Por lo tanto, mi solución de biblioteca de clase contiene unos 15-20 proyectos, cada uno con al menos una referencia externa a la clave de firma, todos mis proyectos de datos tienen referencias externas a la biblioteca SQLite y la biblioteca de prueba unidad con 4-5 referencias externas.

El resultado neto fue que una única actualización en el nivel de solución, incluso si ya tenía todos los archivos, directorios y todo lo último, tardó aproximadamente 2 minutos en completarse. Cada referencia externa tardó entre 10 y 20 segundos en completarse, solo para verificar que tenía la revisión que necesitaba.

Cuando cambié a svnserve, esos 2 minutos se redujeron a aproximadamente 3 segundos. Este es el tráfico local, así que por supuesto esto será diferente en internet. El problema es que esos 2 minutos también fueron tráfico local.

Así, mientras me encantó la interfaz VisualSVN servidor me proporcionó, incluyendo la capacidad de fácilmente configurar los derechos de acceso y los usuarios, la velocidad a la que el módulo de servidor Apache me proporcionó era absolutamente horrible en comparación con lo que svnserve y el protocolo nativo de Subversion sí lo hace.

Tenga en cuenta que desde entonces he instalado un servidor Apache separado, vadeé muchos archivos de configuración y configuré Subversion con Apache a través del servidor VisualSVN, solo para asegurarme de que no era solo VisualSVN, y confirmó que la velocidad que observé no era el trabajo del equipo de VisualSVN. Parece que el protocolo HTTP o los módulos de Apache simplemente no son tan rápidos.

Mi consejo es ir con el servidor svnserve principal, si es posible. Puede tomar algún trabajo conocer los archivos de configuración para la autorización y los "me gusta", pero el factor de irritación solo (es decir, sin irritación sobre la velocidad en absoluto) será más que probable que supere eso.

Answer 2

Estoy usando CollabNet en casa y en el trabajo. Ha estado bien, no tengo quejas con el rendimiento.

Answer 3

Re velocidad de acceso: He visto un servidor Apache https: SVN que necesita una actualización de hardware. Me parece recordar que fue principalmente la falta de memoria lo que ralentizó los numerosos procesos Apache que competían por los recursos de la máquina. Pero eso fue 20 desarrolladores que colaboraron en un proyecto con un árbol desprotegido de 20 GB (muchos binarios, que a menudo cambiaron). Y la actualización a un servidor moderadamente equipado resolvió el problema.

Además, en ese mismo proyecto, tuve que aprender que SVN en un ext3 FS bajo Linux era por lo menos un orden de magnitud más rápido que en NTFS bajo Windows. Marque eso: El Linux en una máquina virtual que se ejecuta en Windows tomó una décima parte del tiempo para una actualización que compite con la caja de Windows que la VM ejecutó en. (Siempre quisimos probar ese controlador ext3 de SO para Windows y ver si esto no haría que SVN fuera más rápido en Windows que su FS nativo. Sin embargo, abandoné el proyecto antes de intentarlo.)

De todas formas, no es como lo que usted decide, está echado en piedra por la eternidad. Puede probar una cosa, probarla exhaustivamente en un proyecto real y cambiar a un servidor y protocolo diferente más tarde. (Incluso hay un comando de SVN para cambiar la URL de un desprotegido árbol Esto se puede utilizar para cambiar el protocolo sin tener que revisar todo de nuevo..)

Esto es lo que yo consideraría que decidir sobre el protocolo: Si si tiene una infraestructura AD o LDAP que le gustaría aprovechar para iniciar sesión en SVN, intente con una de las opciones de protocolo http/https:. Si no tiene esto, y no lo necesitará, y está bien haciendo login por los propios medios de SVN, ¿por qué no usar la velocidad proporcionada por el protocolo svn:?

Nunca he visto un repositorio SVN al que la gente haya usado el acceso WebDAV. IME siempre quieren tener el historial al acceder por web (WebDAV no proporciona esto, AFAIK), por lo que utilizaron una de las interfaces web para SVN.Nunca lo he comprobado, pero asumo que cosas como ViewVC y similares no me importan qué protocolo usan para acceder al repositorio.

En cuanto a la distribución que desea usar, creo que se debe principalmente a las preferencias personales, ya que el código de abajo es el mismo de todos modos. Prefiero descargas para las que no tengo que registrarme y distribuciones que apuntan explícitamente a la plataforma en la que quiero instalarlas. Pero probablemente sea solo yo.

Sin embargo, hay un hecho difícil que podría considerar si su repositorio es accesible desde Internet: cuando el proyecto SVN hizo una nueva versión de punto, cuánto tiempo, en el pasado, tomó las diferentes distribuciones para ponerse al día . Dado que estos pueden ser soluciones de seguridad, es posible que prefiera los que, por lo general, proporcionan las soluciones más rápido.

Answer 4

Suministramos nuestros repositorios SVN utilizando HTTP proporcionado por Apache corriendo bajo CentOS 5.3 desde el interior de una máquina virtual XEN.

Me gustaría observar que al hacer un commit o un checkout en un archivo grande, transfiere ese archivo a velocidades cercanas a la de la red. Mientras revisa o compromete una gran cantidad de archivos pequeños, la sobrecarga de las solicitudes HTTP es mucho más notoria.

En comparación con los plazos del código de compilación, SubVersion no se ve como un cuello de botella dentro de la empresa.

(Esta es mi experiencia con un equipo de 10 desarrolladores)