Buscar..
Observaciones
Clonando repositorios SVN realmente grandes
Si el historial de repositorios SVN es realmente grande, esta operación podría llevar horas, ya que git-svn necesita reconstruir el historial completo del repositorio SVN. Afortunadamente, solo necesitas clonar el repo SVN una vez; Al igual que con cualquier otro repositorio de git, puede copiar la carpeta de repositorio a otros colaboradores. Copiar la carpeta a varias computadoras será más rápido que solo clonar grandes repositorios SVN desde cero.
Sobre commit y SHA1
Sus confirmaciones de git locales se reescribirán cuando use el comando git svn dcommit . Este comando agregará un texto al mensaje de confirmación de git que hace referencia a la revisión SVN creada en el servidor SVN, lo cual es muy útil. Sin embargo, agregar un nuevo texto requiere modificar un mensaje de confirmación existente que no se puede hacer realmente: las confirmaciones de git son inmutables. La solución es crear un nuevo compromiso con el mismo contenido y el nuevo mensaje, pero técnicamente es un nuevo compromiso de todos modos (es decir, el SHA1 del git commit cambiará)
Como las confirmaciones de git creadas para git-svn son locales, ¡los ID de SHA1 para las confirmaciones de git son diferentes entre cada repositorio de git! Esto significa que no puede usar un SHA1 para hacer referencia a un compromiso de otra persona porque el mismo compromiso tendrá un SHA1 diferente en cada repositorio de git local. Debe confiar en el número de revisión svn que se anexa al mensaje de confirmación cuando empuja al servidor SVN si desea hacer referencia a una confirmación entre diferentes copias del repositorio.
Sin embargo, puede usar el SHA1 para las operaciones locales (mostrar / diferencia un compromiso específico, selecciones y reinicios, etc.)
Solución de problemas
El comando git svn rebase emite un error de suma de comprobación
El comando git svn rebase produce un error similar a este:
Checksum mismatch: <path_to_file> <some_kind_of_sha1>
expected: <checksum_number_1>
got: <checksum_number_2>
La solución a este problema es restablecer svn a la revisión cuando el archivo con problemas se modificó por última vez, y hacer un git svn fetch para que se restaure el historial de SVN. Los comandos para realizar el reinicio de SVN son:
- git log -1 -
<path_to_file>(copie el número de revisión de SVN que aparece en el mensaje de confirmación) - git svn reset
<revision_number> - git svn fetch
Debería poder empujar / extraer datos de SVN nuevamente
El archivo no se encontró en la confirmación Cuando intenta obtener o extraer de SVN, aparece un error similar a este
<file_path> was not found in commit <hash>
Esto significa que una revisión en SVN está intentando modificar un archivo que, por algún motivo, no existe en su copia local. La mejor manera de deshacerse de este error es forzar una búsqueda ignorando la ruta de ese archivo y se actualizará a su estado en la última revisión de SVN:
-
git svn fetch --ignore-paths <file_path>
Clonando el repositorio SVN
Debe crear una nueva copia local del repositorio con el comando
git svn clone SVN_REPO_ROOT_URL [DEST_FOLDER_PATH] -T TRUNK_REPO_PATH -t TAGS_REPO_PATH -b BRANCHES_REPO_PATH
Si su repositorio SVN sigue el diseño estándar (troncal, ramas, carpetas de etiquetas) puede guardar algo de escritura:
git svn clone -s SVN_REPO_ROOT_URL [DEST_FOLDER_PATH]
git svn clone revisa cada revisión de SVN, una por una, y realiza un git commit en su repositorio local para recrear el historial. Si el repositorio SVN tiene muchas confirmaciones, esto tomará un tiempo.
Cuando finalice el comando, tendrá un repositorio git completo con una rama local llamada master que rastrea la rama troncal en el repositorio SVN.
Obteniendo los últimos cambios de SVN
El equivalente a git pull es el comando.
git svn rebase
Esto recupera todos los cambios del repositorio de SVN y los aplica sobre sus confirmaciones locales en su rama actual.
También puedes usar el comando
git svn fetch
para recuperar los cambios del repositorio de SVN y llevarlos a su máquina local pero sin aplicarlos a su sucursal local.
Empujando cambios locales a SVN
El comando
git svn dcommit
creará una revisión de SVN para cada una de tus confirmaciones locales de git. Al igual que con SVN, su historial de git local debe estar sincronizado con los últimos cambios en el repositorio de SVN, por lo que si el comando falla, intente realizar primero una git svn rebase .
Trabajando localmente
Simplemente use su repositorio git local como un repositorio git normal, con los comandos git normales:
-
git add FILEygit checkout -- FILEPara configurar / deseleccionar un archivo -
git commitPara guardar tus cambios. Esos compromisos serán locales y no se "enviarán" al repositorio de SVN, como en un repositorio normal de git -
git stashygit stash popPermite usar stashes -
git reset HEAD --hardRevertir todos tus cambios locales -
git logAccede a todo el historial en el repositorio. -
git rebase -ipara que puedas reescribir tu historia local libremente -
git branchygit checkoutpara crear sucursales locales
Como indica la documentación de git-svn "Subversion es un sistema que es mucho menos sofisticado que Git", por lo que no puede usar todo el poder de git sin desordenar el historial en el servidor de Subversion. Afortunadamente las reglas son muy simples: mantener la historia lineal
Esto significa que puede realizar casi cualquier operación de git: crear sucursales, eliminar / reordenar / aplastar confirmaciones, mover el historial, eliminar confirmaciones, etc. Cualquier cosa menos las fusiones . Si necesita reintegrar el historial de sucursales locales, utilice git rebase en git rebase lugar.
Cuando realiza una fusión, se crea una confirmación de fusión. Lo particular de los compromisos de fusión es que tienen dos padres, y eso hace que la historia no sea lineal. El historial no lineal confundirá SVN en el caso de que "empujes" una confirmación de combinación al repositorio.
Sin embargo, no se preocupe: no romperá nada si "presiona" un git merge commit a SVN . Si lo hace, cuando se envíe la confirmación git merge al servidor svn, contendrá todos los cambios de todas las confirmaciones para esa combinación, por lo que perderá el historial de esas confirmaciones, pero no los cambios en su código.
Manejo de carpetas vacias
git no reconoce el concepto de carpetas, solo funciona con archivos y sus rutas de archivo. Esto significa que git no rastrea las carpetas vacías. SVN, sin embargo, lo hace. Usar git-svn significa que, de forma predeterminada, cualquier cambio que haga con carpetas vacías con git no se propagará a SVN .
El uso del indicador --rmdir al emitir un comentario corrige este problema y elimina una carpeta vacía en SVN si elimina localmente el último archivo que contiene:
git svn dcommit --rmdir
Desafortunadamente , no elimina las carpetas vacías existentes : debe hacerlo manualmente.
Para evitar agregar la bandera cada vez que realice un dcommit, o para jugar de forma segura si está utilizando una herramienta GUI git (como SourceTree), puede establecer este comportamiento como predeterminado con el comando:
git config --global svn.rmdir true
Esto cambia su archivo .gitconfig y agrega estas líneas:
[svn]
rmdir = true
Para eliminar todos los archivos y carpetas sin seguimiento que deben mantenerse vacíos para SVN, use el comando git:
git clean -fd
Tenga en cuenta que: el comando anterior eliminará todos los archivos sin seguimiento y las carpetas vacías, incluso las que SVN debe rastrear. Si necesita generar nuevamente las carpetas vacías rastreadas por SVN use el comando
git svn mkdirs
En la práctica, esto significa que si desea limpiar su área de trabajo de archivos y carpetas sin seguimiento, siempre debe usar ambos comandos para recrear las carpetas vacías rastreadas por SVN:
git clean -fd && git svn mkdirs
