2010-07-02 17 views
11

Esto es tal vez inusual, así que déjenme establecer la escena:Administrar fuente bajo git y svn simultáneamente - ¿tiene sentido?

Tenemos un repositorio SVN que contiene nuestro historial de proyectos: un sistema integrado basado en Linux. El repositorio de SVN contiene fuentes del kernel de Linux, U-Boot, busybox, etc. y todas nuestras aplicaciones internas, sistema de archivos y demás.

El kernel de Linux que tenemos es viejo y crujiente y estoy trabajando en la migración a la línea principal, que está en desarrollo activo para nuestra (s) plataforma (s). Estoy haciendo el trabajo del kernel en git y parches comerciales con "The Community".

Podría hacer que las cosas funcionen y tomar una instantánea de las fuentes del kernel y volcarlas en SVN, pero me gustaría mantener la capacidad de obtener actualizaciones, tener sucursales locales y administrar parches con git. Podría guardar dos copias del kernel, una administrada por cada SCM, pero sería un poco complicado. También existen riesgos de desarrollar y probar utilizando fuentes kernel administradas bajo git, y olvidando poner esos cambios en SVN resultando en versiones SVN rotas donde las fuentes que no son kernel no están sincronizadas.

La migración de todo el proyecto a git no es una opción. Gestionar solo la fuente del kernel con git y tener un montón de scripts de cola y hashes almacenados en SVN es posible, pero es más agradable tener una capacidad unificada de historial/difusión desde SVN para todo el proyecto.

Lo que estoy considerando es tratar de administrar las fuentes del núcleo tanto en SVN como en Git simultáneamente, en el mismo directorio.

Como desarrollador del kernel, principalmente uso git y hago un commit de SVN para uso interno cuando las cosas se ven bien. Para otros usuarios internos, podrían obtener fuentes enteras y consistentes con un checkout de SVN, ver un historial unificado y podrían realizar cambios en las fuentes del núcleo bajo SVN. Más tarde, yo u otra persona que usa git puedo actualizar SVN a esos cambios y comprometerlos a git según corresponda.

Habrá que hacer algunos ajustes para que git ignore los archivos .svn y viceversa. Además, no estoy muy seguro de cómo se tomaría una verificación simple de SVN y se lo diría a git que también comience a administrar el subárbol kernel, pero estoy seguro de que git tiene algunas opciones oscuras de cuchillo de ejército suizo para hacerlo.

Así que esa es mi idea du jour. Significa que la mayoría de los compañeros de trabajo no tienen que preocuparse por el git, y podemos ignorar silenciosamente el git y el tenedor después, según sea necesario.

La pregunta aquí realmente es, ¿alguien ha hecho algo como esto, cómo funcionó o qué soluciones alternativas se te ocurrieron?

+1

A continuación, he estado haciendo esto por un tiempo y funciona bien. – blueshift

+0

¿Qué pasa si alguna vez necesita clonar esta configuración en otra máquina? Por ejemplo, si tengo un directorio bajo control git, agrégalo a svn con las ignoraciones apropiadas, pero luego quiero la misma configuración en otra máquina. ¿Tendría que clonar el repo de git y luego intentar sacar el repo de svn en ese directorio? ¿Al revés? –

+1

Descubrí que puede hacer lo que le pedí haciendo clon de git y luego 'svn checkout --force ' para combinar los dos repos. –

Respuesta

6

He hecho esto regularmente, y funciona muy bien.

Lo único importante que tenía que hacer era agregar la carpeta .git a la lista de ignorar la subversión, y la .svn/carpetas al archivo .gitignore.

+0

¡Prometedor! Gracias por la respuesta. – blueshift

Cuestiones relacionadas