2009-07-20 12 views
6

Esta pregunta es similar a this one y this one, pero el escenario es un poco más complejo.¿Cómo se comporta git-svn con los repositorios svn que han cambiado de diseño?

Empecé hace unos años con un repositorio svn privado (que utilizo principalmente para archivos de configuración compartida y similares entre varias máquinas). No fui muy cuidadoso con el diseño del repositorio (donde se ramifica, se va, etc.), así que cambió bastante con el tiempo. Esto fue, por supuesto, un error, pero ya es demasiado tarde. Más recientemente, lo he migrado a un diseño svn trunk/branches/tags más estándar, principalmente con los comandos svn move, pero por supuesto el viejo historial todavía está presente en el repositorio (y, francamente, es un poco desordenado) .

Me gustaría convertir esto permanentemente en un repositorio de git. He intentado usar git-svn, pero parece que solo maneja situaciones en las que se ha seguido una convención de troncal/rama/etiqueta consistente (sí, puedes proporcionar nombres alternativos, pero solo uno para cada uno, aparece). Gran parte de la historia de mi repositorio tiene un tronco efectivamente en la raíz del repositorio, por ejemplo, con etiquetas/y ramas/como subdirectorios.

¿Cuál es la mejor manera de manejar todo esto? Idealmente, me gustaría que el repositorio git con el que termino tenga al menos todo el historial accesible de alguna manera, incluso si las ramas y las etiquetas no están representadas adecuadamente como conceptos de primera clase en git.

Más específicamente, ¿cómo manejará svn-git archivos fuera de los subdirectorios trunk/branches/tags provistos? Mis observaciones hasta el momento son que a veces las echa de menos (definitivamente no está bien), y otras veces las agrega al nuevo repositorio.

Cualquier pensamiento sería apreciado.

+0

Preguntas cómo se comportará sino también decir que lo he probado. Ejemplos específicos de comportamiento indeseable que haya observado serían útiles. Git suele ser increíblemente bueno en el manejo de fusiones complejas, por ejemplo, alterando y moviendo un subárbol en el mismo compromiso. –

+0

OK - Lo he intentado. Admito que no pude haber profundizado en los resultados por completo, pero mis observaciones superficiales fueron ciertamente que git-svn parecía incluir algunos directorios de la raíz svn (es decir, fuera de los directorios trunk/branches/tags), pero no otros. Estaba confundido sobre por qué. git sure es capaz de manejar fusiones complejas, pero creo que esta pregunta es más sobre git-svn que git. –

+0

usa la etiqueta ['svn'] en lugar de la etiqueta [' subversion'] http://meta.stackexchange.com/questions/2601/batch-retag-request-merge-svn-and-subversion –

Respuesta

2

En mi experiencia, la única forma de manejar esto es hacer un seguimiento de la ubicación del repositorio a lo largo del tiempo, y hacer un git-svn-clone por separado para cada período que el proyecto permaneció en una ubicación.

Después de haber creado los repositorios para diferentes etapas en el tiempo (o al menos tan atrás como pueda ser molestado), puede injertar los repositorios juntos.

He creado un screencast que demuestra esta técnica aquí:

http://blog.tfnico.com/2010/10/gitsvn-6-grafting-together-svn-history.html

Cuestiones relacionadas