SVN para git: ¿Cómo lidiar con nuestra no-estándar, probablemente ramificado erróneamente SVN

Nuestra estructura SVN actual se parece a esto:SVN para git: ¿Cómo lidiar con nuestra no-estándar, probablemente ramificado erróneamente SVN

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 hacer las cosas peor fue ramificado proyecto-1.0 del proyecto projectDao-1,0 de projectDao (cada uno en movimientos separados se compromete). Idealmente hubiera sido así.

Este es el registro de confirmación:

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

Y esta es la manera 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 repositorio con el diseño estándar obtengo algo así.

* master 
    remotes/project-1.0 
    remotes/[email protected] 
    remotes/project-2.0 
    remotes/[email protected] 
    remotes/projectDao-1.0 
    remotes/[email protected] 
    remotes/projectDao-2.0 
    remotes/[email protected] 
    remotes/projectResources-1.0 
    remotes/[email protected] 
    remotes/projectResources-2.0 
    remotes/[email protected] 
    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

This is what gitg generates

no sé cómo puedo usar rebase para obtener este derecho como:

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

Fuente

2011-06-01 Huber Simmons

Escriba "git branch -a" y publique el resultado completo de ese comando en su pregunta. – ralphtheninja

Parece que ha exportado e importado varias veces en git, ¿es así? Por ejemplo, el maestro parece ser un árbol secundario propio, también lo es el "verde", etc. – ralphtheninja

Si entiendo correctamente, quiere cambiar las ramas importadas a directorios en una rama 1.0. Además, no mencionas si se trata de una migración permanente o un pago de git-svn mientras mantienes tu repositorio de svn.

En caso de que esto sea solo un checkout de git-svn y el objetivo es seguir trabajando con el SVN original como repositorio central, simplemente haría un checkout sin utilizar el conmutador de diseño estándar y trabajar en los directorios de SVN. Es un poco más sucio, pero no tienes problemas al volver a SVN.

En caso de que desee transformar su repositorio, agregue un compromiso a todas las ramas poniendo el contenido de esa rama en un directorio en la raíz, para unir las ramas 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 directorios y volver a establecer la base.

Fuente

2011-06-02 14:45:35 LaPingvino

Migraríamos de forma permanente.Sin embargo, esto es bastante nuevo para mí, así que realmente no entiendo cómo puedes hacer esto: _añadir un compromiso a todas las ramas poniendo los contenidos de esa rama en un directorio en la raíz, para unir las ramas después_. No es realmente necesario para transformar toda la historia. –

Para obtener una rama 1.0 y 2.0 (para 3.0 y posteriores, puede simplemente derivar el maestro a una rama 3.0): en las ramas de éstos (por ejemplo, Project-2.0, ProjectDao-2.0 y ProjectResources-2.0, o una copia de trabajo) de estas 3 ramas) crea un proyecto de directorio en el primero, ProjectDao en el segundo y ProjectResources en el tercero correspondiente al máster, y mueve todos los documentos a esos respectivamente, luego los compromete, luego se fusionan en la nueva rama 2.0. – LaPingvino

Gracias, eso hizo lo que necesitaba –

Usted debe ser capaz de rebasar estas ramas como mejor te parezca con git. Siempre y cuando puedas obtener el historial completo de svn a git, crear ramas 1.0 y 2.0 a partir de cualquier confirmación que consideres adecuada y continuar desde allí para construir cualquier estructura que desees es pan comido.

Fuente

2011-06-01 21:25:42 ralphtheninja

¿Podría explicarme un poco más? No entiendo cómo hacerlo. Agregué la estructura de la sucursal que actualmente tengo en la primera publicación. –

Parece un poco raro con el nombre "remotes/project-1.0", etc. (parece casi una rama remota, que se parecería a "controles remotos/origen/maestro"), pero supongo que esto es lo que sucede cuando se convierte de svn a git. – ralphtheninja

SVN para git: ¿Cómo lidiar con nuestra no-estándar, probablemente ramificado erróneamente SVN

Respuesta

Cuestiones relacionadas