9.2 Git y Otros Sistemas - Migración a Git

Si lee la sección anterior sobre el uso de git svn, usted puede usar fácilmente esas instrucciones para clonar un repositorio; luego, deje de usar el servidor de Subversión, presione en un nuevo servidor de Git y comience a usarlo. Si desea ver el historial, puede lograrlo tan rápido como pueda extraer los datos del servidor de Subversión (lo que puede llevar un tiempo).

Sin embargo, la importación no es perfecta; y porque tomará tanto tiempo, también puedes hacerlo bien. El primer problema es la información del autor. En Subversión, cada persona comprometida tiene un usuario en el sistema que está registrado en la información de confirmación. Los ejemplos en la sección anterior muestran schacon en algunos lugares, como la salida de culpa y el registro de git svn. Si desea asignar esto a mejores datos de autor de Git, necesita una asignación de los usuarios de Subversión a los autores de Git. Cree un archivo llamado users.txt que tenga esta asignación en un formato como este:

Para obtener una lista de los nombres de autor que utilizan SVN, puede ejecutar esto:

Eso genera la salida del registro en formato XML, luego mantiene solo las líneas con la información del autor, descarta los duplicados y elimina las etiquetas XML. (Obviamente, esto solo funciona en una máquina con grep, sort y perl instalados). Luego, redirija esa salida a su archivo users.txt para que pueda agregar los datos de usuario equivalentes de Git al lado de cada entrada.

Puede proporcionar este archivo a git svn para ayudarlo a mapear los datos del autor con mayor precisión. También puede indicarle a git svn que no incluya los metadatos que normalmente importa Subversión, pasando --no-metadata al comando clone o init. Esto hace que su comando de importación se vea así:

Ahora debería tener una importación de Subversión más agradable en su directorio my_project. En lugar de commits que se ven así

se ven así:

No solo el campo Autor se ve mucho mejor, sino que el git-svn-id ya no está allí.

También debería hacer un poco de limpieza posterior a la importación. Por un lado, debe limpiar las referencias raras que git svn configuró. Primero moverá las etiquetas para que sean etiquetas reales en lugar de ramas remotas extrañas, y luego moverá el resto de las ramas para que sean locales.

Para mover las etiquetas para que sean etiquetas Git correctas, ejecuta

Esto toma las referencias que eran ramas remotas que comenzaron con controles remotos / origen / etiquetas / y las convierte en etiquetas reales (ligeras).

A continuación, mueva el resto de las referencias en refs / remotes para que sean ramas locales:

Ahora todas las ramas antiguas son ramas reales de Git y todas las etiquetas antiguas son etiquetas Git reales. Lo último que debe hacer es agregar su nuevo servidor Git como un control remoto y pulsarlo. Aquí hay un ejemplo de cómo agregar su servidor como un control remoto:

Como quiere que todas sus ramas y etiquetas suban, ahora puede ejecutar esto:

Todas sus ramas y etiquetas deben estar en su nuevo servidor Git en una importación agradable y limpia..

Since Mercurial and Git have fairly similar models for representing versions, and since Git is a bit more flexible, converting a repository from Mercurial to Git is fairly straightforward, using a tool called "hg-fast-export", which you’ll need a copy of:

The first step in the conversion is to get a full clone of the Mercurial repository you want to convert:

The next step is to create an author mapping file. Mercurial is a bit more forgiving than Git for what it will put in the author field for changesets, so this is a good time to clean house. Generating this is a one-line command in a bash shell:

This will take a few seconds, depending on how long your project’s history is, and afterwards the /tmp/authors file will look something like this:

In this example, the same person (Bob) has created changesets under four different names, one of which actually looks correct, and one of which would be completely invalid for a Git commit. Hg-fast-export lets us fix this by adding ={new name and email address} at the end of every line we want to change, and removing the lines for any usernames that we want to leave alone. If all the usernames look fine, we won’t need this file at all. In this example, we want our file to look like this:

The next step is to create our new Git repository, and run the export script:

The -r flag tells hg-fast-export where to find the Mercurial repository we want to convert, and the -A flag tells it where to find the author-mapping file. The script parses Mercurial changesets and converts them into a script for Git’s "fast-import" feature (which we’ll discuss in detail a bit later on). This takes a bit (though it’s much faster than it would be over the network), and the output is fairly verbose:

That’s pretty much all there is to it. All of the Mercurial tags have been converted to Git tags, and Mercurial branches and bookmarks have been converted to Git branches. Now you’re ready to push the repository up to its new server-side home:

