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

Tengo un repository de Mercurial para un proyecto personal, y he estado almacenando el repository principal en mi Dropbox durante algunas semanas (algo similar a esta línea , y entiendo que también es posible con git ).

La idea es que sirve como una forma de trabajar con múltiples máquinas y como una copy de security remota. Copio el repository y trabajo en la copy que no es de Dropbox, y solo envío actualizaciones de vez en cuando, de la misma manera que, supongo, funcionaría con Bitbucket.

¿Puedes 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 counts gratuitas para usuarios únicos, lo cual es genial, pero están limitados a 150M, que no es muy grande .

En particular, ¿es posible que el process de synchronization de Dropbox corrompa el repository? Tuve que ejecutar hg recover una vez en el repository 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: agregué algunas aclaraciones a las preguntas. Están en cursiva .

Aconsejaría en contra de ello por las razones indicadas anteriormente, pero más enérgicamente declarado. Tanto mercurial como git tienen sus propios protocolos para mover sets de cambios entre repositorys. Estos protocolos están optimizados / diseñados para:

  • eficiencia
  • consistencia (nunca se puede sacar de un repository en un estado medio actualizado)
  • ganchos / desencadenantes: hacer cosas en push / pull incluyendo filters de calidad (sin tabs permitidas, etc.)

Cuando solo dejas que una synchronization de directorys maneje el mantenimiento de los directorys .hg (o .git) sincronizados, durante esa synchronization tienes un almacenamiento remoto que está en un estado incoherente 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: sets de cambios comprometidos) y qué no (ejemplo: actual, revisión principal del directory de trabajo local).

En otras respuestas, la gente dice "probablemente estarás bien" o "nunca he tenido un problema" y es probable que así sea, pero no está garantizado, y el control de revisión no es un lugar para jugar las probabilidades. Utilice el protocolo de synchronization apropiado, mejor, más seguro, más eficiente y más completo para su sistema de control de fuente.

He tenido problemas con los repositorys de Dropbox dañados. No sucede todo el time, 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 barato que get un alojamiento real, por lo que siempre que guardes copys de security puedes considerarlo aceptable para proyectos personales.

Supongo que probablemente funcionaría bien para proyectos personales en una o dos máquinas, pero realmente querrás utilizar alojamiento profesional para proyectos con varios miembros.

Personalmente he usado BitBucket por un time y he estado muy satisfecho … también puedes tener un proyecto privado en la count gratuita.

Espero problemas si intenta acceder al repository en el medio de la synchronization. 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.

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

El inconveniente de la solución de Dropbox es que si se arruina algo en el repository de su máquina, ese error se copyrá 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 time para evitar problemas.

Pierdes la capacidad de desacoplar la realización de cambios en tu repository con la publicación de esos cambios.

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

He estado usando Dropbox con Hg también sin experimentar un problema hasta ahora. Demasiado tarde, me di count de que hg no informa corrupción durante los loggings rutinarios, solo cuando intentas utilizar el repository 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 repository con clientes de Mac, Windows y Linux (utilizo los tres en diferentes momentos). Pero he visto al less 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.

He estado usando Dropbox con git para proyectos personales desde hace bastante time, y todavía no he tenido un solo problema. Aunque, hay veces que tienes que esperar a que Dropbox se sincronice. Creo que esto puede causar problemas menores si hay más de unas pocas personas trabajando en el mismo proyecto, pero para proyectos personales, me parece 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 media synchronization, es muy probable que esto cause problemas, e incluso podría dañar tu repository, pero si eres el único que trabaja en el proyecto, sabrás exactamente cuándo se sincronizará Dropbox.

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

Saludos Mirko

Lo estoy usando con Bazar en este momento en 3 máquinas. Sin embargo, soy el desarrollador solitario en cualquiera de las sucursales.

Usé el command init-repo –no-trees para crear el repository.

Para aquellos que prefieren usar Dropbox sobre bitbucket / github, esto es lo que hago para evitar la corrupción del process de synchronization bidireccional de los services de copy de security en la nube:

Mi carpeta de código local es c:\code y la carpeta de respaldo es c:\Dropbox . Dentro de la carpeta de Dropbox, tengo un contenedor de files encriptado truecrypt (Su tamaño es suficientemente más grande que mi carpeta de códigos). Durante el día, regularmente realizo cambios en mi repository Git / Mercurial local. Sin embargo, al final del día, dejé Dropbox y monté el contenedor del file TrueCrypt. Presiono los cambios en un repository vacío en el contenedor de files, lo desmonto y reinicio Dropbox.

De esa manera, puedo usar un service en la nube de forma segura para servir como copy de security de mi repository DVCS. Si el contenedor de files 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 copy conflictiva del contenedor de files de alguna manera, puedo montar fácilmente ambas copys y comparar los sets de cambios.