Mercurial(y supongo que Git) con Dropbox: ¿algún inconveniente?
(10)
+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.
Pierdes la capacidad de desacoplar la realización de cambios en tu repositorio con la publicación de esos cambios.
Utilizo Dropbox para alojar un par de repositorios que uso tanto en mi casa como en mi máquina 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).
Tengo un repositorio de Mercurial para un proyecto personal, y he estado almacenando el repositorio 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 copia de seguridad remota. Copio 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.
¿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 cuentas 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 proceso de sincronización de Dropbox corrompa el repositorio? Tuve que ejecutar hg recover 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: 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 conjuntos de cambios entre repositorios. Estos protocolos están optimizados / diseñados para:
- eficiencia
- consistencia (nunca se puede sacar de un repositorio en un estado medio actualizado)
- ganchos / desencadenantes: hacer cosas en push / pull incluyendo filtros de calidad (sin pestañas permitidas, etc.)
Cuando solo dejas que una sincronización de directorios maneje el mantenimiento de los directorios .hg (o .git) sincronizados, durante esa sincronización 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: 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 es probable que así sea, pero no está garantizado, y el control de revisión no es un lugar para jugar contra viento y marea. Utilice el protocolo de sincronización apropiado, mejor, más seguro, más eficiente y más completo para su sistema de control de origen.
Espero 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.
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 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.
He estado usando Dropbox con git para proyectos personales desde hace bastante tiempo, 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 los 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 sincronización, es muy probable que esto cause problemas, e incluso podría dañar tu repositorio, pero si eres el único que trabaja en el proyecto, sabrás exactamente cuándo se sincronizará Dropbox.
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 barato que obtener un alojamiento real, por lo que siempre que guardes copias de seguridad puedes considerarlo aceptable para proyectos personales.
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 comando init-repo --no-trees para crear el repositorio.
No recomendaría usar Dropbox con mercurial, ya que a menudo veo archivos en conflicto entre mi Mac y los clientes de Windows. Especialmente deshacer se ve afectado, pero también tuve conflictos con otros archivos.
Saludos Mirko
Para aquellos que prefieren usar Dropbox sobre bitbucket / github, esto es lo que hago para evitar la corrupción del proceso de sincronización bidireccional de los servicios de respaldo 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 archivos encriptados 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 y monté el contenedor del archivo TrueCrypt. Presiono los cambios en un repositorio vacío en el contenedor de archivos, lo desmonto y reinicio Dropbox.
De esa 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.
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 tiempo y he estado muy satisfecho ... también puedes tener un proyecto privado en la cuenta gratuita.