El siguiente sistema que verá importando es Perforce Como mencionamos anteriormente, hay dos formas de que Git y Perforce hablen entre sí: git-p4 y Perforce Git Fusion.

Si su equipo está convirtiendo su control de código fuente de TFVC a Git, querrá la conversión de mayor fidelidad que pueda obtener. Esto significa que mientras cubrimos git-tfs y git-tf para la sección de interoperabilidad, sólo cubriremos git-tfs para esta parte, porque git-tfs soporta ramificaciones, y esto es prohibitivamente difícil usando git-tf.

The first thing to do is map usernames. TFVC is fairly liberal with what goes into the author field for changesets, but Git wants a human-readable name and email address. You can get this information from the tf command-line client, like so:

Esto agarra todos los conjuntos de cambios de la historia del proyecto y lo coloca en el archivo AUTHORS_TMP que procesaremos para extraer los datos de la columna Usuario (el segundo). Abre el archivo y busca en qué caracteres comienzan y terminan la columna y reemplazan, en la línea de comandos siguiente, los parámetros 11-20 del comando` cut` con los que se encuentran:

El comando cut mantiene sólo los caracteres entre 11 y 20 de cada línea. El comando tail omite las dos primeras líneas, que son cabeceras de campo y subrayados ASCII-art. El resultado de todo esto se canaliza a uniq para eliminar duplicados y se guarda en un archivo llamado` AUTHORS`. El siguiente paso es manual; Para que git-tfs haga un uso efectivo de este archivo, cada línea debe estar en este formato:

La parte de la izquierda es el campo “Usuario” de TFVC, y la porción en el lado derecho del signo de iguales es el nombre de usuario que se utilizará para los compromisos de Git.

Una vez que tengas este archivo, lo siguiente que debes hacer es hacer un clon completo del proyecto TFVC en el que estás interesado:

A continuación, deseará limpiar las secciones git-tfs-id desde la parte inferior de los mensajes de confirmación. El siguiente comando hará lo siguiente:

Que utiliza el comando sed desde el entorno Git-bash para reemplazar cualquier línea que empiece por “git-tfs-id:” con vacío, que Git luego ignorará.

Una vez que todo está hecho, estás listo para añadir un nuevo mando a distancia, empujar todas sus ramas hacia arriba, y hacer que su equipo comience a trabajar desde Git.

