¿Podemos configurar el servidor svn en una computadora local sin acceso a la red?

Quiero configurar un repositorio SVN en mi computadora sin ningún acceso a la red. Estoy trabajando en un código sin ningún colaborador, por lo que no quiero que esté disponible públicamente.

Leí esta publicación , pero sugiere el uso de servicios de repositorio SVN en línea que proporcionan repositorios gratuitos. En ese caso, mi código estará disponible públicamente (como se incluye en los términos de los planes gratuitos).

Entonces, me preguntaba si puedo configurar un servidor local en mi máquina con Windows XP al que solo accedo, incluso cuando no tengo conexión a Internet.

La forma más fácil de configurar un servidor local es usar svnserve :

Subversion incluye Svnserve, un servidor independiente liviano que utiliza un protocolo personalizado sobre una conexión TCP / IP normal. Es ideal para instalaciones más pequeñas o donde no se puede usar un servidor Apache completo.

Sin embargo, en realidad no necesita un servidor de subversión, si todo lo que desea hacer es acceder al repositorio localmente, ya que puede acceder a un repositorio de subversión a través de una URL de archivo, como se describe en esta respuesta :

Puede acceder al repositorio utilizando el protocolo file: //, por lo que solo necesitará Tortoise SVN instalado y nada más. Vea esta pregunta en Preguntas frecuentes: ¿Es posible usar TortoiseSVN sin un servidor?

Incluso puede tener el repositorio en el dispositivo usb para que pueda llevar la fuente consigo y trabajar desde otras computadoras.

Si está utilizando TortoiseSVN , puede encontrar instrucciones en Creación del repositorio con TortoiseSVN :

1. Abre el explorador de windows

2. Cree una nueva carpeta y asígnele un nombre, por ejemplo, SVNRepository

3. Haga clic derecho en la carpeta recién creada y seleccione TortoiseSVN → Crear repositorio aquí ...

Inmediatamente arriba en esta página también describe cómo crear un repositorio desde la línea de comandos .

Dicho esto, te recomendaría que eches un vistazo a Mercurial o Git como alternativa svn. Si está familiarizado con TortoiseSvn, encontrará que TortoiseHg y TortoiseGit son una transición fácil, además le brinda la flexibilidad de trabajar de forma distribuida más tarde si es necesario. Por ejemplo, en el pasado he usado tarjetas de memoria para transferir hgrepositorios entre máquinas sin acceso a la red, y cuando trabajas de esta manera obtienes una copia de seguridad gratuita.

El servidor más simple (y más rápido), que puede usar para trabajar con el repositorio local, incrustado en cada cliente svn . Este es un servidor para acceder a cualquier repositorio y cualquier cantidad de repositorios , existentes en el sistema de archivos local, utilizando el archivo de protocolo: ///. No proporciona ningún método de autorización o autenticación, solo otorga acceso ilimitado completo al repositorio bajo control, pero, por otro lado, permite usar y ofrece todas las características del sistema VCS per se.

Para usar este servidor, tiene en cualquier directorio vacío en cualquier ubicación, llame al comando CLI svnadmin con el subcomando y los parámetros correspondientes (no recuerdo, ¿hay programas administrativos en el paquete CLI-client o no y no puedo? compruébelo: no he instalado CLI svn-client, solo TortoiseSVN, que tiene estos programas en el instalador en la versión 1.7). Espero que pueda encontrarlo.

svnadmin helpmuéstranos todos los subcomandos disponibles, ahora estamos interesados ​​en el subcomando create.

svnadmin help create proporcione todos los detalles necesarios para nosotros

create: usage: svnadmin create REPOS_PATH

Create a new, empty repository at REPOS_PATH.

Valid options:
...

En el punto de partida para el primer repositorio podemos ignorar todas las opciones de ajuste fino y recordar solo la forma principal svnadmin create REPOS_PATH, allí REPOS_PATH es la ruta absoluta o relativa al directorio vacío, planificado para el repositorio. Debido a que la mayoría de las personas comunes de Windows para aplicaciones multiplataforma pueden confundirse las personas, qué notación (barras diagonales hacia adelante o hacia atrás) usar en la ruta (metoo), la forma más segura es la cdubicación, desde la cual nuestro directorio es visible sin una ruta larga - padre del futuro repo-directorio o el directorio en sí. Para planeado para repo z:\Main antes svnadmin create

Z:
cd \Main

y por ultimo,

svnadmin create .

Como resultado, se crea un repositorio vacío en el directorio, que se muestra en el Explorador de Windows con un icono especial como indicador de contenido

Ahora, cada vez que se necesita este repositorio , usamos comandos SVN habituales, la parte URL o los parámetros parecen serfile:///Z:/Main

