Mercurial (y supongo que Git) con Dropbox: ¿algún inconveniente?

Question

Tengo un repositorio de Mercurial para un proyecto personal, y he estado almacenando el repositorio principal en mi Dropbox durante unas semanas (algo a lo largo de this line, y entiendo que también es possible with git).

La idea es que sirve como una forma de trabajar con varias máquinas y como una copia de seguridad remota. Yo clono el repositorio y trabajo en la copia que no es de Dropbox, y solo envío actualizaciones de vez en cuando, de la misma manera que, supongo, funcionaría con Bitbucket.

¿Puede pensar en los inconvenientes de esta idea, en comparación con el uso de hosting dedicado (BitBucket en el caso de Mercurial)? Sé que Bitbucket tiene cuentas gratuitas para usuarios únicos, lo cual es genial, pero están limitados a 150M, que no es un gran.

En particular, ¿es posible que el proceso de sincronización de Dropbox corrompa el repositorio? Tuve que ejecutar hg recuperar una vez en el repositorio principal, pero podría no estar relacionado (y de todos modos se recuperó felizmente). ¿Alguien tiene una mala experiencia con la idea? ¿Alguien tiene una buena experiencia más larga y puede aliviar mis preocupaciones? ¿Alguien tiene una opinión basada en una mejor comprensión de los aspectos internos de estas cosas?

editar: He añadido algunas aclaraciones a las preguntas. Están en en cursiva.

Answer 1

Aconsejaría que no por las razones mencionadas anteriormente, pero más enérgicamente declarado. Tanto mercurial como git tienen sus propios protocolos para mover conjuntos de cambios entre repositorios. Estos protocolos están optimizados/construidos para:

• eficiencia
• consistencia (no se puede tirar de un acuerdo de recompra en un estado de semi-actualizada)
• ganchos/disparadores - hacer las cosas de push/pull incluyendo la calidad (no hay fichas permitidas, etc.) filtros

Cuando dejas una sincronización de directorios manejar el mantenimiento de la .hg (o .git) directorios sincronizados a continuación durante ese sincronización que tienes una tienda que está en remoto un estado inconsistente y no lo sabe.

Además, tanto hg como git tienen una separación de lo que es local-only y lo que es remote-okay dentro del estado de su disco. Saben qué información compartir (por ejemplo: conjuntos de cambios comprometidos) y qué no (ejemplo: actual, revisión principal del directorio de trabajo local).

En otras respuestas, la gente dice "probablemente estarás bien" o "Nunca he tenido un problema" y eso es cierto, pero no está garantizado, y el control de revisión no es un lugar para jugar. posibilidades. Utilice el protocolo de sincronización apropiado, mejor, más seguro, más eficiente y más completo para su sistema de control de fuente.

Answer 2

Me gustaría tener problemas si intenta acceder al repositorio en el medio de la sincronización. También parece ser un poco sobrecargado. Realmente no necesitas sincronizar sobre las cosas que sincronizas. No tengo idea de cómo Dropbox maneja los conflictos, pero dudo que pueda hacerlo de una manera consciente de la ciencia.

Answer 3

Supongo que probablemente funcionaría bien para proyectos personales en una o dos máquinas, pero realmente vas a querer utilizar alojamiento profesional para proyectos de miembros múltiples.

Personalmente he usado BitBucket por algún tiempo y he estado muy satisfecho ... también puede tener un proyecto privado en la cuenta gratuita.

Answer 4

+1 para bitbucket. Es gratis, y obtienes un solo repositorio privado con esa cuenta gratuita (a diferencia de github).

El inconveniente de la solución de dropbox es que si se arruina algo en el repositorio de su máquina, ese error se copiará en bitbucket y se replicará en cualquier otro lugar donde tenga instalada la Dropbox. Dropbox es muy rápido, por lo que no podrás evitar que ocurra a tiempo para evitar problemas.