Si su sistema no es uno de los arriba mencionados, usted debe buscar un importador online - importadores de calidad están disponibles para muchos otros sistemas, incluido el CVS, Clear Case, Visual Source Safe, incluso un directorio de archivos. Si ninguna de estas herramientas funciona para usted, tiene una herramienta más obsoleta o necesita un método de importación más personalizado, debería usar ‘git fast-import’.. Este comando lee instrucciones simples de stdin para escribir datos Git específicos. Es mucho más fácil crear objetos Git de esta manera que ejecutar los comandos raw Git o intentar escribir los objetos raw (ver [ch10-git-internals] para más información). De esta manera, puede escribir un script de importación que lee la documentación necesaria del sistema desde el que está cargando e imprime instrucciones directas a stdout. A continuación, puede ejecutar este programa y canalizar su resultado mediante `git fast-import

Para demostrar rápidamente, podrá escribir un simple mensaje Supongamos que trabajas en current, haces una copia de seguridad de tu proyecto copiando el directorio ocasionalmente en un directorio de copia de seguridad con el código ‘back_YYYY_MM_DD" directorio de copia de seguridad y desea importar esta en Git. Tu Estructura del directorio se ve así:

Para poder importar un directorio Git, necesitas revisar cómo Git almacena sus datos. Como recordará, Git es fundamentalmente una listado enlazado de objetos commit que apuntan a una imágen de contenido. Todo lo que tienes por hacer es indicarle a `fast-import`qué son las snapshots de contenido, cuáles son los puntos de datos de confirmación y el orden en que van a entrar. Su estrategia será para ir a través de snapshots Uno a la vez y crear commits con el contenido de cada directorio, vinculando cada commit al anterior.

Como hicimos en Un ejemplo de implantación de una determinada política en Git, scribiremos esto en Ruby, porque es con lo que generalmente trabajamos y tiende a ser fácilmente legible.Usted puede escribir este ejemplo con bastante facilidad en cualquier elemento con el que esté familiarizado - sólo tiene que escribir la información apropiada a "stdout"., si se está ejecutando en Windows, esto significa que usted tendrá que tener especial cuidado de no introducir porte devoluciones al final de sus líneas - Importación rápida de git es muy particular acerca de que sólo quieren saltos de línea (LF) salto de línea (CRLF) usando windows.

Para empezar, cambiará al directorio de destino e identificará cada subdirectorio, cada uno de los cuales es snapshot que desea importar como un commit. Cambiará a cada subdirectorio e imprimirán los comandos necesarios para exportarlo. Tu loop principal básico se ve así:

Si ejecuta print_export dentro del directorio, que toma el registro y la señal de la instantánea anterior y devuelve el registro y la señal de ésta; de esa manera, se pueden enlazar correctamente.“Mark” is the fast-import para un código de identificación que se da a un commit; mientras crea commits,dar a cada uno de ellos una anotación que se puede utilizar para vincular al mismo desde otro commits. Por lo tanto, lo primero que debe hacer en el método ‘print_export’ es generar una etiqueta a partir del nombre del directorio:

Para ello, creará una matriz de directorios y utilizará el valor índice como punto, ya que una línea debe ser un código entero. Tu sistema se ve así:

Ahora que tiene una representación entera de su commit, necesita una dirección para los metadatos de commit. Como la información está expresada en el nombre del directorio, la analizarás. La siguiente línea del archivo print_export es

Donde`convert_dir_to_date` esta definido como

Esto devuelve un valor entero para la data de cada directorio. La última parte de la meta-información que necesita para cada committer son los datos del committer, que usted codifica en una variable global:

Ahora está listo para empezar a publicar los datos de validación para su importador.: La información inicial indica que está definiendo un objeto de commit y en qué rama está activado, seguido de la línea que ha generado, la información de committer y el mensaje de committer y, a continuación, la línea anterior, si la hay. El código se ve así:

Usted codifica la zona horaria (-0700) porque hacerlo es fácil.

Si está importando desde otro sistema, debe especificar el uso horario como un intervalo de tiempo. El mensaje de confirmación debe expresarse en un formato especial:

El formato consiste en los datos de la palabra, el tamaño de los datos a leer, una nueva línea, y finalmente los datos. Puesto que necesita utilizar el mismo formato para especificar el contenido del archivo más tarde, cree un sistema de ayuda,"export_data":[source,ruby]

Todo lo que queda es especificar el contenido del archivo para cada uno de ellos. snapshot. Esto es fácil, porque tiene cada uno de ellos en un directorio - puede crear el comando borrar todo seguido del contenido de cada archivo en el directorio. Git entonces grabará cada instantánea apropiadamente:

Nota: Porque muchos sistemas piensan que sus modificaciones son cambios de una confirmación a otra, fast-import también puede tomar comandos con cada confirmación para especificar qué archivos se han agregado, eliminado o modificado y cuáles son los nuevos archivos. Podrías calcular las diferencias entre snapshots y proporcionar sólo estos archivos, pero hacerlo es más complejo - también puedes darle a Git todos los datos y dejar que lo resuelva. Si esto se adapta mejor a sus archivos, consulte la página de manual "Importación rápida" para obtener más detalles sobre cómo proporcionar sus archivos de esta manera. El formato para listar el nuevo contenido del archivo o especificar un archivo modificado con el nuevo contenido es el siguiente:

Aquí, 644 es el modulo (si tiene archivos ejecutables, necesita detectar y especificar 755 en su lugar), e inline dice que listará el archivo inmediatamente después de esta línea. Su método de "datos_inline" se ve así:

Se reutiliza el modo export_data que definió anteriormente, porque es el mismo que el de los datos del mensaje de confirmación. Lo último que necesita hacer es devolver la línea actual para que pueda pasar a la siguiente edición:

Eso es todo. Aquí está el script en su totalidad:

If you run this script, you’ll get content that looks something like this:

Para ejecutar el importador, se debe pasar esta señal a través de git fast-import mientras que en el directorio Git se desea copiar. Puede crear un nuevo directorio y luego ejecutar git init en él para un punto de partida, y luego ejecutar su script:

Como puedes ver, cuando se completa con éxito, te da un conjunto de estadísticas sobre lo que logró. En este caso, ha importado un total de 13 objetos para 4 confirmaciones en 1 rama. Ahora, puedes ejecutar git log para ver tu nueva historial:

Ahí tienes, un buen y limpio depósito de Git. Es importante tener en cuenta que nada está comprobado - no tiene archivos en su directorio de trabajo al principio. Para obtenerlos, debe reajustar su rama a donde "maestro" está ahora:

Puedes hacer mucho más con la herramienta "Importación rápida": maneja diferentes modos, datos binarios, múltiples ramas y fusiones, etiquetas, indicadores de progreso y mucho más. Varios ejemplos de escenarios más complejos están disponibles en el directorio ‘contrib/fast-import’ del código fuente Git.