Svn to git: Cómo lidiar con nuestro svn no estándar, probablemente incorrectamente ramificado

Nuestra estructura svn actual se ve así:

trunk -- project -- projectDao -- projectResources branches -- project-1.0 -- projectDao-1.0 -- projectResources-1.0 -- project-2.0 -- projectDao-2.0 -- projectResources-2.0 tags -- project-1.0.0 -- ... 

Para empeorar las cosas project-1.0 se ramificó a partir del proyecto Project Dao-1.0 de projectDao (cada uno en movimientos separados). Idealmente hubiera sido así.

Este es el logging de compromiso:

 trunk -- project -- projectDao -- projectResources branches -- 1.0 ---- project ---- projectDao ---- projectResources -- 2.0 ---- project ---- projectDao ---- projectResources tags --1.0.0 ----project ---- ... 

Y esta es la forma en que tiene sentido. Y entonces deberíamos haber ramificado desde trunk hasta 1.0 en lugar de 2 commits diferentes.

Sin embargo, queremos cambiar a git ahora (de forma permanente) y no sé cómo debería comenzar con esto.

Realmente no entiendo cómo debería hacer esto. Cuando acabo de clonar mi repository con el layout estándar obtengo algo así.

 * master remotes/project-1.0 remotes/project-1.0@3 remotes/project-2.0 remotes/project-2.0@10 remotes/projectDao-1.0 remotes/projectDao-1.0@4 remotes/projectDao-2.0 remotes/projectDao-2.0@11 remotes/projectResources-1.0 remotes/projectResources-1.0@5 remotes/projectResources-2.0 remotes/projectResources-2.0@12 remotes/tags/project-1.0.0 remotes/tags/projectDao-1.0.0 remotes/tags/projectResources-1.0.0 remotes/trunk 

Esto es lo que genera gitg

Esto es lo que genera gitg

No sé cómo puedo usar rebase para hacerlo bien, como:

 * master remotes/1.0 remotes/2.0 remotes/tags/1.0.0 remotes/trunk 

Si entiendo correctamente, quiere cambiar las twigs importadas a directorys en una twig 1.0. Además, no mencionas si se trata de una migration permanente o un pago de git-svn mientras mantienes tu repository de svn.

En caso de que esto sea solo un checkout de git-svn y el objective es seguir trabajando con el SVN original como repository central, simplemente haría un checkout sin usar el conmutador de layout estándar y trabajaría en los directorys de SVN. Es un poco más sucio, pero no tienes problemas al volver a SVN.

En caso de que quiera transformar su repository, agregue un compromiso a todas las twigs colocando el contenido de esa twig en un directory en la raíz, para unir las twigs posteriormente. No perderá la historia de SVN con la antigua estructura de sucursal en su historial de GIT, pero el futuro será de estilo nuevo.

Solo en caso de que desee transformar todo el historial, tendrá que crear directorys y volver a establecer la base.

Deberías poder volver a clasificar estas twigs como mejor te parezca con git. Siempre y cuando puedas get el historial completo de svn a git, es tarea fácil crear las twigs 1.0 y 2.0 de cualquier compromiso que consideres oportuno y continuar desde allí para build cualquier estructura que desees.