Pierde la capacidad de desacoplarse al realizar cambios en su repositorio al publicar esos cambios.

Utilizo Dropbox para alojar un par de repositorios que uso tanto en mi casa como en las máquinas de trabajo, pero esas no son las únicas copias de esos repositorios. También hay un repositorio bitbucket (así como otras personas que tienen clones de ellos).

Answer 5

He estado usando Dropbox con git para proyectos personales desde hace bastante tiempo, y no he tenido un solo problema todavía. Aunque, hay veces que tienes que esperar a que Dropbox se sincronice. I think esto puede causar problemas menores si hay más de unas pocas personas trabajando en el mismo proyecto, pero para proyectos personales, considero que Dropbox es incluso mejor que GitHub, aunque solo sea por el hecho de que empujar/tirar es más rápido.

En cuanto a presionar/tirar a mitad de sincronización, esto probablemente cause problemas, e incluso podría dañar su repositorio, pero si usted es el único que trabaja en el proyecto, sabrá exactamente cuándo se sincronizará Dropbox.

Answer 6

He tenido problemas con los repositorios de Dropbox dañados. No sucede todo el tiempo, pero el hecho de que haya sucedido más de una vez significa que voy a dejar de usar Dropbox para este propósito.

Dicho esto, Dropbox es ciertamente más económico que obtener un alojamiento real, por lo que siempre que guardes copias de seguridad puedes considerarlo aceptable para proyectos personales.

Answer 7

No recomendaría usar dropbox con mercurial, ya que a menudo veo archivos en conflicto entre mi Mac y clientes de Windows. Especialmente deshacer se ve afectado, pero también tuve conflictos con otros archivos.

Saludos Mirko

Answer 8

lo estoy usando con bazar en el momento a través de 3 máquinas. Sin embargo, soy el desarrollador solitario en cualquiera de las sucursales.

Utilicé el comando init-repo --no-trees para crear el repositorio.

Answer 9

He estado usando Dropbox con Hg también sin experimentar un problema hasta ahora. Demasiado tarde, me di cuenta de que hg no informa corrupción durante los registros rutinarios, solo cuando intentas utilizar el repositorio de manera real (la peor de todas las situaciones, ya que no sabes que algo está roto hasta que realmente lo necesites).

No está claro si la corrupción es espontánea o se produce al acceder al repositorio con los clientes de Mac, Windows y Linux (utilizo los tres en diferentes momentos). Pero he visto al menos un caso de corrupción que ocurre cuando solo la Mac estaba activa, por lo que podría ser Dropbox.

Si decide vivir peligrosamente, ejecute "hg verify" (o "git verify" regularmente para eliminar cualquier suciedad.

Answer 10

Para aquellos que prefieren usar Dropbox sobre bitbucket/github, esto es lo que hacer para evitar la corrupción del proceso de sincronización de 2 vías de los servicios de copia de seguridad en la nube:

Mi carpeta de código local es c:\code & carpeta de copia de seguridad es c:\Dropbox . Dentro de la carpeta de Dropbox, tengo un contenedor de archivos cifrados truecrypt (su tamaño es suficientemente más grande que mi carpeta de códigos). Durante el día, regularmente realizo cambios en mi repositorio Git/Mercurial local. Sin embargo, al final del día, dejé Dropbox & para montar el contenedor de archivos TrueCrypt. Presiono los cambios a un repositorio vacío en el contenedor de archivos, lo desmonto & reinicio de Dropbox.

De esta manera, puedo usar un servicio en la nube de forma segura para servir como copia de seguridad de mi repositorio DVCS. Si el contenedor de archivos está en uso, Dropbox esperará a que se desmonte, así que con suerte, no habrá ningún cambio de corrupción allí. Aún así, si obtengo una copia conflictiva del contenedor de archivos de alguna manera, puedo montar fácilmente ambas copias y comparar los conjuntos de cambios.