Control de versiones basado en almacenamiento portátil?

9

Desarrollo proyectos personales en dos máquinas sin el uso de un servidor compartido o una conexión de red entre los dos.

¿Algún sistema de control de versiones común admite de manera confiable el uso de almacenamiento portátil (como un dispositivo flash USB) como depósito compartido?

version-control

— billpg
fuente

¿Por qué quieres / necesitas usar almacenamiento portátil?

— Bernard

Para mover código entre dos máquinas de la misma manera que lo hace un sistema de control de versiones normal con un servidor compartido. (No tengo un servidor compartido.)

— billpg

Solía usar un conjunto de repositorios mercuriales en una unidad flash USB para actualizar las herramientas de fabricación en la fábrica y funcionó muy bien. Incluso podría ver cuándo los técnicos en el sitio habían estado modificando el código en la máquina local, mientras estaba fuera, y fusionar (o rechazar) sus cambios antes de sincronizarlos nuevamente en la unidad flash.

— Mark Booth

Ya se ha dicho aquí que SVN admite almacenamiento local y puede usar usb. Pero prefiero almacenar su DB en mi carpeta privada de DropBox;) También puede usar muchos servicios gratuitos (como assembla o tfs.visualstudio.com)

— Pavel Voronin

31

Use un DVCS como Git o Mercurial .

Los sistemas de control de versiones distribuidos no tienen un servidor central compartido.

Con un DVCS, cada copia de un repositorio contiene el historial completo, todo. Esto significa que, cuando se usa en una llave USB, cualquier cambio que realice se realiza en el repositorio de la llave USB y cuando se mueve entre computadoras conservará este historial.

— Oded
fuente

99

Y si usaras github, ni siquiera tendrías que llevar una unidad USB

— CamelBlues

Gracias. ¿Se puede configurar para usar un almacenamiento portátil como repositorio?

— billpg

@billpg: sí. Simplemente vive en una estructura de directorio.

— Oded

@CamelBlues o bitbucket o kilnhg o probablemente varios otros que pueden o no ser apropiados ...

— Murph

3

Tengo mis principales repositorios personales de Mercurial en DropBox. Funciona muy bien e implementa automáticamente la copia de seguridad (dado que es poco probable que DropBox desaparezca al mismo tiempo que pierdo todas mis computadoras).

— David Thornley

7

Además de GIT, Mercurial, etc. sugerido anteriormente, también eche un vistazo a Fossil: tiene las ventajas de que los binarios de tiempo de ejecución son pequeños (1 Meg más o menos para Windows y Linux), portátiles y cero instalación necesaria. Por lo tanto, a diferencia de los demás (hasta donde yo sé), se puede colocar en el dispositivo de almacenamiento y ejecutar en cualquier máquina en la que esté conectado el almacenamiento, sin tener que instalar primero la aplicación en la máquina. Incluye un Wiki y un sistema de seguimiento de cambios / defectos con el repositorio. También tiene una interfaz gráfica de usuario incorporada.

No lo he usado en serio (principalmente uso GIT), pero me impresionó su enfoque liviano y la inclusión de un Wiki y un rastreador de defectos lo hacen ideal para proyectos pequeños. Mi única preocupación era que algunas de las características más poderosas de GIT pueden no ser posibles, y a diferencia de GIT, la comunidad de usuarios no es tan grande que sea fácil encontrar respuestas a las preguntas.

— Mattnz
fuente

Aunque Git toma el mandamiento de Unix para hacer una cosa y hacerlo bien en serio, puede tener estas características en Git a través de extensiones como ticgit (sistema de venta de entradas) y gollum (wiki basado en repositorio).

— Jason Lewis

@Jason Lewis: Tiene razón, y como es de código abierto, puede modificarlo para cumplir con sus requisitos de todos modos, por lo que GIT (o cualquier otra herramienta) puede ser todo para cualquiera (a quien puede molestar, tiene el tiempo libre y los recursos) para descargar, instalar y depurar todos los "complementos". Todo lo que estaba diciendo es para una solución que "Simplemente funciona", vale la pena considerar Fossil.

— mattnz

1

Usar un DCVS es probablemente una buena idea, pero no es la única opción.

