2011-09-30 22 views
5

La seguridad no es un problema para nuestro pequeño equipo. ¿Hay alguna razón convincente por la que necesitemos usar algún tipo de servidor SVN, en lugar de simplemente usar archivos en un recurso compartido de red en alguna parte?SVN sin servidor para nuestro desarrollo de Visual Studio

EDITAR

Lo sentimos - no creo que me comunicaba muy bien.

Quiero usar SVN para el control de versiones. Creo que no necesita un "servidor". Los miembros del equipo pueden señalar a sus clientes SVN a una ubicación de red.

¿Es eso suficiente?

¿O necesito un "servidor"?

Respuesta

2

Sí, puede crear un repositorio en alguna carpeta y señalar a sus clientes allí, no es necesario el proceso svnserve o apache2 + mod_svn.

Hay un sin embargo, un par de razones por las que debe considerar un servidor:

  • sincronicidad: Un repositorio basado en archivos se ve alterada por los clientes que acceden a ella. Si uno de los relojes de sus clientes no está sincronizado con el resto del equipo, es posible que en casos excepcionales corrompa los datos del repositorio. Sin embargo, un servidor siempre tendrá un tiempo único.
  • Escalabilidad: cuando la cantidad de confirmaciones por día crece, la secuencia de bloqueo/confirmación/desbloqueo basada en archivos puede provocar una carga inesperada en el servidor de archivos y frustrar a su equipo con tiempos de respuesta prolongados.
  • Extensibilidad: más pronto que tarde usted o su equipo descubrirán la necesidad de un sistema de tickets (para QA/QC o soporte de 3er nivel, por ej. Trac, Redmine, Bugzilla) y luego tendrán problemas y correcciones asociadas con el control de revisión de hecho se convierte en un deber tener. Estos sistemas de tickets siempre aceptan una URL svn: //, pero lo más probable es que rechacen un repositorio basado en archivos.

No sé si estos motivos son lo suficientemente convincentes para usted, pero puede posponer la decisión de ir al servidor hasta que empiece a ser inevitable, incluso indefinidamente si su equipo no crece.

0

SVN no se trata de seguridad; se trata de mantener el historial de tu código fuente.

No puedo pensar en una razón convincente por la que no desee configurar un servidor SVN. Uso uno en casa en mi escritorio personal para mi propio desarrollo. No se trata de seguridad; se trata de mantener el historial de mi código fuente en caso de que lo arruine y quiera revertirlo.

También se trata de hábitos: "Primero hacemos nuestros hábitos, luego nuestros hábitos nos hacen". Aprende a hacerlo bien todo el tiempo, incluso en situaciones simples.

0

Imagine trabajar en el mismo proyecto con varias personas. Y ambos están modificando el mismo archivo en el mismo momento. Si ambos trabajan en ese mismo intercambio de archivos, será malo. Otra razón para utilizar algún tipo de control de fuente es poder realizar un seguimiento de los cambios. De esta manera puede notificar a su colega donde se equivocó. :-)

1

El principal objetivo de svn es el control de versiones. Usar archivos no es fácil de mantener el control de versiones. Y por cierto, es posible configurar el "servidor SVN" local en su propio PC

0

hmmm, la subversión no es la herramienta adecuada si necesita seguridad, es la herramienta adecuada:

  • si usted quiere tener un equipo que trabaja en las mismas fuentes al mismo tiempo (y puede revertir un commit incorrecto)
  • si quiere evitar que el último que guarde un archivo borre todas las modificaciones hechas por el otro (en caso de archivos) en la misma red compartida)
  • si necesita hacer un desarrollo paralelo (y crear ramas para eso)
  • si tiene que ser capaz de extraer nuevamente una versión etiquetada (útil cuando la entrega de la solicitud)
0

Configuración de un servidor es casi trivial, por lo que sería preguntar por qué no le gustaría un servidor. Pero aquí hay algunas otras razones:

  1. Fiabilidad. Los sistemas de archivos de red como SMB share no son tan confiables como , especialmente cuando se trata de múltiples usuarios que escriben en los mismos archivos al mismo tiempo. SVN específicamente no afirma apoyar esto.
  2. Rendimiento.Proporcionar acceso a los archivos a través de un servidor será significativamente más rápido que hacerlo a través de la red compartir.
  3. Auditoría. Desea que sus cambios estén asociados con un usuario, incluso si no le importa la seguridad. Pasar por un servidor obliga a iniciar sesión y el servidor puede usar ese nombre de usuario para registrar quién realizó el cambio.
  4. Seguridad. Si usa un recurso compartido de red, todos los usuarios tienen acceso directo de lectura/escritura a los archivos del repositorio. Sé que no le preocupa la seguridad, pero ¿qué hay de los errores simples? Como alguien borrando accidentalmente archivos del repositorio.

