¿Cómo puede un estudiante mobile usar efectivamente Dropbox con un sistema de control de fuente?

Tengo una computadora portátil en preparación para el próximo semestre, que me llevará a tomar un curso de progtwigción universitaria mientras trabajo a time completo. Por supuesto, usaré un sistema de control de fuente (probablemente Subversion) y tuve la idea de crear mis repositorys en mi carpeta de Dropbox, lo que me permitiría verificar y trabajar localmente el código usando mi computadora portátil o mi escritorio (o de hecho, cualquier otra computadora que pueda acceder a Internet), y luego volver a enviarla al repository compartido de Dropbox.

  • ¿Alguna trampa o razón por la cual esta no sea una buena manera de lograr mi objective? (Supongamos que puedo evitar la corrupción del repository SVN haciendo algo estúpido).
  • ¿Alguna de las claras ventajas de ir con una solución de alojamiento web que superaría las ventajas de Dropbox (es decir, es gratis y ya está configurado en mis máquinas)?
  • ¿Alguna otra estrategia para compartir para trabajar en código desde múltiples ubicaciones?

Nota: No tengo la intención de compartir la carpeta de Dropbox con otras personas, ya que me doy count de que el hecho de que varias personas accedan a un repository a través de un file:// es una mala idea. Mi pregunta solo se refiere a un usuario individual.

Si bien a primera vista esto parece una mala idea (básicamente superponer dos sistemas de control de revisión diferentes con flujos de trabajo diferentes), hay una manera que tendría sentido para usted, suponiendo que usted sea el único desarrollador.

(Como nota al margen, lo que Dropbox le ofrece es una copy de security fuera de línea de sus datos, así como un server desde el que sincronizar. Si intenta usar SVN por sí mismo, tendrá que configurar su máquina para permitir el acceso de forma remota. puede o no ser un factor decisivo para usted, dependiendo de su nivel de experiencia en tareas tipo sysadmin).

Lo que podría hacer es crear un repository para un proyecto determinado en su unidad de Dropbox. Luego, al retirar una copy de trabajo, créela fuera de la carpeta de Dropbox, accediendo a tu repository usando el file: protocolo. De esta forma, el repository permanece sincronizado en todas las máquinas, pero cada máquina tiene una carpeta de trabajo separada, lo que le permite trabajar en una twig diferente en una máquina que otra si lo desea, o mantener un código no asignado sin que se propague a otra máquina. Donde esto se rompe es si varias personas están accediendo al repository a través del file: protocolo: esto no se recomienda debido a las posibles condiciones de carrera.

Nota: esta solución le permite continuar comprometiéndose incluso cuando está fuera de línea, como lo haría con otros DVCS. Pero tenga en count que hacer esto y luego comprometerse sin connection en otra máquina antes de permitir que se sincronicen los repos podría ser desastroso. Es extremadamente importante permitir que los repos se sincronicen después de trabajar fuera de línea antes de realizar una confirmación en otra máquina.

Sugeriría usar un DVCS en vez de Subversion con Dropbox. La razón es que es posible producir un conflicto de combinación con Dropbox al cambiar el mismo file a las máquinas al mismo time con conectividad de networking limitada / sin connection. Si logra desorderar su depósito de subversión de esta manera, será difícil arreglar el repository, mientras que con los sistemas popclar DVCS puede al less activar el repository roto y clonar una versión local del mismo en el recurso compartido de Dropbox.

Mientras escribía lo anterior, me di count de que no menciona si está usando más de una computadora con la misma count de Dropbox, por lo que lo anterior no se aplica realmente si está usando su count de Dropbox con una sola computadora (supongo que podría si haces algo realmente tonto / raro).

Yo usaría Git y Github. Luego tiene un control de fuente Y puede acceder fácilmente desde ambos lugares.

O incluso más ideal sería configurar su propio server para alojar el repository svn o git, pero obviamente no siempre es una opción.