Tengo un pequeño repositorio CVS en una memoria USB. Cuando quiero acceder a él, solo necesito usar cvs -d <path>o establecer $CVSROOTla ruta de la raíz del repositorio (que por supuesto requiere que la unidad de memoria USB esté montada en el sistema).

Si ya está acostumbrado a usar CVS, esto debería ser viable. Lo mismo debería aplicarse a SVN. Simplemente significa que su repositorio central está en la memoria USB y no siempre es visible.

Hay argumentos para usar un DCVS en lugar de un CVS en general. No creo que esos argumentos se vean particularmente afectados por si el repositorio central está en una memoria USB o en otro lugar. Por ejemplo, podría crear fácilmente un repositorio git en la memoria USB.

— Keith Thompson
fuente

1

Normalmente no soy un gran admirador de DVCS, pero creo que DVCS sería mejor en este caso. El problema con VCS no distribuido es que el repositorio es un único punto de falla. Si se encuentra en un centro de datos con clima controlado y se realiza una copia de seguridad con regularidad, eso no es un gran problema, pero algo como una memoria USB se perderá (o pisará, o será comido por un perro, o caerá en un ruso blanco) antes. o después.

— Mike Baranczak

1

@MikeBaranczak: Buen punto, pero se debe hacer una copia de seguridad de todo lo que se encuentre en una memoria USB , ya sea un repositorio CVS o no.

— Keith Thompson el

Con un sistema distribuido, cada cliente ya tiene una copia completa del repositorio. Por lo tanto, no hay razón para un procedimiento de "copia de seguridad" por separado.

— Mike Baranczak

1

@MikeBaranczak: Claro, esa es una buena razón para usar un DCVS. Mi punto es que la elección de un DCVS frente a un sistema centralizado no depende de si está utilizando una memoria USB o no.

— Keith Thompson el

0

Como una adición a las otras respuestas:

Si bien un DVCS se adapta muy bien a este problema, técnicamente también podría usar Subversion, si se siente más cómodo con él. Subversion puede usar un directorio local en lugar de un servidor central. Podrías poner eso en una memoria USB y usarlo.

La desventaja, en comparación con un DVCS, sería que solo puede trabajar con Subversion (es decir, confirmar, ver registros, etc.) mientras la memoria USB está conectada. Además, siempre debe ser la misma memoria USB (o al menos una -to-date copy), porque con Subversion no debe usar más de un repositorio (esa es la parte no distribuida). Entonces, si alguna vez olvida su memoria USB, no puede usarla, a diferencia de Git o Mercurial.

Nota:

Como se explicó anteriormente, y en los comentarios, un DVCS es realmente mejor para su problema. Solo mencioné Subversion por completo, y en caso de que tenga alguna razón especial para usar Subversion.

— sleske
fuente

1

Al igual que con la respuesta de Keith , el problema con un VCS en un directorio local es que es un punto único de falla. Además, si se mueve de la máquina A a la máquina B pero deja la unidad de memoria USB conectada a la máquina A, es mucho menos probable que le importe si está utilizando un DVCS (siempre puede combinar sus cambios locales más adelante) mientras que con un VCS , tendría que volver a la máquina A, obtener el disco y volver a la máquina B antes de poder continuar.

— Mark Booth

@ MarkBooth: no estoy abogando por esta solución, solo quería señalar que existe, por razones de integridad y en caso de que OP tenga algunas preferencias especiales para Subversion. Edité mi respuesta para aclarar esto.

— sleske

Gracias @sleske, estoy de acuerdo en que una preferencia por svn(o incluso Cvs) podría pesar a favor de usar esa solución, pero en aras de una divulgación completa, también deberían mencionarse las desventajas de ese enfoque. Siéntase libre de editar los puntos de mi comentario en su respuesta. Si lo hace, me complacería limpiar (eliminar) mis comentarios. * 8 ')

— Mark Booth

No estoy seguro de qué agrega esta respuesta que ya no dije en la mía.

— Keith Thompson el

1

@KeithThompson: agrega la información de que SVN puede usar un directorio local en lugar de un servidor central. Eso se explica en los documentos de SVN, pero dado que la mayoría de las personas usan SVN a través de un servidor central, puede que no sea obvio que SVN no requiere un servidor.

— sleske