c:\>svn ls file:///Z:/Main
branches/
tags/
trunk/

(Agregué el árbol de repositorio estándar en el repositorio).

Analicemos esta URL extraña:

• file:///, como para cualquier URL, significa protocolo de acceso, en nuestro caso el protocolo es especial y tiene tres, no dos barras
• Z:/Main es la ruta completa al repositorio con la unidad y la ruta dentro de la unidad, todas las barras diagonales inversas de Windows reemplazadas por barras diagonales "clásicas"

Desde cualquier otro punto, este repositorio no tiene ninguna diferencia con "Big Brothers" con servidores especiales de Subversion

Probemos una respuesta que recomiende soluciones genéricas en lugar de específicas.

En primer lugar, sí, puede usar Subversion en una computadora independiente: puede instalar el servidor localmente o puede trabajar con el archivo: //

Pero a menos que haya una muy buena razón por la que tenga que usar Subversion, sugeriría que esta no es la mejor solución para el problema del control de versiones local, sobre todo porque falla una de las cosas que considero esenciales, es decir, asegurarse de que el código fuente está en al menos dos lugares (sí, incluso para cosas personales). Por lo tanto, sugeriría el uso de un Sistema de control de versiones distribuido (DVCS).

Uno de los beneficios de DVCS es que, una vez que se instalan las herramientas, los repositorios son autónomos dentro de una carpeta y puede sincronizar el contenido entre diferentes carpetas que contienen el "mismo" repositorio siempre que tenga acceso a nivel de archivo. También tiene la opción de hablar con las versiones de "servidor" de esos repositorios (que están alojados de forma privada o que están disponibles como servicio). Esto hace la vida mucho más fácil ejecutar todo localmente.

También hay otras ventajas para DVCS.

Como ya señalé, no creo que realmente tenga una solución VCS adecuada hasta que su código esté en al menos dos máquinas (específicamente dos discos duros distintos e idealmente en más de una ubicación, aunque clone y presione para decir memoria USB o El almacenamiento "en la nube" (skydrive, dropbox, et al) es otra forma que también debería funcionar).

En términos de qué DVCS, vería Mercurial (Hg) y Git y también Veracity . Uso Mercurial porque todavía es más agradable en Windows ...

Si usted considera los servicios alojados, estoy de acuerdo en que hay mucho que elogiar github, pero también hay muchas cosas buenas sobre Bitbucket y Fogbugz / Kiln ... y lo mismo probablemente sea cierto para muchos otros servicios que no he enumerado (por ejemplo, http://beanstalkapp.com/ que se mencionó al pasarme a Twitter hoy)

Subversion no requiere un servidor. Utiliza un repositorio centralizado, pero se puede acceder a este repositorio a través del método de acceso 'archivo', lo que significa que simplemente necesita acceder al sistema de archivos en el que está almacenado el repositorio. La forma más fácil de configurar esto sería crear una carpeta en algún lugar de su disco duro, apuntar TortoiseSVN (o una herramienta similar) y 'crear repositorio aquí'. A partir de ahí, puede hacer lo que sea necesario para obtener su código en el repositorio.

Sin embargo, a la larga, probablemente sea mejor usar un SCM distribuido, los mejores candidatos son git (más potente, curva de aprendizaje empinada, funciona mejor en * nix) y mercurial (un poco menos potente, fácil de aprender, funciona igual) bien en windows y * nix). Con estos, su copia de trabajo contiene todo el repositorio, y puede hacer tantos clones (remotos o locales) como desee. Puede comenzar localmente, y si decide alojar el repositorio externamente, simplemente clone su repositorio local existente en la ubicación externa, y puede sincronizar en ambas direcciones en cualquier momento. Mejor aún, debido a que cada uno de sus clones contiene el historial completo del proyecto, el SCM también funciona como un sistema de respaldo. Con Subversion, si su servidor muere y no ha hecho una copia de seguridad, su historial se ha ido, con git,

http://hginit.com/ tiene un excelente tutorial sobre cómo comenzar con mercurial.

Hay bastantes empresas de alojamiento SVN que ofrecen una cuenta gratuita para uno o dos desarrolladores y no requieren que su código sea público. Consulte la tabla vinculada para ver la tarifa de $ 0, OSS requerido = NO. Cuento nueve proveedores que cumplen con esos criterios en este momento.

Si bien puede alojar su propio repositorio muy fácilmente, existen algunos beneficios que vienen con el uso de un proveedor:

• Puede acceder a su código desde cualquier lugar sin configuración adicional.

• Mantener su código fuera del sitio lo protege de fallas del disco duro, incendios, etc.

• Bajos gastos administrativos.