Cuando se ejecuta git svn clone y, a menudo durante las operaciones posteriores git svn fetch me sale este mensaje para una serie de carpetas:git-svn "No se pudo encontrar el revmap", ¿qué significa?
Couldn't find revmap for <SVN folder URL>
Mi repositorio parece funcionar bien. ¿Qué significa este mensaje? Debería preocuparme por eso?
No tengo la respuesta completa, pero este error es generado por git-svn.perl. (La ruta del código relevante parece ser do_fetch -> make_log_entry -> find_extra_svn_parents -> lookup_svn_merge.) Ese código parece estar tratando de ver una propiedad de svn merge commit svn: mergeinfo para descubrir todas sus parent commits/branches, con la esperanza de convirtiendo eso en una buena combinación de fusión de múltiples padres dentro del clon de git. Si la resolución de los padres falla, tu compromiso seguirá siendo capturado en git; simplemente no tendrá la misma información para padres que de otra manera.
Hasta ahora, personalmente no he encontrado ningún problema grave derivado de este error para mi caso de uso principal actual, que es la conversión de un svn repo a git; git-svn ha sido capaz de resolver las grandes fusiones que en realidad me importan, y estos errores hasta ahora parecen estar limitados a fusiones individuales o sucursales antiguas que ya no me importan.
En realidad, a primera vista, parece que en mi caso la mayoría de estos errores provienen de commits donde svn:mergeinfo se grabó en lo que interpreto que es el nivel incorrecto en svn. En svn repo, generalmente intentamos registrar svn: mergeinfo en la raíz de la sucursal, p. en svn/trunk, mientras que los casos de los que git se queja parecen pertenecer a mergeinfo adjunto a subdirectorios de ramas particulares, p. en svn/trunk/dir1. No soy un experto en svn, pero mi heurística actual es que si tienes muchos svn: mergeinfos que no están en la raíz de la sucursal, puede haber algún problema con tu svn repo o tu proceso de fusión. Si eso es correcto, es comprensible que git se queje. En mi caso, creo que la mayoría de estos commits "extraños" modifican svn: mergeinfo en la raíz de la sucursal (por ejemplo, svn/trunk) y en el nivel del subdirectorio (por ejemplo, svn/trunk/dir1); git obtiene todo lo que necesita desde el nivel raíz, y arroja un error aparentemente inofensivo sobre el nivel del subdirectorio.
Dicho esto, algunas personas parecen estar reportando problemas en algún caso, tal vez especialmente cuando rebasing in a git-svn repo where not all the branches were checked out.
Sólo quería señalar - en realidad hay un archivo oculto en git-svn, llamado algo así como
.git/svn/refs/remotes/git-svn/.rev_map.00088888-caaa-4444-9999-2222eeeeeee4
... donde el identificador de cierre es el UUID del repositorio o git-svn-id.
Este es un archivo binario, y hay un poco más sobre ella en /usr/lib/git-core/git-svn:
# rev_map: ...
# This is the replacement for the rev_db format, which was too big
# and inefficient for large repositories with a lot of sparse history
# (mainly tags)
#
# The format is this:
# - 24 bytes for every record,
# * 4 bytes for the integer representing an SVN revision number
# * 20 bytes representing the sha1 of a git commit
...
# - Piping the file to xxd -c24 is a good way of dumping it for
# viewing or editing (piped back through xxd -r), should the need
# ever arise.
Tenga en cuenta que la producción se ve algo como esto:
$ cat .git/svn/refs/remotes/git-svn/.rev_map.* | xxd -c24 | head -1
0000000: 0000 0001 33ee 22cc 9933 88aa 44ff 22dd 5566 88ee 66aa bbcc ....5.'..?..J...Zj..`...
Creo que cuando se escribe git svn info , es este archivo el que se consulta para que obtenga un número de revisión SVN basado en el hash SHA git para una confirmación. No tengo ni idea de cómo se podría reconstruir, aunque (aunque git svn reset puede ayudar a borrar las entradas de este archivo, no estoy 100% seguro de que no)
El revmap es la asignación entre los números de revisión de compromiso de Subversion (r123) y los hash de confirmación de Git (b389fe ...).Sin embargo, no tengo idea de lo que significa el error, aparte de eso, lo veo bastante regularmente y parece benigno. –
Supongo que eso significa que el historial de revisiones puede no conservarse. – bancer