Descargue e instale algo como Subversion Edge. Esto es trivial de instalar en Windows y le da una interfaz de usuario web para administrar el servidor. También obtienes una IU web para buscar repositorios que pueden ser útiles al investigar un error.

0

En un equipo de tan solo dos personas, algún tipo de control de versión es una gran ventaja sobre ningún control de versión. Ser capaz de realizar un seguimiento de los cambios, el código de sucursal si necesita múltiples versiones para fines de demostración y el uso de bloquear/desbloquear + fusionar para evitar que los desarrolladores asesinen el código de los demás es la razón por la que utiliza SVN. También es útil cuando se trabaja solo en un proyecto.

Puede alojar SVN fácilmente en Linux, Mac, Windows; solo necesita que la máquina pueda conectarse a la red desde las máquinas de desarrollo.

0

Usted necesita un proceso de servidor SVN ejecutándose en algún lado. No puedes evitarlo. Es una parte fundamental de SVN, es lo que proporciona acceso a su repositorio, y es a lo que los clientes deben apuntar.

Utilizamos VisualSVN. No requiere casi ningún esfuerzo instalarlo.

1

Subversion utiliza tres protocolos principales:

  • svn:
  • http:
  • file:

Hay algunos otros (SVN + ssh y https), pero que están relacionados con lo anterior.

Si usa el protocolo file:, no necesita un servidor Subversion. Todo lo que tiene que hacer es apuntar con el protocolo de archivo en el directorio donde el depósito de la subversión vive:

C> svnadmin create C:\svnrepos\myrepos 

C> cd C:\workspace 
C> svn co file://C:/svnrepos/myrepos repos 

En lo anterior, he creado un repositorio de Subversion en C:\svnrepos\myrepos y luego fui a otro directorio y lo hizo (muy importante!) un pago y envío Ningún servidor se está ejecutando.

Hay varios problemas con esto: directorio del repositorio

  • La subversión se debe leer/escribir accesible a cada uno lo que significa que cualquiera puede modificar directamente el repositorio sin pasar por la subversión.
  • No estoy 100% seguro de cómo funcionan los ganchos o cómo se manejan las colisiones si más de un usuario intenta comprometerse al mismo tiempo.
  • Incluso si no planea tener ningún tipo de seguridad, es probable que desee saber el nombre de la persona que realizó el cambio. El protocolo file:// no rastrea eso. Todo lo que ves es que se hicieron cambios, pero no por quién.

Y, por último:

  • Ejecutar un servidor no es tan difícil.

Por lo tanto, si bien se puede poner el depósito de la subversión en un recurso compartido de red y todo el mundo puede utilizar el protocolo file://, en realidad no es una muy buena razón para hacerlo. De hecho, utilizo Subversion como mi propio repositorio personal, donde soy el único que lo usa, y no uso el protocolo file://.

Puede ejecutar fácilmente svnserve como un servicio de Windows, por lo que se inicia automáticamente cada vez que se inicia la máquina. Y, es muy simple de configurar. Simplemente no hay razón para no usarlo.

Por lo tanto, podría seguir adelante y hacerlo derecho modo de todos modos.

Por cierto, ¿cómo está utilizando Subversion a través de Visual Studio? Le sugiero que consulte ankhsvn, que le permite acceder a Subversion directamente en Visual Studio.

+0

Creo que verá al usuario, incluso si el protocolo es 'archivo'. Se toma de la máquina en la que el usuario está trabajando.Tengo algunos repositorios SVN localmente, y hay un autor con todos los commits. Pero el resto de tu respuesta es (en mi opinión) correcta. – mliebelt

3

Agent SVN es un plug-in para Visual Studio Subversion y se pueden configurar para utilizar una ubicación de archivos para el repositorio y como se requiere ningún servidor tales.

Cuestiones relacionadas