Envolviendo Dropbox con Mercurial para control de versiones – ¿idea loca?

Actualmente uso Dropbox como mi solución de "copy de security" para fuente y resources, y está muy bien y ha guardado mi tocino muchas veces.

Ahora necesito un sistema de control de versiones adecuado, y realmente no quiero poner un repository DENTRO de mi carpeta de Dropbox.

En primer lugar, completará mi asignación de Dropbox con bastante rapidez; para otro, no quiero que Dropbox y el software de control de versiones peleen por los files.

Así que estoy pensando en hacer algo como esto (estoy usando Mercurial, pero estoy seguro de que la misma teoría se aplica a otras cosas de VC)

MYDOCS Folder <-- this is where the repo will go .hg (for Mercurial in this case) DROPBOX Folder WORK FOLDER PROJECT1 PROJECT2 PROJECT3 ... 

De esa forma, todo lo que trabajo está cubierto por Dropbox, pero mi control de versión está fuera de Dropbox.

Obviamente, no todos los files de mi carpeta DROPBOX están controlados por la versión, y estoy atascado con solo 1 Repositorio para TODO mi trabajo (no es lo ideal) pero ¿alguien puede ver otros inconvenientes con este enfoque?

Nota: MYDOCS se respalda por separado (con mucha less frecuencia) por lo que no hay riesgo de pérdida de files aquí.

PD

Pasé un poco de time durante el fin de semana implementando esto (usando Mercurial / TortoiseHG) y parece funcionar bastante bien.

Hay algunos inconvenientes: tienes que configurar filters de ignorar agresivos (al final acabo de usar "*" y agregué el código manualmente), de lo contrario, TortoiseHG tiene un ataque al corazón con 10s de 1000s de files cada vez que busca cambios / nuevos files para agregar

Esto significa que no detectará nuevos files en proyectos existentes, que es un dolor de cabeza menor – sería genial si Mercurial tuviera un filter INCLUDE en momentos como este …

pps Tuve una idea shiny para hacer que esto fuera más fácil.

Creé una nueva carpeta fuera de Dropbox llamada "Repo" y dentro creé una unión de directory (enlace para usted * types de nix) al directory dentro de mi Dropbox que contiene todo mi origen (mi directory de Eclipse Workspace – básicamente).

Luego puse mi repo en la carpeta 'repo' – de esa manera no está supervisando todo mi Dropbox, solo la parte de él lo quiero, y todavía no está 'dentro' de mi Dropbox;)

Como usted señala, la principal desventaja de este enfoque es que está vinculado a un único repository. Una de las grandes ventajas de los sistemas de control de versiones distribuidas como Mercurial es que los repositorys son baratos de crear y usar para pequeños proyectos aislados.

¿Por qué no usar bitbucket.org para sus necesidades de control de versiones? Puede crear tantos repositorys privados como desee y usar todo el disco que desee. El único inconveniente aquí es que está limitado a la cantidad de usuarios con los que puede compartirlos, pero dado el enfoque que describió anteriormente, eso no parece ser un problema.

No vas a sufrir la corrupción del repository que se ve al mantener el directory .hg en Dropbox, pero probablemente terminarás cometiendo less, lo que también es un fastidio.

Mercurial codifica la raíz para que esté en el mismo nivel que el directory de trabajo, por lo que no creo que pueda cambiar esto.

Sin embargo, lo que podría hacer es .hg simbólicamente el directory .hg a otro directory:

 cd WORK_FOLDER ln -s ../MYDOCS_Folder/.hg .hg hg up null # to reset the dirstate hg up 

Mercurial seguirá el enlace simbólico y funcionará normalmente, pero probablemente Dropbox (si se comporta con sensatez) no lo hará. Cuando hagas esto, asegúrate de nunca hacer ninguna operación en la WORK FOLDER porque eso estropeará las cosas.

Para ser sincero, no recomendaría este tipo de flujo de trabajo, aunque parece frágil.