¿Por qué elegir mod_dav_svn en lugar de svnserve y un browser de repository?

Por favor corrígeme si me equivoco sobre mi comprensión de mod_dav_svn, que básicamente tiene dos propósitos:

  1. Exponga el repository SVN (en el sistema de files) a los clientes, que pueden ser:
    • browseres de repositorys (por ejemplo, web)
    • el command 'svn' en sí mismo, que es un progtwig de línea de command del cliente
  2. Actúe como un browser de repository para hacer que el repository se pueda ver de forma conveniente

Ahora, para el punto 1, ¿son correctas mis siguientes suposiciones?

  • Cada vez que se expone un repository usando mod_dav_svn, se utiliza la forma http: // o https: // de acceder al repository
  • Si se usa svnserve, se usa la forma svn: // de acceder al repository
    • En este caso, mod_dav_svn no serviría para uso adicional

Para el punto 2, si se usa la funcionalidad de búsqueda de repository de Trac, no hay uso adicional para la funcionalidad de búsqueda de repository que ofrece mod_dav_svn.

¿Mod_dav_svn sirve para algún otro propósito que no he esbozado aquí? Preguntado de otra manera, ¿hay alguna desventaja al ir con svnserve y Trac?

Lo pregunto porque me da la printing de que mod_dav_svn es muy común, así que me pregunto qué me falta.

Olvídese de Punto # 2: Navegación HTTP. Eso es solo una pequeña ventaja. No reemplaza su necesidad de algo como Fisheye , ViewVC o (mi favorito) Sventon .

Hay algunas desventajas de usar http de Apache para su server de Subversion:

  • Es más lento
  • Es más difícil de configurar

Entonces, hay ventajas:

  • Utiliza un puerto estándar (80) que normalmente no está bloqueado por firewalls.
  • Se puede integrar con LDAP y Active Directory
  • Puede usar HTTPS que encriptará las actualizaciones y los paros (incluidas las passwords de los usuarios).
  • Puede hacer que múltiples repositorys usen la misma instancia de Apache httpd. Con svnserve , solo puede hacer un único repository por instancia y si tiene varios repositorys en un sistema, deberá ejecutar cada process svnserve en un puerto no estándar.

Mi opinión personal: si está haciendo un entorno corporativo, las ventajas de utilizar el protocolo HTTP o HTTPS superan las desventajas. Si está hablando de un pequeño repository y usted y sus amigos, ejecuto svnserve simplemente por la menor sobrecarga y una configuration más sencilla. Sin embargo, en esas circunstancias, solo uso Github y no me preocupo por eso.

Ejecuto Subversion como mi sistema de control de fuente personal en mi máquina, y uso svnserve en esa instancia.


Gracias, algunas preguntas de seguimiento. 1) Cuando accedo a una URL en mi server svn como svn: // server / repo, ¿no es eso también usar el puerto 80? 2) Si la integración LDAP no se puede hacer para svnserve, la única forma en que los usuarios pueden autenticarse es si están en el file al que hace reference la contraseña-db en svnserve.conf para svn: // o si tienen una count shell para svn + ssh: //? 3) ¿No puede la misma protección ofrecida por https: // ser ofrecida por svn + ssh: //, o hay una diferencia? (Lo siento, no puedo poner aquí los párrafos que envía cada vez que pulso enter, lo hago bien).

  1. Está utilizando el puerto 3690 por defecto. Esto se puede cambiar cuando ejecuta svnserve , pero luego su URL svn debe reflejar eso también.

  2. Bastante cierto. La mayoría de los lugares que usan svnserve usan el file passwd. Sin embargo, desde la versión 1.5, puede usar SASL . Sin embargo, nunca he visto a nadie usarlo.

  3. Sí, ssh + svn: // ofrece packages encriptados. Sin embargo, SSH puede ser complicado de implementar. Básicamente, el process svnserve debe generarse y ejecutarse para ese usuario en particular. Eso significa que cada usuario necesita acceso directo de lectura / escritura al repository. Necesita configurar umask para cada usuario y crear un grupo Subversion Unix al que todos pertenezcan. Luego, dado que estos usuarios tienen acceso directo a los files del repository, evite que inicien session en el server del repository. El Manual en línea tiene detalles completos. Pero, al final, solo funciona en serveres Unix y clientes Unix. Los clientes de Windows no tienen SSH en ellos, y tendrían que instalar eso. Lo intenté varias veces, pero https: // es mucho más fácil.

La simplicidad de svnserve lo convierte en un pan comido para instalaciones rápidas y sucias, especialmente si se está implementando en Windows.

Sin embargo, en el momento en que necesite memorizar muchas passwords y desee que el repository de Subversion use el mismo mecanismo de SSO que se usa en la organización, usar los mecanismos de authentication de Apache junto con mod_dav_svn ayuda mucho.

Antes de Subversion 1.7, se decía que el performance de mod_dav_svn era atroz y se sabía que era más lento que svnserve. Subversion 1.7 supuestamente ofrece un protocolo HTTP más rápido y simple que debería hacer que el mod_dav_svn sea más aceptable.