Eclipse, importa el proyecto pero no copys

Utilizo Linux como sistema operativo primario y también tengo que trabajar en una máquina virtual de Windows con Eclipse 3.7.

Estamos trabajando con subversion pero con Linux estoy felizmente usando gitsvn con Emacs + magit, que funciona muy bien. Así que me gustaría poder trabajar en el mismo código desde ambos sistemas operativos y solo hacer la gestión de control de versiones reales en Linux.

Entonces tuve el siguiente pensamiento:
1. comparte el directory con virtualbox
2. crea los proyectos que apuntan al directory compartido

Bueno, eso no funciona, porque el tonto quiere copyr todo. Así que traté de usar carpetas virtuales que parecían una buena idea, pero ahora algunos scripts están fallando porque no encuentran las routes codificadas.

Entonces ya no sé qué probar, ¿alguna idea?

EDITAR:
Mi último bash en la última edición no funcionaría, así que tengo una pregunta más simple. Dado un process de recuperación de repository git / svn / whatever, ¿por qué no puedo simplemente decirle a Eclipse que cree un proyecto allí sin tocar los files?

¿Es tan difícil para Eclipse crear su proyecto en esa position?
Y dado que claramente no hay una forma de "apoyo" para hacerlo, ¿hay alguna solución alternativa?

Eclipse modifica y comstack fuente en su área de trabajo. El primer nivel del espacio de trabajo son los directorys del proyecto, + a. Metadatos que es local solo para esa instancia de espacio de trabajo. Tradicionalmente, el espacio de trabajo contiene los proyectos en los que trabaja.

Eclipse también es compatible con 2 modos vinculados. En una, cuando crea el proyecto en el área de trabajo le da una ruta absoluta a otro lugar en el sistema de files. Esto es útil si tienes proyectos de eclipse en un repository git, por ejemplo.

En el otro modo, crea el proyecto en su espacio de trabajo localmente. Luego vincula sus carpetas (fuente, resources, lo que sea) a otro lugar en el sistema de files. Esto es útil para proyectos que no desean save los files específicos del eclipse (.project, .classpath, etc.) en su SCM.

Tienes que crear un espacio de trabajo diferente en cada sistema operativo (no hay forma de evitarlo). Pero podría crear los proyectos en cada espacio de trabajo y vincularlos a la location común (no lo recomiendo, pero sería factible).

Desde mi experiencia, las etapas son las siguientes (usando la versión de Indigo): 1. Crear un nuevo proyecto vacío 2. Haga clic en Archivo-> importar-> sistema de files 3. en el sistema de import de files de la window de import, compruebe los files que desea en el nuevo carpeta de proyecto 4. Haga clic en avanzado en la window de import y marque "crear enlaces en el área de trabajo"

El nuevo proyecto debe contener enlaces al directory original.

Mismo problema aquí y finalmente obtuve una solución!

1) clone su repository pero no directamente en su espacio de trabajo, en mi caso utilicé workspace2 en lugar de workspace.

2) En eclipse, importe todos los proyectos en workspace2, pero no marque "copyr files al área de trabajo", por lo que el código fuente se deja en workspace2.

3) En git verá cambios aparecidos, en files project.options (solo se cambia la date del file) y en files .path (algunas líneas cambiaron su order). Como todos ellos son cambios irrelevantes, reinicie la sucursal local descartando esos cambios.

Eso es todo, ¡Git no ve más cambios y eclipse para abrir los files correctamente!

Me encontré con un problema extraño que vale la pena comentar aquí: después de importar fui a "git gui" para ver los cambios, y el primer file cambiado fue un file "project.options" que solo cambió su date pero el diff estaba vacío (como el contenido no se modificó). Hay un error en git que hace que git gui ingrese en un bucle infinito: mientras detecta cambios en el file y diff está vacío, se realiza una nueva exploración, luego se detecta el mismo cambio e ingresa en un bucle de reescaneo.

Hay un parche para resolver esto, pero era más fácil simplemente agregar un comentario tonto en ese único file (no en todas tus project.options) y luego "git gui" era feliz de nuevo y podía restablecer los cambios en la twig.