2011-11-30 12 views
18

Estoy haciendo una conversión unidireccional desde un repositorio SVN a un repositorio Git usando git svn clone. La mayoría de los ejemplos lo hacen con la bandera --no-metadata: ¿hay alguna ventaja con el uso de esta bandera?¿Hay alguna ventaja al usar --no-metadata en git svn clone?

Entiendo que la bandera elimina los números de revisión de SVN. Puedo pensar en razones por las que puede ser útil mantener esto a su alcance (por ejemplo, refiriéndome a confirmaciones específicas mencionadas en el software de seguimiento de errores).

¿Cuáles son los argumentos para usando la bandera --no-metadata? ¿Hay algún beneficio además de la sensación de romper todos los lazos?

Respuesta

12

en realidad no es recomendable:

Esta opción no es recomendable, ya que hace que sea difícil de localizar a viejas referencias a los números de revisión de SVN en la documentación existente, bicho informes y archivos. Si planea migrar eventualmente de SVN a git y está seguro de descartar el historial de SVN, considere git-filter-branch (1) en su lugar. filter-branch también permite reformatear de metadatos para facilitar la lectura y reescribir la información de autoría para usuarios que no son "svn.authorsFile".

+13

Esto no responde la pregunta en absoluto. Sabemos que no es recomendable, pero está ahí; ¿Qué sentido tiene? ¿Qué bien puede hacer? ¿Qué razones podría tener para querer usar esta opción? – thecoshman

+0

@thecoshman +1 no es motivo válido – pinkvoid

11

Un argumento para usar --no-metadata es que no cambia los mensajes de confirmación. Por lo tanto, incluso si obtiene desde diferentes ubicaciones, los mensajes de confirmación serán los mismos y, por lo tanto, los valores hash de confirmación serán los mismos.

A modo de ejemplo, si git svn init un acuerdo de recompra de un file: URL local y después tire de una URL https:, cada commit en el repositorio se duplica, ya que todas las confirmaciones con git-svn-id: file:/// ... será descabellada como git-svn-id: https:/// ... y codificado con nuevos SHA1.

Si especifico --no-metadata, entonces el mensaje de confirmación y este sha1 tendrán será el mismo y puedo buscarlo desde el sistema de archivos local o el servidor de subversión porque solo habrá una copia de cualquier confirmación de svn en el git repo .

Personalmente preferiría que hubiera una mínima opción de metadatos , que registró la revisión subversión ID, pero no los metadatos completamente, pero sin jugar un poco con git-filter-branch nos pegan con todo o nada.

+1

Otro problema que pueden causar estos metadatos es cuando git cree que debería estar creando la confirmación desde diferentes raíces, p. '/ project/trunk' vs. simplemente'/project'. Esto puede causar que los commits sean distintos en git aunque sean iguales en SVN. – jpmc26

Cuestiones relacionadas